Analyze -v

One thing that definitely trips people up in using WinDBG is the fact that thread and process context are managed separately. By this I mean that switching to a different thread with .thread does not necessarily set the debugger state to be that of the owning process. This is crucial to recognize because it means that the debugger is not using the correct process context for the current thread, which is particularly important when looking at any user mode state.

Let’s see an example with a crash dump I just loaded. In this case, the thread that crashed the system was running under the System process. This means that when I load the crash dump the current process will be set to the System process and all user mode state will be that of the System process (which really means, “no user mode state”, as the System process has nothing mapped into the user portion of the virtual address space and no PEB):

Now I want to switch to a thread in the Outlook process, which has a PEB and the user portion of the virtual address space is Outlook:

So, I execute .thread and supply an address that I previously retrieved from the full !process 86112508 output. You’ll notice however that I have no valid user mode state, the stack walk fails once user mode is reached and !peb informs me that the current PEB is NULL:

This doesn’t make much sense seeing as how this is a full memory dump, so I should be able to view the call stack all the way down into user mode.

The issue is that I have not instructed WinDBG to switch the current process state to that of the Outlook process. Thus, I’m still using the user state of the System process. In order to switch to the correct process context I can do one of two things. I can either explicitly switch the process with .process, or supply the /p /r switches to .thread to have it done for me automatically. The /p is self explanatory, but the /r forces a reload of the user mode symbols for the new process context. This ensures that the user mode loaded module list gets populated and symbols get loaded for the new modules:

One final interesting point is that not all debugger extensions pick up on the process context change. For example, !process -1 will still indicate that I am in the System process. This is due to the fact that !process walks internal O/S data structures which are not modified by the debugger on the context change.

This entry was posted on Wednesday, September 2nd, 2009 at 8:15 am and is filed under WinDBG. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.