I’ve grappled with this problem on various Vista systems for over a year now. A user will be tooling along merrily in Vista on his or her desktop when all of a sudden BAM! Explorer.exe crashes, and automatically restarts itself. A look into the Event Log on the affected desktop usually produces an Event 1000 Error, with the following General log entry:
Faulting application Explorer.EXE, version 6.0.6001.18000, time stamp 0x47918e5d, faulting module unknown, version 0.0.0.0, time stamp 0×00000000, exception code 0xc0000096, fault offset 0x027262f3, process id 0xc44, application start time 0x01c94d7badff6da6.
The two keys to unraveling this problem are the identification of Explorer.exe (which your users will tell you about anyway) and the privileged exception error code 0xC0000096. If you research this history of this code along with explorer.exe, you won’t find much about it on Vista per se, but there are plenty of postings on this topic related to XP. Further digging reveals that file associations active inside Explorer, especially those that invoke non-Microsoft viewers (as when, for example, you designate WinZIP as the default tool for opening .ZIP files, or Paintshop Pro as the default for .jpg, .gif, and .png files) can sometimes cause delays in getting Explorer to open drive icons (it’s chasing viewers down to populate listings with thumbnails in case you wonder why this happens), and can also cause occasional, apparently random crashes as various activities you undertake cause Explorer to refresh views of a drive or folder.
There’s a nifty little freeware program available from Nirsoft called ShellExView that will show you all of the Shell Extensions installed on Windows Vista (and thus also, part of Windows Explorer). By carefully disabling third-party (non-Microsoft, that is) shell extensions inside Explorer–especially those your users never touch, and therefore don’t need anyway–you can usually stop these problems dead in their tracks. When you see how many file extensions appear on a typical desktop (the one shown has 341 shell extensions installed, of which just over 30 come from third parties, and the rest from Microsoft) you’ll develop a profound appreciate of how the occasional tangle here could easily cause problems.
The accepted technique for troubleshooting such issues is to start by disabling all non-MS shell extensions, then re-enable third-party entries in vendor-specific groups to isolate the offending party or parties. My experience has been that you can disable those that aren’t used without any difficulty, then concentrate on those that are used. I’ve been able to identify the culprits in most cases by doing away with unused shell extensions, and have never had to spend more than 15 minutes running down other culprits.
Try it: you’ll find ShellExView to be a very useful tool.