Shared libraries in Windows make programming much more efficient for the programmer who does not need to reinvent the wheel every time he needs to perform a common task. They also make it easier to plug security holes in shared code when they are found since it needs to be patched in fewer places and does not require that every application be recompiled.
Despite these positive aspects, they can pose their own problems when attempting to troubleshoot the root cause of error messages they may generate.
Our Reader’s Question:
How to do I fix a Windows Vista 32-bit C:\Windows\explorer.exe problem on a Dell Inspiron 530?
After clicking the OK button in the dialog shown in the screenshot, the screen will blacken out and return to normal running, but it will not allow me to access the C, D, and, at times, the E drive when trying to access them from My Computer.
Running sfc /scannow doesn’t find any errors. I downloaded updates from both the Dell and Microsoft websites trying to fix this problem. I have also installed the Microsoft Visual C++ 2010 Redistributable Package (x86). The PC is completely up-to-date according to Windows Update.
Note: Discussions about Windows Explorer in Windows 7 and earlier versions also apply to File Explorer in Windows 8 and later versions. If there is a notable difference between them, it will be explicitly stated.
The Windows Shell
Windows Explorer is the shell and runs as the explorer.exe process as seen in Task Manager or Sysinternals’ Process Explorer. Like many other Windows programs, all of the functionality provided by the shell is not incorporated into that single executable file. There are dozens of other EXE and DLL files used to implement property sheets, property handlers, preview handlers, context menus, and many other elements you use in Windows Explorer every day.
Shell extensions allow programmers to easily add functionality to Windows Explorer by writing a DLL to perform the task and registering the DLL with the operating system, so Explorer knows where to find the code to accomplish the task. For example, 7-Zip adds a sub-menu to the standard context menu, giving quick access to archive handling tasks, Hard Disk Sentinel adds icon overlays to the standard drive icons, so you can see drive health status at a glance, and HashTab adds a new property sheet, to calculate and display hashes of the selected file.
Many of these shell extensions are implemented as in-process Component Object Model (COM) servers. This means that when a process, in this case Windows Explorer, uses the extension, it will not appear in Task Manager or Process Explorer as a separate running process with its own process identifier (PID). Instead, it is executing inside the calling explorer.exe process.
Default Single-Instance Process
Windows Explorer is written to be capable of running as two separate processes, but — in its default configuration — it will only run a single instance. When it is first executed as part of the startup process, it creates the Windows desktop environment. Executing it again creates a new thread in the existing process, which displays the familiar file management window, instead of starting a new process.
This behavior allows a reduced memory footprint, but can also bring its own little twist when troubleshooting problems. A critical error or unhandled exception in code being executed in the explorer.exe process, including in-process servers provided by DLLs, will cause the entire desktop environment to go down with it.
In most cases, the desktop process will be automatically restarted. If it does not restart, you should still be able to use Ctrl-Shift-Esc to bring up the Task Manager. From there, go to File > New Task (Run…) > type explorer.exe > OK to restart the process.
This can be avoided with a simple change. Open Windows Explorer > Organize > Folder and search options in Vista/7. For Windows 8 and later, open File Explorer > View > Options > Change folder and search options. Select the View tab and check Launch folder windows in a separate process.
Changing this setting isolates your desktop process from all of the other Windows Explorer windows you have open. If any of those Explorer windows crashes, your desktop will remain unscathed.
Microsoft Visual C++ Runtime Library (CRT)
The Microsoft Visual C++ Runtime Library provides routines for programming Windows that automate many tasks, such as input/output, file manipulation, memory allocation, system calls, and many others.
Every Windows installation will have at least two different versions of the CRT installed. A freshly built Vista SP2 through Windows 10 machine will have both version 8.0 and 9.0 (VC 2005 and VC 2008, respectively) present. When additional software is installed, it may also include more recent versions of the runtimes, depending on which version of Visual C++ was used to create the program or any of its components.
When an error or exception is encountered in a piece of code, ideally it will be handled as soon as possible in the currently executing procedure, and either be corrected or allow for a graceful failure. If the error is not handled locally, it gets passed up to the code that called the currently executing code, and the process continues until the exception is handled. If it completes its run to the top of the chain and it still is not handled, it will generate a runtime error as seen above.
When the user clicks on the OK button, the process will be terminated. If the program has a defined failure behavior, such as critical services, or its run state is monitored by another process, it may be automatically respawned. This is what is happening in this instance. The screen blacks out when the explorer.exe process is terminated, then the desktop comes back when the explorer.exe process is restarted.
Although the error message above clearly indicates it came from the explorer.exe process, it is not likely to be a problem with explorer.exe itself. It is much more likely the culprit lies elsewhere, such as a third-party extension that is being used by Explorer.
With our reader’s description of the issue above, there are a couple of additional items we need to take into account:
- At the time of the crash, Explorer was trying, but unable, to populate the listview.
- The inability to access drives after the desktop has respawned, may indicate another process has one or more of those devices locked, thereby preventing access from the newly created explorer.exe process.
- Running sfc /scannow and getting a clean bill of health, drops Windows protected resources to the bottom of the list for consideration. Other causes are far more likely.
The Fixes Are In
In this particular case, there are three areas where I would look for a solution. The first involves the Windows Search service, the second involves investigating shell extensions, and the last would be the VC++ redistributables themselves.
Because the original screenshot shows the crash happening when Explorer is attempting to populate the listview, it is possible that the Windows Search service is blocking access to the required resources. I have seen this happen when the service crashes and does not have the correct restart parameters.
Press Win+R > type services.msc > OK to start the management console with the services module. Scroll down to Windows Search and double-click on the entry to open the Properties dialog. Ensure the settings on the Recovery tab match the image below.
The most common problem is the “Restart service after:” setting. This error frequently occurs when this setting is non-zero.
Problematic Shell Extensions
Download Nirsoft’s ShellExView for your system architecture (x86 or x64), install and run it. It will take a bit of time to examine the system and fill the table with data. Scroll across to the CLSID Modified Time column and click on the header to sort on this field. If you wish to exclude the modules provided by Microsoft, you can go to Options > Hide All Microsoft Extensions. For those using a 64-bit version of Windows, you may also want to show the 32-bit extensions on the system by going to Options > Show 32-bit Shell Extensions.
Look for extensions that were added just before the symptoms began. Select one or more and press F7 or go to File > Disable Selected Items, or click on the red LED icon in the toolbar. Ideally, this should be done one at a time.
Test to see if the symptoms persist. If they do, you can re-enable the previously disabled extension(s) by using F8, File > Enable Selected Items, or the green LED toolbar icon. From here, disable a different extension and repeat the testing process until you find the one causing the problem.
Repair/Reinstall VC++ Redistributables
I use this one as a last resort, if only one program is kicking out errors. If you have multiple programs that are having problems with VC++ runtime errors, you may want to try this first.
When looking at the installed programs on my system (Control Panel > Programs and Features), it shows every version of the redistributable packages (and some of their updates) ranging from version 8 through version 12 (VC++ 2005 through VC++ 2013). I have them installed because of the Microsoft programming tools I use. Most users will not have all of these.
You can find the latest downloads for supported versions of Visual C++ from Microsoft. For our purposes here, you only need to be concerned with those that are labeled as “redistributable” packages. Links that are classified as service packs are for the programming tools, not simply the runtimes. You will only need the ones that are currently listed in the installed programs on your system. Installing other versions will not help out in this case. Users of 64-bit operating systems may need both the x86 and x64 versions of the CRT.
Windows Update checks to see if your computer has the latest updates for these packages installed, but it does not check to ensure that it is properly installed and has not been broken. The installers can check to ensure that all of the runtime files are the proper ones and all registry entries are correct.
Once you have downloaded the appropriate installers, run them on the system. The 2005 versions will prompt you to accept a license agreement before reinstalling the package. All of the others have a GUI that will ask you if you want to repair or uninstall the existing installation. In most cases, a repair operation will fix any issues.
If you want to try the most extreme method, you can uninstall the runtimes, reboot the machine, then reinstall them. I do not recommend this method with the 2005 and 2008 runtimes. Without them, Windows will generate a lot of errors and a great deal of functionality will not be there for you when you reboot.
With a little bit of observation, a touch of trial and error, and some understanding of how errors are generated from runtimes on the system, software issues can be found and resolved without resorting to complicated debugging tools and logs.
Have you run into runtime errors on your system? What was required to solve them? Let me know in the comments below.