Windows Explored

While deploying Windows 7 to a couple offices a few months ago, we started to receive some complaints of IE exhibiting weird behavior. I had a chance to witness this myself. The issue usually arose when a user would open the browser to perform a search on Google, MSN, or Yahoo. For example, after initially typing into the search box of the search engine for Google, one would begin to see search hits auto-populate normally, but afterwards if you tried to access one of the browser menu options a second time, the browser would “hiccup” and none of the menu options would function. Even odder, if trying to type a search phrase in the MSN search box, the typed characters would show up in the IE address bar. Here is a video of this odd behavior:

Eventually, uninstalling IE 9 and reinstalling was enough to resolve, but I wanted to see I could isolate the issue to come particular component. To do this, I started with Dependency Walker and started IE through its debugger. Strangely enough,  the issue with the browser could not be created anytime the debugger was attached. Curious, I did some searching in the DW FAQ and found this:

My application runs better when being profiled by Dependency Walker than when I run it by itself. Why is this?

I’ve had several reports of applications that normally crash, will not crash when being profiled under Dependency Walker. Dependency Walker acts as a debugger when you are profiling your application. This in itself, makes your program run differently.

First, there is the overhead of Dependency Walker that slows the execution of your application down. If your application is crashing due to some race condition, this slow down alone might be enough to avoid the race condition. If this is the case, it is a design issue of the application and you are just getting lucky when it doesn’t crash.

Second, normally when threads block on critical sections, events, semaphores, mutexes, etc., they unblock on a first-in-first-out (FIFO) basis. This is not guaranteed by the OS, but is usually the case. When being run under a debugger, FIFO queues are sometimes randomized, so threads may block and resume in a different order than they would when not running under a debugger. This might be relieving a race condition or altering the execution enough to make things work. Again, the application is just getting lucky when it doesn’t crash.

Finally, applications running under the debugger automatically get a system debug heap. All memory functions are handled slightly different. Allocations are padded with guard bytes to check to see if you are writing outside of a region you have allocated (buffer overrun/underrun). Allocations might also be laid out differently in memory then when not under the debugger. So, if you are writing past the end of a buffer under the debugger, you might be trashing guard bytes, freed memory, or just something not very critical. However, when not running under the debugger, you might be trashing something critical (like a pointer), and your app crashes.

For the debug heap, you can turn this off in Dependency Walker and see if your application crashes when being profiled. If it does then, then you probably suffer a buffer overrun, stray/bad/freed pointer, etc. To do this, start a command prompt. Type "SET _NO_DEBUG_HEAP=1". Then start Dependency Walker from that command line. This should disable the debug heap for that instance of Dependency Walker. Note, this only works on Windows XP and beyond.

We have not encountered the issue since the pilot offices completed their deploys. Perhaps anyone of the various changes that were made to the task sequence corrected whatever was causing this.