A blog with focus on Windows 10 and cloud <solutions
RSS icon Email icon Home icon

  • How to solve a crashing File Explorer (explorer.exe) in Windows 10

    Posted on February 27th, 2017 By Andreas Stenhall + No comments

    This is a schoolbook example of how to solve an annoying EXPLORER.EXE crash problem in just minutes. This guide can be used as inspiration for troubleshooting similar problems or for use with any application or process that crashes.

    Problem

    A user experienced a problem after upgrading Windows 10 version 1511 to 1607. Every time the user tried to open Windows File Explorer, it crashed, restarting the entire EXPLORER.EXE process. In the Application log in Event Viewer the following event was logged:

    Faulting application name: Explorer.EXE, version 10.0.14393.479, time stamp 0x58258a90
    Faulting module name: ntdll.dll, version 10.0.14393.479, time stamp 0x5825887f
    Exception code: 0xc0000374
    Fault offset: 0x00000000000f8283
    Faulting process ID: 0x2428
    Faulting application start time: 0x01d290d349d6a062
    Faulting application path: C:\WINDOWS\Explorer.EXE
    Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
    Report ID: cf2ee514-f280-4942-8225-4c7fb440f27b

    Investigation

    As the problem above does not really tell us anything useful we need to obtain more information on the problem. On the machine which have the problem, start by activating the creation of crash dump files to get the information you need by setting the following registry values:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

    Name: DumpFolder
    Type: REG_SZ
    Value: C:\CrashTemp

    Name: DumpCount
    Type: REG_DWORD (32-bit)
    Value: 10

    Name: DumpType
    Type: REG_DWORD (32-bit)
    Value: 2

    Now reproduce the problem so that a crash dump is generated!

    To analyze the problem we will be working with the Microsoft tool Windows Debugging Tools which can be downloaded for free from Microsoft (part of the Windows SDK), https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit (look for Get debugging Tools).

    After installing Windows Debugging Tools, start it from the Start menu, it is called WinDbg (x86) or WinDbg (x64). To be able to get a result from the debugging of the DMP file and find the cause of the problem you will need the symbol files. These can be downloaded as one package but it is much more convenient to setup Windows Debugging Tools to download files as necessary. To set this up, in WinDbg, go to Open and choose Symbol file path. Now type a path to a directory on the hard drive, for example:

    SRV*C:\symbolfiles*http://msdl.microsoft.com/download/symbols

    Load and analyze the crash dump file
    When the process crashes a snapshot of the memory is dumped to a file on the user’s computer.  This is the file that contains the key to the crash and to analyze it first open it by going to Open and then choosing Open Crash Dump. Before doing this copy the file to the machine where you will analyze this.

    Browse to the location of the DMP file and choose to load it and if you get a question if you want to save the workspace you choose Yes. The necessary symbol files will now be downloaded from Microsoft. To get all the details about the crash you have to type:

    !analyze -v

    In this particular crash, we could instantly determine that the cause was thumbcache.dll.

    Solution

    As the problem was related to thumbnails cache, the first thing to try I thought was deleting the thumbnails cache. So I killed the explorer.exe process on the user’s machine and browsed to C:\Users\<username>\AppData\Local\Microsoft\Windows\Explorer and deleted the thumbnails cache files which are located there. Voila, the user could then start File Explorer once again without experiencing a crash!

  • When to troubleshoot blue screen crashes

    Posted on July 27th, 2009 By Andreas Stenhall + No comments

    The other day I got an email from a blog reader which contained the information of a successful analyze of a memory dump file which is generated when an infamous blue screen of death occur. The reader wanted me to give him the solution or point him in the direction of a solution. This got me into thinking. When is it worth putting time on doing blue screen analyzes?

    The content of the crash dump is maybe not that relevant after all. What is more important is how often and when the blue screen of death occurs. If the crash occurred just once or very seldom and randomly I would say that it might not be worth finding out exactly what caused the crash. Keep in mind that a blue screen could indicate a hardware failure, although driver problems are the most common cause for crashes.

    However if the crashes occur often or at when doing specific tasks you have all the reasons in the world to get to the bottom of the problem. In these cases I recommend following the guide for troubleshooting blue screen crashes.

    An interesting thing to note about blue screens that start occurring after for instance upgrading the OS from Windows XP to Windows Vista or Windows 7 is that the new memory management in the later operating systems might reveal problems in the memory modules that did not show when using Windows XP.

    Finally, whenever having problem with blue screens of death I would recommend upgrading the machine BIOS. Often there are compatibility and stability fixes which solves problems with hardware which might be causing you the problems you are experiencing.