Many software applications that execute in Windows 8 (and earlier Windows versions) come with so-called Windows shell extensions.
These are intended to provide extra application functionality and convenience and they usually do a good job, but like any other software they can go wrong and cause complete or partial application failure -- with considerable bother and even havoc in some cases.
This is a longish blog post, necessitated by the complexity of the way that shell extensions work. They are so tightly interwoven into the parent applications that it can be very difficult to identify, isolate and resolve problems with them.
Hence I’ve gone to the trouble to explain it carefully and in some detail. I hope it will save you wasted time and ease your frustration if you happen to become a victim!
As the name extension implies, these code elements provide extra functionality to File Explorer (you’ll know it as Windows Explorer in earlier versions of Windows) and other parts of Windows.
As MSDN puts it: “The Windows UI provides users with access to a wide variety of objects necessary for running applications and managing the operating system. The most numerous and familiar of these objects are the folders and files that reside on computer disk drives. There are also a number of virtual objects that allow the user to perform tasks such as sending files to remote printers or accessing the Recycle Bin.”
Shell extension handlers are developed by Microsoft as part of Windows itself, but also by many third-party developers ranging from big software corporations right down to solo developers. (There’s a vast number of the latter in the Windows community, many of whom provide retail or freeware products of very high quality).
The type of extension handler that I’m focusing on in this post is Shortcut menu handlers which these days are more commonly referred to as Context menu handlers.
A context menu -- or shortcut menu -- appears when you right click on an object in File Explorer or other contexts such as dialog boxes. For example, in File Explorer to edit the hosts file I might do the following (with the pointer showing where I performed the right click mouse operation):
Context menus are extremely useful, and it’s not long after installing Windows and your favorite third-part software products that there will be quite an assortment of context menu handlers present in your Windows system, all waiting to do your bidding. A typical example:
All right, all right, everybody knows that. Let’s move on to the real point of this blog post.
Last October (2012) I took delivery of what might well be my last ever Windows desktop system. For my prime development system I switched from a quite adequate 4-core machine running Windows 7 64-bit (with a healthy 8 GB of RAM and several terabytes of SSDs plus more terabytes of spinning disks) to an even zippier 8-core machine (with 32 GB of RAM, twin faster SSDs in RAID mode plus even more terabytes of spinning disks), also running 64-bit Windows 7 Ultimate.
This was a few weeks prior to the release of Windows 8 Pro. Once it was released, I tested Windows 8 Pro extensively in a virtual machine environment -- especially getting back some favorite Windows features that Microsoft removed such as the Start Button (via Classic Shell, which I had long been using on Windows 7) and desktop gadgets (via a hack, the 8GadgetPack). I mention this here only because Windows 8 Pro was my final destination.
All went well for a month or two, and then I started having unusual problems with Windows Explorer on the new Windows 7 machine (but not on the old one).
I happen to be an extremely heavy user of context menus, and sometimes in Windows Explorer -- but not every time -- when I invoked a context menu (similar to the example above) there would be a pause lasting a few seconds followed by the following error dialog (1): 
(Click on the various images to view enlargements)
Upon clicking the Cancel button, the following dialog (2) appears:
THE QUESTION:
What could be causing such errors? A little research at the Microsoft support website plus other Windows specialist sites indicated that this sort of thing is likely to be caused by a faulty Windows shell context menu handler.
The question that I was faced with – exactly as you will be in similar circumstances -- is which of many installed software products (ranging from complex suites to tiny single-purpose utilities) have context menu handlers? And then, of course, how do you determine which specific piece of software is causing the current fault?
A SOLUTION:
The universal answer to this seems to be to go to Nir Sofer’s excellent freeware product site. For today’s exercise, download and install the ShellExView utility which enables you to display details of all the shell extensions installed on your computer, and to easily disable or enable each individual shell extension.
TIP - While at the site, you might consider downloading Nir’s entire suite of utilities in a neat package called NirLauncher, a package of more than 150 portable freeware utilities for Windows. The NirLauncher package includes a “variety of tools that you may need for your daily computer use, including utilities to recover lost passwords, to monitor your network, to view and extract cookies, cache, and other information stored by your Web browser, to search files in your system, and more.”
THE BASIC PRINCIPLE:
Identifying and adopting a systematic, consistent debugging approach for the more esoteric parts of Windows can be very difficult.
In this case, by disabling shell extensions one at a time, you should be able to determine whether or not it’s the one causing the problem. But this is easier said than done.
Firstly, you’ll find that your system has dozens and dozens of shell extensions installed. Therefore disabling, testing, then [if not faulty] re-enabling them one at a time is a slow and elaborate process.
Secondly, it’s not always easy to recognize and reproduce the conditions that cause the error. For example, while this context menu error was repeatedly occurring on my new Windows 7 machine, it never did arise on the old Windows 7 system. Despite my best attempts to keep the apps on the two systems in synchronization, apparently the new system had some differently installed and/or configured applications.
It happened that this problem was not at the top of my priorities as the end 2012 approached, so I let it slip as summer vacation time arrived here Down Under.
In no time it was January 2013, and I was planning to upgrade from Windows 7 to Windows 8 Pro before the end of January (being a miser, I wanted to do this before the expiry of Microsoft’s generous $14.99 upgrade price offer). The in-place upgrade to Windows 8 went surprisingly smoothly. I only had to reinstall a couple of products to make them work properly again, and most products worked without a hitch. (I only had to chase down a single device driver update, for an external hard disk docking station that had stopped running at USB 3.0 speeds, and to reinstall a couple of programs after which they worked fine.)
So now I had Windows 8 Pro running pretty well (using my four monitors in non-touchscreen mode, operating 99 percent like Windows 7 did prior to the upgrade, is exactly how I wanted). I get all the benefits of the many under-the-cover enhancements in Windows 8 while happily avoiding the “Modern UI” (a.k.a. “Metro”) like the plague. (It has no relevance at all for the way I work. Whenever I purchase a Windows 8 Pro tablet then, and only then, will I be content to make use of this new tiled interface. But that’s another story.)
But guess what? Whenever I right-click on a folder in the left navigator column of File Explorer, I discover that Explorer always freezes for a few seconds and then closes unceremoniously, without displaying the indicative error dialog that I mentioned above (the earlier screenshot “Windows Explorer has stopped working”) . . . No error message at all, zilch, nada – I really appreciate that, Microsoft!
Luckily, if you call it that, I had been experiencing the Explorer freeze-ups with Windows 7. So I surmised -- quite rightly as it transpired -- that this was likely to be that same context menu bug. I should point out here that without the prior experience under Windows 7 I would have been totally I the dark, without any clue about what was happening under Windows 8 and why. For some reason the Microsoft developers worsened the situation by neglecting context menu error trapping code when developing Windows 8 File Explorer.
THE RECOMMENDED METHOD TO USE SHELLEXVIEW:
So, how should you go about using ShellExView to resolve your difficulties? While some other people have discussed the use of ShellExView, generally they’ve omitted usage details (see this case).
When I ran ShellExView on my Windows 8 system I got the following listing. Note that it’s best to sort the entries by vendor name (Company), and I’ve highlighted the Microsoft section in yellow. This is the start of the list (T represents “Top”):
After scrolling down a long way in ShellExView, here are the last few Microsoft entries and the remainder of the non-Microsoft entries (B represents “Bottom”):
It’s a reasonable assumption that it is highly unlikely that the faulty shell extension will be contributed by Microsoft, so let’s ignore the central yellow section of the list.
Adopt a binary search type of approach. Firstly, select all of the entries bottom entries (B) and disable them via the context menu of ShellExView (click “Disable Selected Items” or press the F7 key).
Now focus on the section of the list (T). Disable each of them one at a time, and see if the fault that you’re testing remains or not (in my case, see if Windows File Explorer crashes silently).
As mentioned earlier, this sort of testing can be a laborious process. So if the top section (T) contains too many entries, consider using the binary search approach on it by disabling half of these and checking the other half one at a time.
If none of the top entries seem to be causing the problem, re-enable them and move down to the bottom section (B) of ShellExView, where you carry out the same binary search approach:
It was here that I discovered that when I disabled the Spybot-S&D Explorer Integration the problem went away. Relief at last, like as if I’d stopped hitting myself on the head with a hammer!
The final task was, naturally, to double-check that this is the only disabled shell extension and that all the others were enabled.
So there you are, job done: a methodology for you to follow when you’re faced with this sort of problem. I hope that it’s one you can use effectively, and avoid losing as many hours as I did when solving this issue.
And of course, some faulty shell extension code that Safer-Networking Ltd has to fix in Spybot - Search & Destroy.
UPDATE (25 April 2013):
Their support team just advised me that this is a known problem with Search & Destroy version 2, here is their forum post about it:
You do not need to uninstall Spybot 2, you can simply disable the feature that is causing the issue. Please run the Start Center, switch to advanced mode and start Settings.
Now open the tab "System Integration“. Here you can uninstall "Windows Explorer integration“. Click "Apply“ and "OK“ afterwards. Settings can also be launched via SDTray (the small Spybot 2 icon beside your systems clock in the taskbar).
Making use of ShellExView was the only way that I eventually determined what the cause of the problem was. Because of the nature of this crash I didn’t have a clue that it was a Spybot issue, so didn’t ever even think to check on this particular support forum.
0 comments:
Post a Comment