Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
PingBack from http://dertompson.com/index.php/2007/07/11/problem-of-periodical-windows-explorer-hangs/
I don't normally put my 10 cents worth into blogs... cuz I'm too busy programming, but I have a piece of insider knowledge from some of the code I have been working on, and lets face it Mark Russinovich is one of the top programmers I have ever come across. I have been building a 'Windows Explorer' style file browser - initially it was a dialog box for some of my other projects, and at some point of mental instability I decided to make it a fully fledged version (alot faster and cooler gui and... well I don't want to yank my own chain here) segway back into my observation - I have noticed the lack of threads used to render the shellfolder icons in windows explorer, this behavior can be observed or reproduced by opening a large directory in the list pane (ie 'C:\Windows\system32 or C:\Windows\i386) and then violently scrolling down to the bottom or scrolling around. You will notice that the display will seize up momentarily as it tries to fill in the icons (this blocking is caused because it is on the main thread). You should be aware that the listview is using callbacks to get its display data. I solved this problem by filling in the text data on the main thread and launching many threads in the callback proc to deal with the icons. And voila the listview scrolls like a banshee no delays, way less clunky, way faster! The little icons filling themselves in in their own time (quite quickly with 8 threads nibbling at them) now all was fine and dandy until I realized that my prog was crashing quite often after I did this, and after some analysis I found that it was usually .msc files causing the crash (something to do with 16bit old crap), it was quite intermittent but was the cause. I then tried to remedy this and found that if I put a mutex in SHGetFileInfo and the Ishellfolder GetIconOf functions that this problem went away. This slowed down the rendering of the icons significantly because the mutex only lets the function occur in a serial manner (and this is the main an slowest function while retrieving icons) instead of happening in a threaded, overlapped manner. So I have a hypotheses that MS in their ultimate wisdom never even bothered to thread these functions because they are not thread safe. However they can be successfully threaded with the appropriate mutexes - which is still much faster and better. BTW if you are interested windows explorer is filled with bugs, mem leaks, inconsistent behaviors, you can make it crash left right and center just by doing certain things - not just from malformed third party shell extensions. A pretty poor production for the most important flagship product for the entire windows product line! Maybe windows should spend their time making what they have better and more efficient, and yes! debugging their bugs. Nah... why pull out the floorboards because their rotten when you can just nail some boards onto the side of the sh*t mansion on an angle and then paint them cool colors to make them look like they are OK.
Thanks, I learned a lot here from the blogger and all the responses. I found another case -- do you know when you click the START button it displays icons for frequent or recently used applications? One of those had a UNC path in it. arrgh! I like the idea of scanning the registry for "\\", it seems to be a simple solution if you know what you are doing.