Windows Explored

One of our helpdesk technician’s in a remote office reached out to me recently and asked me to assist with an application that suddenly started crashing on him with the following error: “Microsoft Visual C++ Runtime Library. Runtime Error! This application has requested the Runtime to terminate it in an unusual way…”

We fired up Process Monitor, started the problem application again and collected a trace of the executable up until the message box appeared. Usually, I like to filter for unusual suspects, like access denied, invalid path, or some other out of the ordinary result but nothing really stood out in the Count Occurrences > Results filter, so we set it aside and I told him I would look later. I also captured a dump of the application with Process Explorer and would look for clues using WinDbg.

Following up the next day, I started by examining the dump. I don’t really know the internals of the application well (or for that matter advanced WinDbg techniques) and didn’t really know what I was looking to uncover. It’s a 3rd party app so I can’t take the approach I would normally take with a Microsoft application when it crashes by looking for some 3rd party modules in the thread stacks and then disable them from the program (although, in hindsight, the dump did reveal an important clue).

Turning back to the procmon log, I took a more practical and simplified approach: rather than examining results and file or reg operations, I just followed the log to the end to see what happened just before the application crashed. This is what I saw:
 
There are a series of registry operations for the workstation time zone. This is nothing remarkable … except for that fact that this workstation is in Arizona but the registry activity points to Mountain Standard Time on the workstation. Checking the workstation time, however, revealed it was correct for Arizona, which doesn’t make sense because, during this time of year, Arizona is offset by 1 hour behind Mountain Time. Opening the clock revealed why: DST was not checked for mountain:

In fact, the time zone did not matter at all; as long as the DST option is not checked, the application would crash. Checking this option or setting the time zone to Arizona resolved the problem. In the case of the Arizona Time Zone, this does not matter since Arizona doesn’t use DST at all and the option is not available.

As for the dump I had captured previously, this clue also revealed itself in the first parameter of the second frame right before the exception: