M09 Post-Mortem Debugging - pudn.comread.pudn.com/downloads181/ebook/846936/User Mode...2...

Contents

Overview 1

Lesson 1: The USER.DMP File 2

Lesson 2: Loading USER.DMP 11

Lesson 3: Live vs. Post-Mortem Debug 15

Lab: Post-Mortem Debugging 20

Post-Mortem Debugging

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, places or events is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. © 2002 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Windows, Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Post-Mortem Debugging 1

Overview

To insert the standard Overview slide, position the cursor within the following blue text, and then press F3.

2 Post-Mortem Debugging

Lesson 1: The USER.DMP File

To insert a new slide, position the cursor in the following paragraph. Then, on the Presentation menu, point to Insert Slide, and click the appropriate slide.

This lesson explains what a USER.DMP file is and mentions the four methods for generating a USER.DMP file.

What You Will Learn After completing this lesson, the student will be able to:

• Explain what a USER.DMP file is

• Explain four ways that a USER.DMP file can be generated


What is a USER.DMP File?


A USER.DMP file is a file that contains a user mode process’ address space at the time the file is generated. This file is typically generated by DRWTSN32 when a fatal error occurs. It can also be generated in other ways in order to gain extra insight into what a particular process is doing at a specific moment in time. A USER.DMP file contains useful information such as:

• Call stack at the time of the crash for each thread of the user mode process

• Register settings

• Entire address space for the user mode process, which can include:

• Source code (ASP)

• Full module contents (DLL Binaries)

• User names and passwords

• Database connection strings

• Metadata for .NET code

User-mode crash dumps can actually be named anything, but USER.DMP is the default naming convention used by DRWTSN32. Thus, user-mode crash dumps are typically referred to as a "user dump" or "USER.DMP".


How are USER.DMP Files Generated?


Four Ways to Generate a USER.DMP File USER.DMP files are typically generated by DRWTSN32.EXE when a user mode process encounters a fatal error on a machine that has been configured to generate crash dumps. However, there are three additional methods available for generating USER.DMP files.

The four methods for generating a USER.DMP file are:

• DRWTSN32.EXE • WinDBG ".dump" command • ADPlus.vbs • DebugDiag


DRWTSN32 Configuration for dump

Dr. Watson is the most common creator of user-mode crash dump files.

Dr. Watson defaults to creating crash dump files along with a DRWTSN32.LOG file when an application encounters an error. There are many user-configurable options that turn these features on and off and running DRWTSN32 with no command-line options will present a dialog for these options. If Dr. Watson has been configured to be the default debugger, the log and crash dumps will be created in the directories specified in DRWTSN32 which, by default, is the %windir% directory (C:\WINNT on most machines).

As of Windows NT 4.0 Sp5, running DRWTSN32.EXE –P <PID> will cause Dr. Watson to attach to an active process, take a process dump and exit. (This is very similar to what the DOTCRASH program does.)


Windbg’s .dump Command


Windbg contain a feature that provides for the instantaneous generation of a crash dump file while debugging a process. This can be very useful since the state of the process can be saved for further analysis at a later date. The crash dump is generated when the process you are debugging is stopped by the debugger and the following command is issued in the WinDbg command prompt:

.dump <options> <path\filename>

For example, if Windbg is launched and currently attached to NOTEPAD.EXE, and the process has been halted in the debugger, a command to generate a complete (mini + all options) dump with unique dump file name can be typed in the Windbg command prompt window:

.dump /ma /u c:\user.dmp

Windbg can also be used to attach “non-invasively” to a process, which allows you to dump out a processes memory to file and then detach without stopping the process.


ADPlus.vbs

ADPlus.vbs is a script file written in the Visual Basic Scripting language. The script file is used to create a CDB.exe window that attaches to one or more processes and generates dump files either instantly or when an exception occurs.

Here are some of the more useful command line options that you can use with ADPlus:

• -quiet Suppresses all modal dialog boxes

• -c <file> Allows the use of a configuration file

• -hang Runs in “hang” mode, causes a dump file to be created immediately

• -crash Runs in “crash” mode, monitoring for exceptions

• -iis Used to attach to all IIS related processes. Should be used in conjunction with –crash or –hang

• -pn <process> Attach to the process of a specific name

• -p <PID>

•

Attach to a process using the process ID

• -o <dir>

•

