Now there's no guesswork as to which thread was doing the work. From the screen in Figure 1, you can then issue the ~ (tilde) command in the debugger to find out what thread number corresponds to 0x1194. Figure 2 shows the command line and its output. As you can see, thread 2 (which includes 1194 in the line) is the thread that corresponds to 0x1194.
Figure 2: Output of ~ command
0:000> ~
. 0 Id: 1260.e74 Suspend: 0 Teb: 7ffdf000 Unfrozen
1 Id: 1260.6d0 Suspend: 0 Teb: 7ffde000 Unfrozen
2 Id: 1260.1194 Suspend: 0 Teb: 7ffdd000 Unfrozen
3 Id: 1260.11f8 Suspend: 0 Teb: 7ffdc000 Unfrozen
4 Id: 1260.1780 Suspend: 0 Teb: 7ffdb000 Unfrozen
5 Id: 1260.13d4 Suspend: 0 Teb: 7ffda000 Unfrozen
6 Id: 1260.1544 Suspend: 0 Teb: 7ffd9000 Unfrozen
7 Id: 1260.1164 Suspend: 0 Teb: 7ffd7000 Unfrozen
This was just an example that I created to demonstrate the tool, but now we can change the focus to thread 2 to find out what was going on at the time the CPU was consumed. At the command prompt, run the following command to change the context to thread 2:
0:000> ~2s
The command's output in Figure 3 shows that the wmiprvse.exe process enumerated through various directories (EnumDirsNT) at the time this test was done, which makes sense since the WMI query I issued required the enumeration of all directories on my system.
Figure 3: Wmiprvse.exe process thread 2 details
eax=013bd900 ebx=00004021 ecx=00000004 edx=00000044 esi=76fb49f4 edi=00100001
eip=76fb5cb4 esp=013bd548 ebp=013bd840 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!KiFastSystemCallRet:
76fb5cb4 c3 ret
0:002> k
ChildEBP RetAddr
013bd544 76fb4a00 ntdll!KiFastSystemCallRet
013bd548 75810c0a ntdll!ZwOpenFile+0xc
013bd840 75810def kernel32!FindFirstFileExW+0x1c9
013bd860 60c44cbb kernel32!FindFirstFileW+0x16
013bdd5c 60c4585e cimwin32!CImplement_LogicalFile::EnumDirsNT+0x5b2
013be254 60c4585e cimwin32!CImplement_LogicalFile::EnumDirsNT+0x1151
013be74c 60c4585e cimwin32!CImplement_LogicalFile::EnumDirsNT+0x1151
013bec44 60c7b7e9 cimwin32!CImplement_LogicalFile::EnumDirsNT+0x1151
013beec8 666ff3dd cimwin32!CShortcutFile::EnumerateInstances+0x157
013beedc 666ff82f framedynos!Provider::CreateInstanceEnum+0x21
ProcDump will also dump a process if any of the process's windows are hung (-h option); as with the other ProcDump functions, you don't need to be physically at the console to initiate this task.
Launching a Process Under the Debugger
An especially useful ProcDump option is the ability to launch a process directly under the debugger using the -x option. The -x option works with the Image File Execution Options registry entry. The command example in Figure 4, which specifies -x with the lsass.exe process, will take three dumps of lsass.exe when the process spikes the CPU to 90 percent.
Figure 4: Using ProcDump with the -x option
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.EXE
Debugger = c:\procdump\procdump.exe -c 90 -n 3 -ma -x
Now the next time lsass.exe is started, ProcDump will monitor the process with the configured parameters. Why is this so cool? Because there are processes that could spike immediately on startup and freeze your whole system, and you can't log on to the console until the CPU has settled down—but by that time, there's nothing to dump out because the high CPU has gone down. Using ProcDump with the -x option lets you capture information about these spikes when they happen.
More Help for High-CPU Issues
I predict the ProcDump will be the tool of choice for most high-CPU issues and will change the way we attack such problems and how fast they're resolved. ProcDump was built as a grassroots effort initiated by Microsoft's Global Escalation Services team. A special thanks to Ming Chen, the senior escalation engineer who first approached Mark and got the ball rolling; Jeff Daily, a principal escalation engineer, for his leadership and guidance; and of course, a huge thanks to Mark Russinovich, a Microsoft technical fellow, for taking our input so frequently and making changes so fast.