Tag: WinDbg

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.

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.

Windows 10: How to figure out what the blue screen of death is caused by

Having deployed many thousands of Windows 10 machines over the last year I must say that I am surprised by the large number of blue screens that have occurred and still occur on Windows 10. As always, hardware issues surface when deploying a new OS, but the vast majority of blue screens that occur are actually caused by bad drivers.

Things are shaping up and nowadays Windows 10 and its drivers are more stable then a year ago but still there are quite a few blue screens caused by primarily bad graphics drivers and not to mention WiFi drivers from the most prominent chipset maker in the business.

Therefore I have made some updates to this popular guide – troubleshoot and analyze blue screens of death – how to figure out what the infamous blue screen of death is caused by.

Updating drivers on an active basis is very much necessary in terms of deploying and managing Windows 10 if you want to keep blue screens away!