Crash Logs
It is inevitable that software will occasionally fail, sometimes in a controlled and predicted manner that can be catered for within the software itself, and more rarely in an unexpected and uncontrolled manner such that the software will either lock up or just unexpectedly terminate.
When an application crashes in an unexpected manner the operation system will often create some form of log or dump files to help developers investigate the reason for the crash.
These documents describe how to identify or create the crash files to aid with crash investigations:
Windows
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.
Program crash
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 for updd v6 or procdump64.exe for updd v7.
For updd v7 replace references to procdump in the text below to procdump64.
In a command window with admin privileges enter the following commands:
md c:\dumps
procdump –mp -i c:\dumps
BSOD crash
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.
MacOS
Under MacOS if a program locks up the system shows a revolving beach ball when the app has focus or if a program crashes functionality will be lost and related visual references, such as menu bar icons or dialogs will just disappear.
In both cases it is possible to retrieve a crash or spin log that should be sent to us ([email protected]) to help with our investigations into the issue along with any information needed to help reproduce the problem.
Crashes
If a crash occurs, or is thought to have occurred, with one of our components, be it the driver or an add-on component such as the UPDD Daemon, Commander extensions then the system may create a crash log located in one of two areas, depending on a user or system component crash:
User component crash (UPDD Daemon, UPDD Calibration, UPDD Commander etc)
If this is the case there should be a crash log located in the user-level library folder (hence the ~ character) at the following path: ~/Library/Logs/DiagnosticReports
It will include the name of the crashing component, such as: "UPDD Commander_[timestamp]_[computer name].crash” as per the example below or [app name]_[timestamp].ips (macOS 12 and above):
System component crash (driver)
If this is the case there should be a crash log located in the system level library folder at the following path: /Library/Logs/DiagnosticReports
It will include the name of the crashing component, such as: "updd_[timestamp]_[computer name].crash” or [app name]_[timestamp].ips (macOS 12 and above):
Depending on the OS version in use the ‘Library’ folder may be hidden by default. To locate the Library folder, choose 'Go to Folder' from Finder’s 'Go' menu and type:
~/Library/Logs/DiagnosticReports/ or /Library/Logs/DiagnosticReports/
If the library folder is hidden and should you wish to make it permanently visible type the following command in Terminal:
e.g. chflags nohidden ~/Library – this works for in Mac OSX Lion – it may be slight different for other OS versions.
Lockups
When the beach ball is displayed when focusing on a menu bar icon or application dialog then the application has locked up. Sometimes a lock up may force the application to eventually crash in which case a crash log as described above will be created. In other cases the beach ball will remain until you manually Force Quit the program:
A locked up program will be listed in red text in the list of programs.
However, prior to forcing the program to quit you can take a 'spin log' that will help identify the position within the program that has caused the failure. To do this highlight the locked program in the Activity Monitor, it will be listed in red text as (Not Responding). In this instance you can run 'Sample Process' and 'Run Spindump' and send us the output/log from both requests. The spin log will be found in one of the Library folders with the suffix .spin:
Sample request
Occasionally it may be appropriate to take a sample request to try and capture a specific application process, such as excessive CPU usage.
In this case you may wish for the sample to be taken over a period of time.
This can be achieved by starting a sample request from the command line and specify how long it should last using a command in the form:
sample "process name" 30 -f ~/Desktop/updd_sample_filename.txt
For example:
sample "UPDD Daemon" 30 -f ~/Desktop/updd_daemon_sample.txt sample "UPDD Commander" 30 -f ~/Desktop/updd_commander_sample.txt sample "updd" 30 -f ~/Desktop/updd_sample.txt
The second parameter is the number of seconds to take the sample for, so this example the command will sample for 30 seconds and save the file to the desktop.
Its possible there's more than one UPDD process with the same name if there are multiple accounts logged in at the same time. However, the sample command will pick the process for the current user which is the required sample.
Last updated