Software crashes explained

Software crashes are a common issue that disrupt user activities and can lead to loss of unsaved work. These unexpected shutdowns can be caused by various factors such as bugs in the code, incompatible system updates, hardware failures, or insufficient system resources. They can also suggest that the system hardware is not meeting the software’s requirements.

Addressing these crashes often involves troubleshooting to identify the root cause, which may include reviewing error logs, updating or reinstalling the software, or even upgrading hardware components. In a business setting, these crashes can lead to significant downtime, loss of productivity, and potential data loss.

Check the event log

When a system crash occurs, the Event Viewer can be used for accessing general information. Specifically, application crashes are logged under Event ID 1000. To locate these logs, navigate to Windows Logs > Application within the Event Viewer.

An example of a crash log from Event Viewer:

Faulting application name: Application.exe, version: 1.0.0.1, time stamp: 0x6156aa76
Faulting module name: Application.exe, version: 1.0.0.1, time stamp: 0x6156aa76
Exception code: 0xc0000005
Fault offset: 0x0001eb62
Faulting process id: 0x0x13B4
Faulting application start time: 0x0x1DA65AE0381F4A9
Faulting application path: C:\Program Files\Application\Bin\Application.exe
Faulting module path: C:\Program Files\Application\Bin\Application.exe
Report Id: d766ff6f-bh24-4b93-b1ad-2b52a747d3c7

Sometimes the Exception code will give hints as to where the problem lies. However, quite often you will have to do some more investigation if the exception code leads nowhere.

Enable and analyze crash dumps

The next viable step is to enable crash dumps. Reading crash dumps requires basic knowledge of the dump files. For more information and instructions on how to analyze crash dumps, visit:

Microsoft Learn - Install WinDbg

To enable crash dumps, you will need to edit Windows Registry:

You will need to add three registry values to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps registry key.

In some cases, you may need to create the LocalDumps registry key first.

The values we are adding are as follows:

Name: DumpFolder
Type: REG_SZ
Value: C:\CrashDumps

Name: DumpCount
Type: REG_DWORD (32-bit)
Value: 10

Name: DumpType
Type: REG_DWORD (32-bit)
Value: 2

Alerts_and_warnings-Issue_explanations-2.9.2.png

After the registry values have been added, you need to restart the service called Windows Error Reporting Service.

To perform the whole operation at once, you can use the following PowerShell script. Note that the script needs to be run as an administrator.

# Define the registry pat
$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps"
# Check if the LocalDumps key exists
if (!(Test-Path "$registryPath")) {
   # Create the LocalDumps key
   New-Item -Path "$registryPath" -Force | Out-Null
}
# Define the values to be added
$values = @{
   "DumpFolder" = @{
       "Value" = "C:\CrashDumps"
       "Type" = "String"
   }
   "DumpCount" = @{
       "Value" = 10
       "Type" = "DWord"
   }
   "DumpType" = @{
       "Value" = 2
       "Type" = "DWord"
   }
}
# Add the values to the LocalDumps key
foreach ($value in $values.GetEnumerator()) {
   Set-ItemProperty -Path "$registryPath" -Name $value.Key -Value $value.Value.Value -Type $value.Value.Type -Force
}
# Starts the Windows Error Reporting Service
Start-Service WerSvc

If you can replicate the crashing issue yourself, start the application and wait for it to crash. A DMP file will be created in the DumpFolder you specified above, which in our case is C:\CrashDumps.

Next you will need to download WinDbg. You can download the application from Microsoft Store, or from https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/.

To use WinDbg to analyze dump files, navigate to the following site for instructions: Microsoft Learn - Get started with Windows debugging.

Once you are done debugging, be sure to remove the registry values we added before and clean the C:\CrashDumps folder. It’s advisable to hold on the crash dumps in case they need to be further analyzed or sent to the developer of the software.

Use Process Monitor

Another powerful tool for debugging application crashes is Process Monitor.

“Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. It combines the features of two legacy Sysinternals utilities, Filemon and Regmon, and adds an extensive list of enhancements including rich and non-destructive filtering, comprehensive event properties such as session IDs and usernames, reliable process information, full thread stacks with integrated symbol support for each operation, simultaneous logging to a file, and much more. Its uniquely powerful features will make Process Monitor a core utility in your system troubleshooting and malware hunting toolkit.” -Microsoft Learn

To get started with Process Monitor, visit https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

Update the software

One good way to try to remediate the issue is to update the software to the latest version where applicable. You can use Applixure Analytics to see if the issue is version specific using the Issues Event History found in the software page.

Alerts_and_warnings-Issue_explanations-2.9.3.png

Report the issue to software manufacturer

If the software is a custom line-of-business (LOB) or a third-party application, be sure to report the issue to the developer if it persists. If you have the crash dumps described in section Enable and analyze crash dumps, be sure to include them in your report.

Applixure Analytics warnings and alerts

This issue is associated with the following Analytics alerts and warnings: