In this tutorial I will show you how you can easily analyze a User Mode Process Dump. This tutorial is intended for beginners. In this example I will use the “Debug Diagnostic Tool v2 Update 3“. This tool was previously designed to analyze only IIS Process Dumps but now you can use it to analyze any kind of User Mode Process Dump. The reason why I use DebugDiag is because its doing nearly all the work automatically and showing you the results as a report therefore DebugDiag is the best User Mode Dump Analysis Tool for beginners.
You can download the latest Version of “DebugDiag” from the link below :
“Debug Diagnostic Tool v2 Update 3”
Debug Diagnostic Tool (DebugDiag) is designed to assist in troubleshooting issues such as hangs, slow performance, memory leaks or memory fragmentation, and crashes in any user-mode process.
As you know to analyze a user mode process dump you normally have to know how the process you analyze works, behaves and which components it loads furthermore what all these components does. Only after that, if you take a look at the active threads at the top of the stack and at the loaded modules you can say something definite about the root cause of the problem.
In this tutorial I will show you quickly how you can get an inside and a first look into the problematic process and what you can do without studying the process and all it’s related components. In this example I have send a print job to my Canon printer and paused it. Afterwards, I created a User Mode Process Dump from the Spooler process "spoolsv.exe" over the Task Manager > Right click the Process > and select “Create dump file”.
I assume that you already have a process dump on the hand.
Once “Debug Diagnostic Tool” has been installed on your PC please proceed as follows :
1. Please click “DebugDiag 2 Analysis”.
2. Select the “CrashHangAnalysis” checkbox and add the path to your process dump. Afterwards click “Start Analysis”.
3. DebugDiag will begin to analyze your dump file.
4. Once done the Analysis Report will show up. As we can see in this example we have one Warning and Information event.
5. If we now take a closer look at the problematic areas we can see that DebugDiag has brought 3 threads from the stuck in front of us. It’s the 24, 31 and 32 numbered threads. Furthermore it says that the 32nd thread is blocked.
6. If we now take a look at the thread 32 we can see that the Entry Point is "localspl!PortThread". I know that LocalSpl is a Dynamic Link Library and it’s the Local Print Provider in Windows. If we print anything locally this component is the one who manages the print job. If we would print to a shared network printer "Win32spl!PortThread" would show up here. Win32spl is the remote print provider responsible for printing to remote printers. If we take a look at the calls we can see that at the top of the stack it’s saying something with wait "ntdll!AlpcSendWaitReceivePort+14". This is because I paused the print job and created a User Mode Dump from the Spooler Process.
7. If we take a look at Thread 31 we can see the the print job has been submitted "localspl!SplWritePrinter" and my Printers Print Monitor which is a Canon has been initialized but is waiting. This is because I set the print queue on pause.
As a result, a little bit knowledge of the process and the loaded module (DLL’s) by the process is required. You can basically google with the thread names if you don’t know what the active threads are doing or what they are responsible for.
Good luck !