Troubleshooting an application that crashes in Windows – a few tools, tips and tricks

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.


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


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

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:


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:


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.


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.