Product: TIBCO Spotfire®
How to verify the integrity of a dump file
Often when investigating application crashes, hangs, memory problems, and other issues, it is necessary to capture a dump file for further analysis. Since some dump files can be large, the creation or transfer of these files can cause integrity problems rendering the dump files unreadable. Because of that it is good practice to verify the integrity of the dump files before sending for investigation to ensure that they are usable. Here are a few potential ways to verify a dump file integrity before sending for investigation.
Option 1: Use dumpchk.exeRefer to the following Microsoft KB article for details:
- How to Use Dumpchk.exe to check a memory dump file
Once installed, you can use dumpchk.exe to analyze your dump with a command like (verify the exact installation path first):
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dumpchk.exe" "c:\PathToMyDumpFile\myDumpFile.dmp"
C:\myDumpfiles\dump_PID_2872>"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dumpchk.exe" dump_PID_2872.dmp
If successful, you will see the dump analysis results starting with something like:
C:\myDumpfiles\dump_PID_2872>"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dumpchk.exe" dump_PID_2872.dmp Loading dump file dump_PID_2872.dmp Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\myDumpfiles\dump_PID_2872\dump_PID_2872.dmp] User Mini Dump File with Full Memory: Only application data is available Symbol search path is: srv* Executable search path is: Windows 8 Version 9200 MP (16 procs) Free x64 Product: Server, suite: TerminalServer SingleUserTS Built by: 6.2.9200.16384 (win8_rtm.120725-1247) Machine Name: Debug session time: Tue Sep 13 12:42:49.000 2016 (UTC - 4:00) System Uptime: 14 days 23:17:05.012 Process Uptime: 0 days 18:54:58.000
If the file is corrupt, you may see something like:
C:\myDumpfiles\dump_PID_4148>"c:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dumpchk.exe" dump_PID_4148.dmp Loading dump file dump_PID_4148.dmp Microsoft (R) Windows Debugger Version 10.0.10586.567 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [T:\agavare\dump_PID_4148.dmp] Minidump does not have system info Could not open dump file [dump_PID_4148.dmp], HRESULT 0x80004005 "Unspecified error" **** DebugClient cannot open DumpFile - error 80004005
Ensure the Debug Diagnostic Tool is installed. You can download that from Microsoft from here:
Option 2: Use Debug Diagnostic Tool
- Open "DebugDiag 2 Analysis" application
- Select Default Analysis > CrashHangAnalysis
- Click "Add Data Files" and browse to the .dmp file
- Click "Start Analysis"Right click on the dump "Analyze Crash/Hang Issue"
- Right click on the dump "Analyze Crash/Hang Issue"
Option 3: Compare a file hash before and after transferIf the original dump file is confirmed to be valid (using Option 1 or Option 2 above), then it might be necessary to ensure the file has not been corrupted in the transfer. You can use the same methods as described above, or use a program that generates a hash of the file and compare the hash of the original version with the copied version in the destination location. If the file is identical, as it should be, the two hashes should be identical. There are many programs that you use can use to generate a hash of a file, for example:
md5sum (Linux and Windows versions available):
$ md5sum dump_PID_9734.dmp > hash.md5
External: How to Use Dumpchk.exe to check a memory dump file