Finding what’s causing Windows 10 explorer constantly crashing

If you are here than you probably have the same problem that I had. The same problem that some of my colleagues had. You upgraded a Windows 7 or 8 installation to Windows 10, and now every few seconds Explorer freezes up for about a minute and then restarts.

Like I said, I have seen a few computers with this problem, and after a lot of searching was able to get them all working. Usually it was some incompatible component, and the solution (or workaround) was simply to rename it. But the thing is, each one was crashing because of a different component. Each time it was a different file I had to rename. Sometimes looking in Event Viewer can give the answer. You should give it a look before trying the procedure below. But sometimes Event Viewer yields nothing. It only reports a crash in Explorer.exe, which doesn’t help much. So how can we identify what component is causing the issue?

Process Monitor

Process monitor is a really useful tool which shows file system, registry and network activity for processes in real-time. In one of the cases, I used it to get a hint as to which component was causing the exception. If you don’t already have it you can download it from the link above. After downloading and running it, if not already in the filters screen, click on the funnel icon or choose Filter -> Filter (Ctrl-L), to open the filters dialog.

We want to see only activity from Explorer.exe. To do that, choose Process Name, is, type Explorer.exe, choose include and click Add.

Setting the filter to Include explorer.exe
Setting the filter to Include only Explorer.exe

Now you should see a lot of activity from Explorer.exe, all with the same PID. The next time it crashes though, you will also see activity from a new PID, until the first one ends up dying. You can already click on the magnifying glass to stop capturing more activity.

Second PID gets created
Second PID gets created

Now scroll up until before all the Thread Exit calls, if you see an event Create Process for C:\WINDOWS\system32\WerFault.exe you can ignore it, and before that there should be some activity related to the exception handling. That’s not the exception itself though, so you still haven’t found the problem.

Finding exception handling events
Finding exception handling events

Double click one of the events. In my case it was one of the registry queries. Click on stack, to confirm this is related to exception handling. You should see something like this:

Stack trace showing the activity is related to exception handling
Stack trace showing the activity is related to exception handling

If you see near the top of the stack (bottom of the screen) UnhandledExceptionFilter + some hex number great, you are almost done. If you see KERNELBASE.dll + some number instead, it means the symbols aren’t being loaded. It’s still possible to continue, but it will be harder. If you already see the symbols or if you want to proceed without them you can skip the following section.

Setting up symbols loading

If you want to see the symbols but they aren’t being loaded, you need to find a copy of dbghelp.dll and, according to this post, symsvr.dll. You might have them in you computer already, or you can download Debugging Tools from Microsoft. You can try looking in C:\Program Files (x86)\Microsoft Visual Studio {version}\Common7\IDE or C:\Program Files\Windows Defender, or install Debugging Tools from here, which will install the dlls to C:\Program Files\Windows Kits\10\Debuggers\x86 or C:\Program Files (x86)\Windows Kits\10\Debuggers\x64. Once you found these dlls go to Options->Configure Symbols then on DbgHelp.dll path enter the path of both dlls. They should be in the same folder. Symbol paths should already have srv* Now when you go to the stack trace screen you should see Loading Symbols near the bottom and the function names should appear next to the Module.

Identifying the misbehaving file

The last events before the process terminates are related to the exception handling, and not to what actually caused the exception. You have to search up the events, looking at their stack, until you find one that’s not related to exception handling. In my case there were a lot of similar events all of which were still under UnhandledExceptionFilter (or KERNELBASE.dll + 0xF540F if you don’t have symbols) until I reached an event which wasn’t.

Blue still had UnhandledExceptionFilter in the beginning of the stack. Yellow was unrelated and red was where the problem lied.
Finding the culprit

All the events which still had UnhandledExceptionFilter in the stack trace are highlighted in blue. The first event before that is highlighted in yellow and in my case was unrelated to the problem. The one before that gave a hint where the exception might have occurred. Let’s see the stack:

Stack trace of event near the exception
Stack trace of event near the exception

Looking at the stack trace we can see that the system was probably loading ODBCCP32.CPL right before the exception occurred which is a strong indicator of where the problem was. To confirm my suspicion I renamed the file to ODBCCP32.CPL.BAK and finally the freezing stopped.

Using this procedure you can find the offending component, and you can look for specific solutions for it, such as updating it to it’s latest version. Or, you can just rename it “temporarily”, and your system will be usable.

Leave a comment if this helped you (or if it didn’t), and which was the component. It might save others some time!

