A blog with focus on experiences with the Windows Client operating systems…
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!

  • The solution to 0xC004F013: Remove KB941649

    Posted on December 27th, 2007 By Andreas Stenhall + 1 comment

    Since the first build of Service Pack 1 beta was released I have had major problems installing it on our Vista Enterprise corporate image, with hotfixes, security update and drivers integrated. The problem has been that we have to install Service Pack 1 two times, the first time it will always fail with the error code 0xC004F013 but the second time SP1 would always install without any indication of error. Very annoying as SP1 takes some time to install and as we will be rolling out Vista in the organization it is totally unacceptable to have to install SP1 twice. And who knows what other side effects there might be?

    Microsoft and I did some research and I first thought that a patch that is only available for order from Microsoft Support was the cause of the problem. After rebuilding the image without that patch the SP1 installation would still fail with 0xC004F013. Today, back at work after Christmas, I managed to figure out by reading the log files produced from package manager (pkmgr.exe) that KB941946 is the hotfix that causes this SP1 installation problem. And to be accurate it’s version 2 of the patch.

    It would be very interesting to learn if anyone else who has a Vista image with patch KB941649-V2 integrated get this error 0xC004F0143 as well when installing Service Pack 1. The problem itself does not lie in SP1 and that is why it has been important to actually and finally get to the bottom of this!

  • Deployment bug found in Vista RTM

    Posted on December 16th, 2007 By Andreas Stenhall + No comments

    Long time no see! I have lots of things to blog about, I just haven’t had the time to do so lately. Last week though I learnt  about a tricky NetBIOS computer naming bug when deploying Vista using Windows Deployment Services (WDS). As you might know  the NetBIOS computer names cannot be longer than 15 characters and when you in Windows Vista (and all previously released Windows versions as well) change the computer name to a name with more than 15 characters you will get a warning message
    that will look something like the screenshot attached to this post.

    Computer name change

    When using Windows Deployment Services with the new option “Name and approve” the client before pushing out the image to the client, you can as you might have figured name the computer object in Active Directory and then fully automate the  installation process. In the unattended answer file in the computer name section for deploying Vista we have entered %MACHINENAME% to make sure that the computer name is not randomly generated with a name like LH-XY45YHGKL and to make sure
    that we will not get any questions to answer when deploying automatically.

    We have a computer naming standard which obviously sometimes makes the computer name more than 15 characters. The bug is when you name a computer longer than 15 characters during Name and approve in the WDS. Then the unattended installation will fail at the specialize pass, without any particular error message, probably because it wants to show the same error message dialogue as when we are in the GUI version of Vista.

  • Where are the “Solutions to install” in Vista?

    Posted on October 20th, 2007 By Andreas Stenhall + No comments

    The error reporting tool Problem reports and solutions in Windows Vista (and also in the upcoming Windows Server 2008) is a great addition from what we saw in error reporting in Windows XP. All application, system and driver crashes as well as compatibility problems and missing driver information is listed in this new control panel for error reports and is sent to Microsoft for analysis. Sometimes, much more frequently than Windows XP, there are solutions available. The check for a solution is done instantly when a crash occur in an application or a Windows component but you can also manually check every now and then to see if there are any solutions to the problems you have experienced.

    Today Windows Explorer crashed on me and it instantly pointed me to the solution, downloading and installing hotfix KB941648, which is the newly released update for compatibility, reliability and stability in Windows Vista. While there are direct links to the download location of the hotfix in the solution to this problem I am still waiting for the first “solution to install” to show up in the Problem reports and solution tools. Having the necessary updates sent to you would be a lot more convenient, and as the feature is already there I wonder why no one is using it, Microsoft for one should be using it! Have you had a “solution to install”?

    Problem reports and solutions

  • Vista SP1 installations fail with error code C004F013

    Posted on October 18th, 2007 By Andreas Stenhall + 1 comment

    The first time I installed Windows Vista Service Pack 1 beta on my work laptop it seemed to install fine, but after logging in for the first time it wanted me to activate Vista to be able to continue. Strange I thought and of course I tried to activate it since our MAK key was in the image already. But instead of activating Vista the computer would just restart and the SP1 installation was reverted and the installation eventually was pronounced as failed with error code C004F013. I tried installing SP1 again and then it was installed successfully.

    After doing another Vista deployment and installing SP1 I found out that the exact same thing happened again, and then again on another machine. I then filed it as a bug on Connect as the problem was also occuring with the standalone version as well as the one from Windows Update. Microsoft has now implemented a workaround for the problem but they are still working on finding the origin of the problem to be able to provide a solid solution to the problem.

    I must really say that I’m impressed by Microsoft as they have been very professional and helpful in resolving the Service Pack 1 issues I’ve reported.