Output the files to the specified directory

• -ce <exception> Monitor for specific exceptions

• -FullOnFirst Generate a full dump on first chance exceptions

• -bp <breakpoint>

Setup a breakpoint to be used by the debugger

A configuration file can be used to eliminate the need to include all the necessary command line options. The format of the configuration file is as follows:

ADPlus>  <Settings>  </Settings> <PreCommands>  </PreCommands> <PostCommands>  </PostCommands> <Exceptions>  </Exceptions> <Breakpoints>  </Breakpoints> <HangActions>  </HangActions> <LinkConfig> <!-allows to link to another config file --> </ LinkConfig > </ADPlus>

Information on what should be placed each section of the configuration file can be found in the debuggers help file, debugger.chm, found in the debugger installation directory.

Note


DebugDiag.EXE


The Debug Diagnostic Tool is a tool designed to help troubleshoot performance issues with Internet Information Services (IIS). Even though the tool was designed with troubleshooting IIS in mind it can be used to identify performance issues for any process.

The main window of the tool has three different tabs used for data collection and analysis. For data collection, rules are configured for the type of problem you are troubleshooting. The advanced analysis portion of the tool is used to analyze and report helpful information on the data that is collected. There is also a Processes view that allows you to view processes, collect dumps, and stop processes that are running on the machine.

The three primary problems the tool aides in troubleshooting are process crashes, process hangs, and memory leaks.

• Process Crashes The crash monitoring feature is designed to help determine why a process terminated unexpectedly. Similar to previous debuggers it will attach to a specific process and will monitor the process for multiple types of exceptions that cause a process to terminate unexpectedly. When a crash occurs, a full memory dump file will be created, in the directory specified when setting up the crash rule, for troubleshooting.

• Process Hangs The hang monitoring feature is designed for troubleshooting performance issues when users browse to pages in a web application and the pages take a long time to respond, or do not respond at all. To troubleshoot a hang, a hang rule is created where a specific URL is monitored. The debug tools will send a request to this URL at configured intervals, and if the URL does not respond in the configured time a process dump will be generated for the processes configured in the hang rule. A manual hang dump can also be generated by right clicking a process in process view and choosing create full dump.


• Memory Leaks The memory leak monitoring feature is designed to track memory allocations for a process. This feature should be used when a process on the system continues to grow in memory until the system becomes un-stable, or the process stops functioning correctly. The debug tool will inject a DLL into the specified process and monitor memory allocations over time. A dump is then generated, and the dump is analyzed to determine what allocations are not being freed and most likely causing the memory leak. Allocations generally fall into 3 groups: caching, short term allocations that will be freed later, and memory leaks. All three allocation methods have very distinct allocation patterns when measured over time. The leak tracking feature calculates a leak probability using a formula that is based on these allocation patterns as measured over a specific time period.

The tool also provides an extensible object model that exposes information necessary to analyze crashes, hangs and memory leaks. The object model is implemented in the form of COM objects and provides a script host with a built-in reporting framework.

Algorithmic analysis of issues will be built using ASP style scripts written using VBScript or Jscript that consume the object model and provides an easily understandable and actionable summary of the problem using a built-in reporting framework.

Please see the Users Guide for information on how to configure the tool for data collection, run analysis, and interpret the reports.

Download: IIS Diagnostics Toolkit

http://www.microsoft.com/downloads/details.aspx?FamilyID=9bfa49bc-376b-4a54-95aa-73c9156706e7&DisplayLang=en


Lesson 1: Review


1. Name three things stored in a USER.DMP file.

2. Name four methods of generating a USER.DMP file.

3. How can you capture a full user dump on first chance exceptions?

4. Which debugger can also analyze user dumps?


Lesson 2: Loading USER.DMP


This lesson will explain which debuggers can load USER.DMP files and how USER.DMP files are loaded.


• List which debuggers can load USER.DMP files

• Explain how to load a USER.DMP file into Windbg

• Explain how to load a USER.DMP file into DebugDiag

• Explain how to load a USER.DMP file into Developer Studio


Loading a USER.DMP file – Windbg/DebugDiag


There are many debuggers that can open a USER.DMP file. We will cover just a few here:

• Windbg.exe (most commonly used) or cdb.exe • DebugDiag.exe • Visual Studio


Loading a USER.DMP File – Visual Studio


