WINDOWS EXPLORER - HANG / CRASH
Description: Windows explorer can often fail in one of two ways: A hang, or a crash. The reasons for these behaviors may be different but the data needed to troubleshoot them are often the same.
Scoping the Issue: The first thing to be determined is whether explorer is hanging or actually crashing. This can determine what kind of dump needs to be collected if a user dump is needed.
Hang: The Windows Explorer process is still running however it may be extremely slow or listed as “not responding” in task manager. The unresponsiveness may only last for a couple of seconds or Windows Explorer may never respond. If the process is listed as "Not Responding" in Task Manager, then it may truly be hung, but keep in mind are some scenarios where applications that are waiting for network resources may also be listed as "Not Responding". In these instances, forcibly terminating and restarting the process is required to restore functionality.
Crash: If explorer actually crashes, the process is terminated and may or may not restart on its own. A new PID will be seen for exporer.exe under task manager.
Data Gathering: In all instances, collecting either MPS Reports with the General, Internet and Networking, Business Networks and Server Components diagnostics, or a Performance-oriented MSDT manifest must be done. Additional data required may include the following:
- In the event of a hang, we may need to capture a dump (or a number of dumps) of the explorer while it is in its unresponsive state. You can do this by either running ADPLUS.VBS from the Windows Debugging Tools in hang mode. On Windows Vista and later operating systems, you can also create a dump of the process from within Task Manager. To do this, highlight the process, right-click and select the "Create Dump File" option.
- For an application crash, check to see if a crash dump has been created. If using Windows Server 2003 or older, you can open Drwtsn32.exe and check the Crash Dump path for the location. The file should typically be named 'User.dmp'. Any dumps along with the MPS Report or MSDT logs should be uploaded to us for review. For additional details, please see our post, Capturing Application Crash Dumps .
Troubleshooting / Resolution: After you have gathered the data, there are some things to check:
- MPS Reports:
- Review the information in the PROCESS.TXT file to see what binaries are being loaded under EXPLORER.EXE. Disabling the third-party add-ins may provide relief. Using a tool such as Autoruns can assist with disabling third party shell extensions.
- You should also check the Event Logs and Windows Update logs to see if there were any application updates or patches that preceded the unexpected behavior - there may be a correlation
- Process Explorer: If you have the opportunity to do so, it may be worth using Process Explorer to examine what an unresponsive application is doing while it is in-state
- Dump File Analysis: If you are experienced at looking at dump files, there are some things that you can look for:
- For hang dumps, check for application locks (for example, anti-virus locks), long-running threads and whether or not the application is waiting for data - for example from a network resource or a user input
- For application crash dumps, running the command !analyze -v may provide a hint as to the cause of the failure. However, the output of this command may not always identify the real culprit.
Additional Resources: