Tag: Crash

This blog post is an example of a problem I encountered the other day in a project I am in. An application that is used by a part of the business is installed properly but crashes. I thought I’d share some tips and tricks based on this troubleshooting, a troubleshooting which turned out to be a true sunshine story.

Problem

A ClickOnce application is installed in Windows 10 and 11 but when trying to start the application it never starts and instead silently crashes.

Investigation

As always when something crashes, more details can be found in the Event Viewer. The event ID 1000 lists some very general information:

Faulting application name: X.Y.Client.WpfClient.exe, version: 1.0.0.0, time stamp: 0x565f048b
Faulting module name: KERNELBASE.dll, version: 10.0.25357.1, time stamp: 0xc0dc8053
Exception code: 0xe0434352
Fault offset: 0x0014e0a4
Faulting process id: 0x0x473C
Faulting application start time: 0x0x1D9824B72D664C7
Faulting application path: C:\Users\andre\AppData\Local\Apps\2.0\KP6YOQBZ.QBT\10VX2RL2.D3R\X...tion_ae3633e36a16d69b_0004.0000_6d9d02277ead5c24\X.Y.Client.WpfClient.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll

This in turn gives me nothing more to go on so next thing to do to get more information is to enable crash dump file generation for application crashes (or any other crashes apart from Windows crashes which already have dump files generated each time Windows crashes).

Enable crash dumps

Go to the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting

First Create a key named LocalDumps so that you end up with this key:

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

Then in the LocalDumps registry key create these three registry values:

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

Restart the service named “Windows Error Reporting Service” and then start the application and note the DMP file created in the location that you specified above.

Analyze crash with WinDbg

Now we can analyze the DMP file with the classic tool Windows Debugging Tools. This is available in Windows ADK and SDK but the easiest way is to install WinDbg (Preview) via Store (or publish to Company portal). You can also use the winget command to install WinDbg by using “winget install 9PGJGD53TN86“.

Start WinDbg and then open the DMP file and choose:

!analyze -v

We can then clearly see some interesting exceptions:

Key  : CLR.Exception.System.ArgumentException._message
Value: Source property was not set before writing to the event log. 
Key  : CLR.Exception.System.Security.SecurityException._message
Value: The source was not found, but some or all event logs could not be searched.  Inaccessible logs: Security.

This, plus the below entries also found as a result of analyzing the DMP file, clearly points toward event logs and specifically the security event log.

STACK_TEXT:
00f8eedc 64b54041 System_ni!System.Diagnostics.EventLogInternal.WriteEntry+0x16bc4d
00f8ef0c 649e53f9 System_ni!System.Diagnostics.EventLog.WriteEntry+0x19
00f8ef18 0314223b X_Y_Client_Business!X.Y.Client.Business.Logger.WriteToLog+0x103
00f8f034 0314211d X_Y_Client_Business!X.Y.Client.Business.Logger.WriteToLog+0x25

Process Monitor for the win!

To figure out what is going on I turn to my personal favorite tool named Process Monitor, a tool that has helped me troubleshoot and learn stuff about Windows for many years.

In Process Monitor, I did a simple recording and filtered on “Access denied”. The application process showed one access denied entry.

The application need read permissions on the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\security 

Said and done, I set users to “Read” on the registry key and started the application again. It crashed still.

I did another trace with Process Monitor and this time it showed that read/write permissions was required on the registry key above security. Strange, but I set Users to Full Control on the registry key referenced:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog

I once again tried to start the application and after that, the application started! Note: The good(?) thing is that after first start, one can revert the permissions to default permissions and the application still work. More investigation is needed in this area.

Summary

A few tools, tips and tricks were involved in this troubleshooting, and I hope to inspire others to use these tools and methods in their own troubleshooting in day-to-day work. My next step now is to contact the developers of the application and point out the rather strange problem, and hopefully get the problem fixed.

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 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.