Over the last few weeks, we’ve been posting quite a bit on different topics related to Debugging . Today we’re continuing in that vein by looking at one of the most common commands that we use when reviewing both kernel- and user-mode dump files – !analyze . !analyze is an extension command that performs a number of automated analysis steps and displays information about the exception or bug check in the dump file. There are a couple of different parameters that you can use, depending on whether or not you are debugging a kernel- or user-mode dump file, but the one that you will probably use most often is – v which shows the verbose output. As with our other posts on debugging commands, let’s go through the parameters first, and then take a look at some examples:
|-v||Displays verbose output|
|-f||Generates the !analyze exception output. Use this to see an exception analysis even when the debugger doesn’t detect an exception|
|-hang||Generates hung-application output – use this in the event that you are analyzing a bug check or exception dump but analyzing why an application hung is more relevant. If you run this command on a kernel-mode dump, the command investigates locks that the system holds, and scans the DPC queue chain. In a user-mode dump, it analyzes the thread stack to determine if there are any blocking threads. In user-mode, you may have to change the thread from the current one to the one that you think is hung – the exception may have switched the current thread to a different one|
|-show BugCheckCode [BugParameters]||Shows information about the bug check code. The BugCheckCode specifies which code to display. The BugParameters value (you can specify up to four) allows you to refine your search. Separate the parameters with spaces.|
OK – now let’s take a look at some examples of !analyze in action beginning with the straightforward command. The dump file I’m using for this post is from a Windows XP SP3 system using an in-house debug training application to create the bugcheck.
As you can see there is very little information here – just the parameters for the bugcheck and a probable cause. Now let’s look at the output from the !analyze –v command:
Wow – lots more information for us including the stop code information, the stack and the current IRQL. If I just wanted to review the information on the error itself using the – show parameter, here’s what I would get back:
Now, we’re not going to get into the actual debugging of this crash, but those of you who have some experience with bugchecks and debugging have probably already spotted the cause for this bugcheck just from the data given. The resources provided below go into more detail on some of the other pieces of data in the verbose output. That’s all for today folks – have a great Tuesday! Until next time …
|Share this post :||
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.