Dumps are used for postmortem analysis, which is sometimes the most effective means of debugging an application. When a program intermittently crashes, postmortem analysis might be the sole way to resolve the problem. With tools such as ADPlus, you can specify that a dump be created whenever a crash occurs, even if the application is unattended. Then the dump can be used to diagnose the problem. Production applications are not ideal for live debugging. How do you perform live debugging on an active Web server? Convenience is another advantage to postmortem analysis. You can move the dump to a developer machine, where there are a host of debugging tools and resources. In this environment, diagnosing the problem is much easier.
There are full dumps and minidumps. A minidump is a partial snapshot of the application memory, which consists of the primary module. Full dumps also include other modules in the memory snapshot—even system modules. The benefit of a full dump is convenience, and symbols are aligned more easily. The disadvantage is that full dumps tend to be large. Not all minidumps are equivalent—some contain more information than others. Check the documentation for the command or tool that creates the minidump to see what options are available.
Remember that memory dumps are static. The debugging paradigm is different from performing live debugging. For example, you cannot step through the application, set breakpoints, or change the state of the application.
As documented earlier, the .dump /ma directive in WinDbg creates dump files that can be used with SOS. Dump files also can be created with ADPlus and other tools.
The ADPlus tool can be downloaded from the Debugging Tools for Windows Web site. It is a Microsoft VBScript file that automates the CDB debugger. Use ADPlus to automate the creation of dumps for applications. ADPlus operates in either crash or hang mode, and it creates other files, such as log files, to aid in postmortem analysis. Unique names are assigned to the dump and other files to avoid overriding previously generated files.
In crash mode, ADPlus attaches CDB to the target processes. You will see that CDB is minimized on your desktop. It is attached invasively to the target application. Run ADPlus before the application crashes. When a crash occurs, a minidump and a log file are created. ADPlus also will generate an entry in the Event Log. A crash is interpreted as the application ending from an unhandled exception. To detach prematurely before a crash, open the minimized CDB console and press Ctrl+C. ADPlus can attach CDB to multiple processes simultaneously. The debugger attaches all instances of the named processes. Here is the syntax for running ADPlus in crash mode:
adplus –crash –pn processname1 –pn processname2 ... –pn processnamen
Alternatively, the process identifier can be used to identify a specific instance:
adplus –crash –p pid –p pid ... –p pidn
In hang mode, run ADPlus after the hang occurs, which attaches CDB to the target application noninvasively. You must decide when the application is hung (a somewhat subjective call) and then apply ADPlus. The debuggee is resumed after the dump is created. Here is the syntax to start ADPlus in hang mode, where pn is the process name and pid is the process id:
adplus –hang –pn processname1 –pn processname2 ... –pn processnamen
adplus –hang –p pid1 –p pid2–p ... pidn
These are other important options:
O(utput) option. This option sets the output directory for dump and log files.
Q(uiet) option. This option suppresses alerts from ADPlus.
N(otify) option. This option notifies a user when an application has crashed.
C(onfiguration) option. This option associates a configuration file, which describes the behavior of ADPlus.
iis option. This option is for debugging Web servers. It is applicable with Microsoft Internet Information Server (IIS) 4.0 and later.
In this example, the Store application has an error and unexpectedly crashes. ADPlus is used to create a dump when the application crashes. The dump then is opened in WinDbg, and the problem is isolated.
Start the Store application in the Adplus subfolder.
Click Hang. As expected, this action hangs the application.
Run ADPlus in Hang mode to attach the CDB debugger to the Store application and create a dump. (Get the correct process identifier for the Store application using the Tlist utility.)
C:store>adplus -hang -p 3520 -o c:dumps Attaching the debugger to: STORE.EXE (Process ID: 3520)Start WinDbg and open the dump. From the File menu, select the Open Crash Dump command. From the dialog box, find and open the dump.
Load the SOS debugging extension. Change to Thread 0 and show the call stack. The following is a partial listing of the call stack. It shows correctly that the btnHang_Click handler was the last method entered. This provides a starting point in uncovering the problem that caused the hang:
0:000> .load sos 0:000> !clrstack OS Thread Id: 0xae8 (0) ESP EIP 0012f030 00de0906 Store.Form1.btnHang_Click(System.Object, System.EventArgs) 0012f044 7b070a8b System.Windows.Forms.Control.OnClick(System.EventArgs) 0012f054 7b114cd9 System.Windows.Forms.Button.OnClick(System.EventArgs) 0012f060 7b114ddf System.Windows.Forms.Button.OnMouseUp(System.Windows.Forms.MouseEventA 0012f084 7b0dfeea System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Messa 0012f0d0 7b082bbf System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message By 0012f0d4 7b09149e [InlinedCallFrame: 0012f0d4] 0012f170 7b0913bb System.Windows.Forms.Button.WndProc(System.Windows.Forms.Message ByRe 0012f178 7b08a70d System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System 0012f17c 7b08a6e6 System.Windows.Forms.Control+ControlNativeWindow.WndProc(System. 0012f190 7b08a535 System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntP 0012f324 003420d4 [NDirectMethodFrameStandalone: 0012f324] System.Windows.Forms.Uns 0012f334 7b094682 System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32, Int32, Int32 0012f3d4 7b094249 System.Windows.Forms.Application+ThreadContext.RunMessageLoopInne 0012f440 7b094087 System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int 0012f470 7b0d66ea System.Windows.Forms.Application.Run(System.Windows.Forms.Form) 0012f480 00de00a8 Store.Program.Main() 0012f69c 79e80b8b [GCFrame: 0012f69c]