USER.DMP files are typically loaded and analyzed in Windbg, but Visual Studio works as well. It is not required that symbols be installed on the machine that generated the crash dump at the time of the failure, but it is necessary to have the appropriate matching symbols available for the debugger when debugging a crash dump.

Before loading a crash dump in the debugger, make sure that you have built a symbol tree with symbols that match the versions used by the customer’s server at the time of the failure. Once you have all of the appropriate symbols available for your debugger, you can load and begin analyzing the crash dump with all of the pertinent symbolic information available.

To Load user.dmp file in WinDbg, follow the following menu selections:

File | Open Crash Dump ( or CTRL+D )

To Load user.dmp file in DebugDiag, follow the following menu selections:

Advanced Analysis tab | Add Data Files button

Start analysis:

select “Category” item in “Available Analysis Scripts” tab

Click “Start Analysis” button

To Load user.dmp file in Visual Studio, follow the following menu selections:

Visual Studio 2003 .NET/Visual Studio 2005:

File | Open | Project … select dump file


Right mouse click on the selected project, select:

Debug | Start new Instance

For Visual Studio 6.0, this feature is disabled by default. A Registry value (DWORD) must be created under

HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Debug

The DWORD value that needs to be created is called:

CrashDumpEnabled

This DWORD value should be set to 1 in order to enable this feature.

You will now be able to open .dmp files in Visual Studio by clicking File Open Workspace… and selecting Dump Files from the File Type dropdown list.

Important


Lesson 2: Review


1. Name three debuggers used to debug user mode crash dump files

2. What is the registry value that must be manually created in order to allow Developer Studio 6.0 to load crash dumps?


Lesson 3: Live vs. Post-Mortem Debug


This lesson will explain the differences between a live debug and a post-mortem debug.


• Explain the differences between live and post-mortem debugging.

• Explain how explain how extensions are useful for post-mortem debugs.


Differences Between Live and Post-Mortem Debugs


Crash dump debugging is also referred to as a post-mortem debug. Post-mortem debugging applies to both kernel crash dumps (memory.dmp) and user mode crash dumps (user.dmp). This discussion pertains specifically to the differences between live and post-mortem user mode debugging. The main differences between live and post-mortem debugging are the following:

• A post-mortem debug is a frozen snap shot in time of what was in the user mode processes’ address space at the time of failure.

• The user does not have to attach to a process while debugging a crash dump.

• No code is being executed during a post-mortem crash since the debug information is static.

• The user cannot set breakpoints when debugging a crash dump since the process is not running.

• The user does not have to worry about losing the state of the process at the time of failure with a crash dump since the information in the crash dump is static.

Post-mortem debugging is much more forgiving than live debugging since there is no worry about losing the repro in the debugger. However, the user is limited to the data in the file and cannot modify the program’s behavior in the debugger like a live debug.


Debugger Extensions


A debugger extension is a tool to help automate repetitive tasks in the debugger, for instance, walking and dumping memory structures in order to capture important data. Or, suppose you wanted to find all of the currently executing ASP pages in a dllhost.exe process. It would be very time consuming to find all the ASP threads and search each one for the Page that is executing. You could use a debugger extension to perform this tedious task, and have your answer instantly.

How to use Extensions .load <Filename> – will load an extension

.chain – will supply a list of loaded extensions

.unload <Filename> – will unload an extension

!<extension>.Help – will display a list of the Commands that it supports.

A debugger extension does not have to export a Help function but all good debugger extensions will have one unless the extension otherwise wishes to remain private.

An SDK ships with the Debugging Tools for Windows which provides a framework for developers to write their own debugger extensions. The following are a few custom extensions that provide some extremely useful functions.

Note


Common Extensions


dbghelp.dll, ext.dll, exts.dll, uext.dll, and ntsdexts.dll are debugger extensions that ship with the Debugging Tools for Windows package and provide some useful commands. These extensions are automatically loaded when the debugger starts.

