Controlling Windows Explorer’s Thread Count (new utility)
Jacques Bensimon sent over this new IPM tool. Enjoy!
As you may be able to tell from this old Classic Shell review, I’m no fan of Microsoft’s recent reinventions of the Start Menu, starting with Windows 8 and persisting to this day. For clients who share this opinion and are bold enough to color outside the lines, I’ve often suggested the addition of Open-Shell-Menu (a reboot of Classic Shell’s Classic Start Menu after its original author made the code available on GitHub), especially in VDI environments where non-persistent profiles can make the retention of the native Windows 10 Start Menu customizations a challenge (to say the least). Without going into all of Open-Shell-Menu’s great features, those who’ve followed this advice have enjoyed the return of a multi-level Start Menu (either single-column Win7-style or “fly-out” WinXP-style), easily captured user customizations, and the remarkable capability (for a freeware product) of being entirely configured via Group Policy.
However, on a recent occasion, I was made aware by a client’s crack Citrix team using Open-Shell-Menu in a Windows Server 2016 RDS/XenApp environment that some few users were reporting that Explorer was occasionally “freezing”, causing the loss of all Start Menu functionality (including Open-Shell-Menu’s). Further research had led them to forum threads such as this one that suggest the issue is, if not necessarily an Open-Shell-Menu bug, possibly an Explorer bug sometimes being triggered by Open-Shell-Menu, under unknown circumstances and for unknown reasons. The sole predictor of this freezing being on the verge of occurring seems to be a wild increase in Explorer’s thread count, reaching the neighborhood of 800 (70 to 120 being a typical/normal thread count in most user sessions). If Explorer is restarted before getting too close to this threshold (or even after a freeze has occurred), its thread count returns to normal and it continues behaving properly thereafter, sometimes for the rest of the user’s session, sometimes not.
Feeling somewhat responsible for this predicament (my lawyers vehemently discouraged my saying so! 🙂 ), and not in a position to easily troubleshoot the issue given the inability to reproduce it on demand, I found myself coding a temporary workaround to monitor Explorer’s thread count and restart it whenever it breaches a given threshold. Not ideal — while all running apps go back to their proper place on the Taskbar or in the Notification area (“tray”) after Explorer restarts, a fairly quick process, any Explorer folder windows that happened to be open before the restart are gone – but probably acceptable as a temporary measure (which most users will probably never see in action given the relative rarity of the issue manifesting). The end result was the new utility Explorer Threads Watcher – not of great interest for most environments, but something to consider if you’re faced with a similar runaway Explorer issue.
Syntax (run with just /? as parameter to see this dialog):
To test behavior, run the utility with parameters like 100 30 — the first number should be a little higher than explorer.exe’s current thread count, as shown by Task Manager if you add the “Threads” column to its Details view — then open a few folders. This should quickly push Explorer over the threads threshold you specified, and it should then restart within at most 30 seconds – you will also soon see a notification explaining why Explorer restarted.
Right-click menu: “Check Now” does an immediate check & refreshes the Explorer thread count shown when you hover over the tray icon (it will also restart Explorer if over the specified max thread count), “Restart Explorer” does just that immediately, regardless of thread count, “Pause Watcher” turns the tray icon red and ceases the scheduled checks until un-paused (but you can still update the thread count manually using “Check Now”).
Notes:
- The utility is compiled 32-bit, so it works in any Windows version.
- Although the threads check is not an “expensive” operation, I don’t recommend running with checks more frequent than every 20 seconds.
- The utility can be run again with new parameters at any time to immediately replace the currently running instance.
- The utility uses a “polite” method to request that Explorer exit, but will move on to a more drastic method if Explorer fails to respond in reasonable time.
Needless to say, I would be very interested to hear from any of you who’ve experienced this Explorer issue with Classic Shell or Open-Shell-Menu, especially if you can share any insight into what triggers it.
JB