The Case of the Intermittent (and Annoying) Explorer Hangs

This is a summary of a popular posting to Mark's Sysinternals Blog (http://www.sysinternals.com/blog). You can read the entire blog post at http://www.sysinternals.com/blog/2005/08/case-of-intermittent-and-annoying.html.

I have several computers in my home network, each with a general designated purpose. For example, one is my game machine, another is my home development system, and a third is where I manage my pictures and home videos (and they all double as test systems). I recently started experiencing intermittent temporary Windows Explorer hangs of up to a minute in length on the development system when I open certain folders and scroll through their contents. We've all experienced Explorer hangs, and the first few I wrote off to standard Explorer flakiness. However, when I recognized the regularity of the hangs, I suspected that something was broken and decided to investigate.

First, I used Sysinternals' Process Explorer to examine the hanging Explorer thread to see whether it reveals any clues about the cause of the hang. (You can view the steps that I performed and the resulting output by reading the full blog posting at http:// www.sysinternals.com/blog/2005/08/case-of-intermittentandannoying.html.) I determined that Explorer was trying to access a network path to obtain icons for the folder that I had opened. I suspected that the network path in question wasn't valid and that the apparent hang was a timeout waiting for a remote computer to respond.

Next, I used Sysinternals' Filemon to determine the network path Explorer was trying to access and why it was accessing a network path to get an icon. The Filemon trace showed that the reference to the path on the development computer resulted in a "bad network path" error and for good reason: Several days earlier, I'd decommissioned that computer.

Only one question remained: Where was Explorer getting the path that referenced the decommissioned computer? The answer resided in the registry, so I had two options: I could use regedit to search for the path, or I could watch for the reference in Sysinternals' Regmon. I chose the latter, so I started Regmon and set it to filter for "development." I refreshed a problematic folder and saw the following entry in Regmon's output:

 QueryValue HKCR\PSP5.BrowserFile\DefaultIcon\{Default} 
   SUCCESS 
  "\\Development\C\PAINTS 1\Psp.exe,Ø" There was the answer. 

I have for a long time used an old version of Corel Paint Shop Pro as my picture viewer because it has the features I need, and I don't need to run an installer to use it. I simply run its executable, Psp.exe, and Paint Shop Pro configuresits settings automatically and runs correctly even from network shares. That means that I can install it on one system in my network and run it from the others. I'd originally run the program from the decommissioned development computer. Paint Shop Pro creates browse files in the folders you view with its browse functionality, and the Regmon trace revealed that it registers an icon for those browse files. The icon for Paint Shop Pro's browse file type was still registered to the original location of the executable on the missing computer. When Explorer came across one of those browse files, it tried to load the icon, and because Explorer is, even today, largely single-threaded, when the network driver waited for the phantom system to respond, Explorer's UI hung.

After some digging, I found that there's no supported means in the Explorer UI to easily manage default icon associations. I could have hunted down every Paint Shop Prorelated file in Explorer's File Types tab in the Folder Options dialog box and deleted the associations, but instead, I just manually deleted Paint Shop Pro's registry keys and browse files from my systems.

Using Process Explorer, Filemon, and Regmon I had diagnosed and fixed the problem in about 15 minutes. (You can download all three programs from http://www.sysinternals.com.) What's disturbing about this troubleshooting example is that the average user confronted with the same scenario would have had no way of knowing what was causing the hangs or how to fix them. This is just one example of the many types of Windows problems that cause users to complain that their systems slow down over time and that result in a general "I don't know, just reinstall" mentality. I hope Windows Vista does better.