0:000> .chain Extension DLL search Path: c:\debuggers\winext; Extension DLL chain: dbghelp: image 6.6.0007.4, API 6.0.6, built Mon Jul 03 14:38:12 2006 [path: c:\debuggers\dbghelp.dll] ext: image 6.6.0007.4, API 1.0.0, built Mon Jul 03 14:37:41 2006 [path: c:\debuggers\winext\ext.dll] exts: image 6.6.0007.4, API 1.0.0, built Mon Jul 03 14:37:36 2006 [path: c:\debuggers\WINXP\exts.dll] uext: image 6.6.0007.4, API 1.0.0, built Mon Jul 03 14:37:49 2006 [path: c:\debuggers\winext\uext.dll] ntsdexts: image 6.0.5457.0, API 1.0.0, built Mon Jul 03 14:53:41 2006 [path: c:\debuggers\WINXP\ntsdexts.dll]


Custom Extensions – sieextpub.dll

Sieextpub.dll was written by various former members of the Solutions Integration Engineering team at Microsoft. This debugger extension is provided “as is” with no support.

SIE Extension - Version 1.8.2 !kdall = Executes kd for the full range of current thread's stack !kdsym = Raw stack with only matching symbols !filevers = Show version and paths of all loaded modules !imports <module> = List all imports for the module !critlist = List CritSecs that threads are waiting on !waitlist = Lists handles each thread is blocking on !sr2 <addr> = Get target process/thread from 1st param of SendReceive2 !waitreply <addr> = Get target process/thread from 2nd param of RequestWaitReplyPort !comcalls = Show COM calls on all threads !vbcheck <module> = Check Unattended Execution/Retained In Memory settings !vbcheckall = Check UE/RIM settings on all modules !stackrange = Shows start/end stack addresses of current thread !rangesearch = Search an address range for values within a range !showstring <addr> = Prints an ASCII string !showstringw <addr> = Prints a double byte string !showvariant <addr> = Shows the contents of a variant object !showctime <val> = Converts a ctime DWORD to a string Step commands repeat a command from a starting address. Use %x and %d as placeholders in command. For example: !stepptr 04002C34 4 dc %x !stepval <val> <count> <cmd> = Repeats command on each value !stepptr <addr> <count> <cmd> = Repeats command on each pointer


Custom Extensions – mdacextspub.dll

mdacextspub.dll was written by the MDAC/WebData Critical Problem Resolution team at Microsoft. This debugger extension is provided “as is” with no support.

It includes many very useful functions in following categories:

• Memory Searching Functions

• Heap+Virtual Memory Functions

• Thread Functions

• COM Functions

• List Processing Functions

• .NET Functions

• Other Miscellaneous Functions

Please run !mdacextspub.help for more information about the commands that the debugger extension provides.


Custom Extensions – iisinfo.dll

iisinfo.dll was written by the IIS Critical Problem Resolution team at Microsoft. This debugger extension is shipped with DebugDiag and provides quite a few useful IIS specific functions to aid in debugging web related issues.

ISInfo.dll - DebugDiag/WinDBG hybrid extension for IIS and ASP information.

----------------------------------------------------------------------------------------------

Usage:

!clientconns - Active client connections

!asprequests - ASP request information about all executing ASP requests

!asprequest [<CHitObj>] - ASP request information executing on current thread or specified

optional CHitObj address

!templates - All cached templates

!aspstack - Script call stack for the ASP page running on the current thread

!asppages - ASP page running on all threads

!asptemplate <CTemplate> - Detailed information and include heirarchy for the specified

template

!templatecode <CTemplate> - Compiled template code or expanded code for the specified template

!includecode <FileMapKey> - Compiled template code or expanded code for the specified include

file

!aspapps - Loaded ASP applications

!aspapp <CAppln> - Detailed information for the specified ASP application

!appvars <CAppln> - Variables stored in the specified ASP Application collection

!sessions <CAppln> - Active sessions in the specified ASP application

!session <CSession> - Detailed information about the specified ASP session

!sessvars <CSession> - Variables stored in the specified ASP Session collection

!help - Shows this help

Options:

[-v|-x] - Verbose mode. Displays extra information for most commands

-----------------------------------------------------------------------------------------------


Lesson 3: Review


1. Do you have to attach to a process when debugging a crash dump file?

2. Can you set breakpoints while debugging a crash dump file?

3. How do you load and unload custom extensions?


Lab: Post-Mortem Debugging

To insert the standard Lab slide, position the cursor within the following blue text, and then press F3.

M09 Post-Mortem Debugging - pudn.comread.pudn.com/downloads181/ebook/846936/User Mode...2...

Documents

Transcript of M09 Post-Mortem Debugging - pudn.comread.pudn.com/downloads181/ebook/846936/User Mode...2...