Under Windows, an error with our software may cause the individual program to crash or in more extreme circumstances the error could cause the system to crash, often referred to as a Blue Screen Crash or BSOD. In both cases we will need a system memory dump at the time the crash occurs to investigate the issue. This document covers both types of crashes.
On occasions software might crash. The term crash has a specific meaning and this article only applies to crashes; not general malfunctions.
A crash indicates that a software module has stopped executing unexpectedly. There will usually be a message to this effect; either a dialog window, or in the Windows system event log - in this case UPDD daemon crashing in Windows XP.
To analyse a program crash we will need as a minimum a minidump. Do not Close the dialog until you have located and moved/copied the minidump as this is often deleted when the dialog is closed.
If enabled the system will automatically take a mini dump and the path to the mini dump will be shown under the 'technical information' link along with some other useful information.
Please send the mini dump along with any other information listed.
Additional important information
If working on a system with JIT (Just in Time debugging) installed then you might be prompted to open or select a JIT debugger; or 3rd party software might suppress the message altogether or even shut down the system.
The actual dialog shown will vary according to the Windows version and configuration, but this is an example taken from a Window 7 system with JIT installed.
If you are utilising custom exception handling software then the behaviour will likely be modified and you should consult the appropriate reference.
Because UPDD components utilise structured exception handling; which treats system errors as software exceptions; most if not all crashes will be reported as "unhandled exceptions"
In reporting such an issue, the information about the exception itself does not provide sufficient context to diagnose the issue.
We will always require a minidump and in some situations a full process memory dump to diagnose a crash on Windows.
Depending on the configuration of your system you might find a minidump in the folder <windows>\minidump; or at a location mentioned in the error dialog (click view problem details in the dialog above).
Note in the latter case the dump is typically deleted when the dialog is closed. Also note that ONLY the dump files (typically suffixed .dmp or .mdmp) are useful. If there are multiple dmp files please only send relevant files (i.e. this timestamped around the time of the reported error) as analysis of these files can be time consuming and this will avoid analysis of possibly unrelated issues.
There are cases where these files cannot be obtained the procedure below allows a minidump to be captured in such cases.
Since UPDD V6 482 UPDD processes now utilise their own exception handlers. When an exception occurs the handler will take and store a mini dump to the UPDD dump file folder and the driver will automatically restart. A setting is set to indicate a crash occurred. If the UPDD diagnostic procedure is run the resultant diagnostic files will allow us to see that a crash occurred (UPDD global setting collected_error_count) and will also contain the dump files. Dump file collection can be disabled by setting the UPDD global setting disable_error_collection.
Using procdump to capture log files
Firstly download "procdump"
From the downloaded file extract procdump.exe (NB as the updd software is mainly 32 bit please use this and not procdump64.exe unless advised otherwise).
In a command window with admin privileges enter the following commands:
procdump –mp -i c:\dumps
The dump is requested as follows: in the control panel -> system -> advanced -> startup and recovery. Select small memory dump.
After a BSOD the dump file will be located in SystemRoot%\Minidump (or whatever was set in the control panel).
Send the file related to the crash using the timestamp of the file to determine the correct file.