12 thoughts on “Finding what’s causing Windows 10 explorer constantly crashing”

    1. Jhon,

      What did you see? Did you see a new instance (with a new PID) being created? What was on the call stack of the last events of the old PID?

  1. Likewise, I can’t see any labelled with UnhandledExceptionFilter – are there any other things to look for that may be causing the same issue?

    A new PID is created as described and it looks the same up to your screenshot captioned ‘Finding exception handling events’ (ie. ending in multiple QueryNameInformationFile entries referencing \System32\ntdll.dll)
    The equivalent last entry has a stack as follows:

    0 FLTMGR.SYS FltDecodeParameters + 0x195a 0xfffff802f8c046ca C:\WINDOWS\System32\drivers\FLTMGR.SYS
    1 FLTMGR.SYS FltDecodeParameters + 0x1508 0xfffff802f8c04278 C:\WINDOWS\System32\drivers\FLTMGR.SYS
    2 FLTMGR.SYS FltDecodeParameters + 0x616 0xfffff802f8c03386 C:\WINDOWS\System32\drivers\FLTMGR.SYS
    3 FLTMGR.SYS FltDecodeParameters + 0x3be 0xfffff802f8c0312e C:\WINDOWS\System32\drivers\FLTMGR.SYS
    4 ntoskrnl.exe IoQueryFileInformation + 0x141 0xfffff8013b05f449 C:\WINDOWS\system32\ntoskrnl.exe
    5 ntoskrnl.exe NtQueryVolumeInformationFile + 0x6eb 0xfffff8013b02751b C:\WINDOWS\system32\ntoskrnl.exe
    6 ntoskrnl.exe NtQueryVolumeInformationFile + 0x482 0xfffff8013b0272b2 C:\WINDOWS\system32\ntoskrnl.exe
    7 ntoskrnl.exe NtAllocateVirtualMemory + 0x2e3d 0xfffff8013b02459d C:\WINDOWS\system32\ntoskrnl.exe
    8 ntoskrnl.exe NtAllocateVirtualMemory + 0x1991 0xfffff8013b0230f1 C:\WINDOWS\system32\ntoskrnl.exe
    9 ntoskrnl.exe NtAllocateVirtualMemory + 0x10b9 0xfffff8013b022819 C:\WINDOWS\system32\ntoskrnl.exe
    10 ntoskrnl.exe setjmpex + 0x3a93 0xfffff8013ad56d93 C:\WINDOWS\system32\ntoskrnl.exe
    11 ntdll.dll ZwQueryVirtualMemory + 0x14 0x7fff382452b4 C:\WINDOWS\SYSTEM32\ntdll.dll
    12 ntdll.dll RtlGetAppContainerSidType + 0x50f 0x7fff381f980f C:\WINDOWS\SYSTEM32\ntdll.dll
    13 ntdll.dll PssNtCaptureSnapshot + 0x187 0x7fff381fe3f7 C:\WINDOWS\SYSTEM32\ntdll.dll
    14 ntdll.dll RtlReportException + 0x25b 0x7fff381a4a4b C:\WINDOWS\SYSTEM32\ntdll.dll
    15 ntdll.dll RtlReportException + 0x48b 0x7fff381a4c7b C:\WINDOWS\SYSTEM32\ntdll.dll
    16 ntdll.dll RtlReportException + 0x77 0x7fff381a4867 C:\WINDOWS\SYSTEM32\ntdll.dll
    17 ntdll.dll memset + 0xae0 0x7fff3824c1e0 C:\WINDOWS\SYSTEM32\ntdll.dll
    18 ntdll.dll _C_specific_handler + 0x96 0x7fff38235946 C:\WINDOWS\SYSTEM32\ntdll.dll
    19 ntdll.dll _chkstk + 0x11d 0x7fff3824991d C:\WINDOWS\SYSTEM32\ntdll.dll
    20 ntdll.dll RtlImageNtHeaderEx + 0x483 0x7fff381e86d3 C:\WINDOWS\SYSTEM32\ntdll.dll
    21 ntdll.dll KiUserExceptionDispatcher + 0x3a 0x7fff38248a3a C:\WINDOWS\SYSTEM32\ntdll.dll
    22 vtkCommon.dll vtkCommonInformationKeyManager::ClassFinalize + 0x36 0x7fff179838a6 C:\Program Files\Autodesk\Inventor 2014\Moldflow\bin\vtkCommon.dll
    23 vtkCommon.dll vtkCommonInformationKeyManager::~vtkCommonInformationKeyManager + 0x11 0x7fff17983911 C:\Program Files\Autodesk\Inventor 2014\Moldflow\bin\vtkCommon.dll
    24 vtkCommon.dll vtkXMLFileOutputWindow::DisplayXML + 0xe2f 0x7fff17ad210f C:\Program Files\Autodesk\Inventor 2014\Moldflow\bin\vtkCommon.dll
    25 vtkCommon.dll vtkXMLFileOutputWindow::DisplayXML + 0x1079 0x7fff17ad2359 C:\Program Files\Autodesk\Inventor 2014\Moldflow\bin\vtkCommon.dll
    26 ntdll.dll RtlDeactivateActivationContextUnsafeFast + 0x1bf 0x7fff381c9d9f C:\WINDOWS\SYSTEM32\ntdll.dll
    27 ntdll.dll LdrUnloadAlternateResourceModuleEx + 0x32d 0x7fff381b3d2d C:\WINDOWS\SYSTEM32\ntdll.dll
    28 ntdll.dll RtlCreateHeap + 0x1241 0x7fff381b1621 C:\WINDOWS\SYSTEM32\ntdll.dll
    29 ntdll.dll LdrUnloadDll + 0x16c 0x7fff381edcbc C:\WINDOWS\SYSTEM32\ntdll.dll
    30 ntdll.dll RtlCreateHeap + 0x13c5 0x7fff381b17a5 C:\WINDOWS\SYSTEM32\ntdll.dll
    31 ntdll.dll LdrUnloadDll + 0x16c 0x7fff381edcbc C:\WINDOWS\SYSTEM32\ntdll.dll
    32 ntdll.dll LdrUnloadDll + 0x94 0x7fff381edbe4 C:\WINDOWS\SYSTEM32\ntdll.dll
    33 KERNELBASE.dll FreeLibrary + 0x1d 0x7fff3534212d C:\WINDOWS\System32\KERNELBASE.dll
    34 combase.dll CoUnmarshalInterface + 0x12e8 0x7fff37f0cb18 C:\WINDOWS\System32\combase.dll
    35 combase.dll CoUnmarshalInterface + 0x11f6 0x7fff37f0ca26 C:\WINDOWS\System32\combase.dll
    36 combase.dll CoCreateInstance + 0x1532 0x7fff37f06ec2 C:\WINDOWS\System32\combase.dll
    37 combase.dll CoUnmarshalInterface + 0xc9e 0x7fff37f0c4ce C:\WINDOWS\System32\combase.dll
    38 combase.dll CoUnmarshalInterface + 0x8d4 0x7fff37f0c104 C:\WINDOWS\System32\combase.dll
    39 combase.dll CLSIDFromString + 0x669 0x7fff37f0f6c9 C:\WINDOWS\System32\combase.dll
    40 combase.dll CoWaitForMultipleHandles + 0x382 0x7fff37ef44a2 C:\WINDOWS\System32\combase.dll
    41 combase.dll CoUninitialize + 0x85 0x7fff37ef2bf5 C:\WINDOWS\System32\combase.dll
    42 CFreeThreadedItemContainer_CreateInstance + 0x4125 0x7fff34aae915 C:\WINDOWS\System32\
    43 SHCORE.dll GetScaleFactorForMonitor + 0x336 0x7fff351d7c86 C:\WINDOWS\System32\SHCORE.dll
    44 ntdll.dll RtlQueueWorkItem + 0x679 0x7fff381ed9f9 C:\WINDOWS\SYSTEM32\ntdll.dll
    45 ntdll.dll RtlReleaseSRWLockExclusive + 0x181a 0x7fff381d2caa C:\WINDOWS\SYSTEM32\ntdll.dll
    46 KERNEL32.DLL BaseThreadInitThunk + 0x14 0x7fff377c8364 C:\WINDOWS\System32\KERNEL32.DLL
    47 ntdll.dll RtlUserThreadStart + 0x21 0x7fff38205e91 C:\WINDOWS\SYSTEM32\ntdll.dll

    1. Try renaming C:\Program Files\Autodesk\Inventor 2014\Moldflow\bin\vtkCommon.dll to vtkCommon.dll.bak and see if that resolves the issue. If it does, you can try reinstalling or updating Autodesk on your computer.

    1. Nevermind, that’s not the problem anymore.
      What I want to know is what even are symbols, and how do I know they’re even there?
      And will the problem always be visible inside a CloseFile operation?
      Is there a way to filter out the operations that didn’t raise an exception (so I can find when the first one happened)?
      Sorry, it’s just that this whole article was so vague about using procmon, something I don’t know anything about. I am lost and confused.

      1. Symbols are basically the names of the functions inside the dll with their offsets. They allow the call stack to have meaningful names. Without them you will see calls like KERNELBASE.dll + 0x(some large number), since procmon knows the address where the call was made, but does not know what function that address refers to.
        There is no rule how the exception will appear. In my case I saw UnhandledExceptionFilter but if you look in the comments you will see an example containing KiUserExceptionDispatcher and RtlReportException.
        Sorry if the article is vague but there isn’t one surefire way of finding the problem (if there was Microsoft would probably provide it, or just fix the problem). I just outline how to do it and what patterns to look for, but some detective work is still required.

  2. Hi, Excellent tutorial, but how to find those in my explorer.exe is not known. i have the same pid of the exe. But how to find the error part. If i allow, it does not end but goes on showing the process explorer for the current time and passisng on when the time also pass. Please will you make me understand. If i am able to fix my explore.exe stopping problem, i would be saved from repairing or reinstalling of the windows. how to find the errors. Thread exit where?

  3. Just a thought… I struggled with the exact same problem for months and pored over event logs looking for the magic bullet. But after I upgraded to Windows 10 Fall Creators Edition, Windows identified a memory fault. I ran MemTest86 and found that some of my RAM memory had failed. I replaced it and Windows Explorer hasn’t died since.

Leave a Reply

Your email address will not be published. Required fields are marked *