Is a process hijacking your machine?
Suppose there is a process on your machine that is hijacking your processor. Perhaps it’s in an infinite loop. Or perhaps you have no idea what a particular process is doing, and you’d like to find out.
If you have a debugger installed, like Visual Studio, it’s fairly simple to do some basic inspection.
First, start Task Manager (Ctrl-Shift-Esc) and look for the process in the Processes tab. You can sort columns by clicking on the header. For example, you can see which process is eating your CPU by sorting on the CPU column. Right click on the target process and choose “Debug”.
After a warning from Task Manager, you are prompted to choose a particular debugger and the kind of debugging (like native code, T-SQL or Common Language Runtime). Just choose all the defaults and the debugger will attach to the process.
Alternatively, you can start Visual Studio and choose Tools->Debug Processes, which will list the running processes and allow you to attach the debugger. It can even attach to a process on a remote machine (if the correct components and permissions are set).
Or you can start the debugger from a Watson error dialog. (If you choose to send crash information via Watson to Microsoft then we can try to inspect the failed process and determine what went wrong.)
I attached to a VFP8 process that ran this infinite loop code which doesn’t hijack the processor in Visual FoxPro because it yields 1 second of processor time each time through the loop, so other processes (like the debugger) won’t be too sluggish.
DO WHILE INKEY(1)!= 27
DOEVENTS
ENDDO
After attaching, choose Debug->Windows->Modules to see what DLLs are loaded in the process. VFP loads a few dozen DLLs, many of which are Windows DLLs.
advapi32.dll
clbcatq.dll
comctl32.dll
comdlg32.dll
comres.dll
frxhdll.dll
gdi32.dll
GdiPlus.dll
imm32.dll
kernel32.dll
mpr.dll
MSCTF.dll
msi.dll
mslbui.dll
msvcp60.dll
msvcr70.dll
msvcrt.dll
ntdll.dll
ole32.dll
oleacc.dll
oleaut32.dll
oledlg.dll
rpcrt4.dll
shell32.dll
SHLWAPI.DLL
sxs.dll
URLMON.DLL
user32.dll
uxtheme.dll
version.dll
VFP8.exe
VFP8ENU.DLL
winmm.dll
winspool.drv
You can choose Debug->Break or you can hit F12 on the debug target application to cause an asynchronous breakpoint. (F12 actually injects a thread into the target process which causes the breakpoint.)
Choose Debug->Windows->Threads to choose various threads (each thread has its own call stack and usually the main thread is at the top) and Debug->Windows->Call stack to get more info:
> 7ffe0304()
user32.dll!77d4414d()
user32.dll!77d441b3()
VFP8.exe!00494945()
VFP8.exe!00713a13()
VFP8.exe!0048414f()
VFP8.exe!006e0fa2()
VFP8.exe!004e8180()
VFP8.exe!0082cd74()
kernel32.dll!77e7a683()
VFP8.exe!00427f34()
VFP8.exe!0054fcbf()
VFP8.exe!0046ef19()
VFP8.exe!0040177d()
ntdll.dll!77f58a3a()
ntdll.dll!77f693c7()
ntdll.dll!77f693f8()
This display doesn’t seem very useful, but Microsoft provides a public symbol server to help your debugger understand what code is being run.
You can set the environment variable _NT_SYMBOL_PATH to set the symbol path. Hit the Windows-Key Break (or right click on My Computer->Properties). Go to the Advanced tab, Environment Variables: New System Variable
Variable Name =_nt_symbol_path
Variable Value = srv*c:\symbols*http://msdl.microsoft.com/download/symbols
(You’ll need to restart VS to read this environment variable.)
Alternatively, you can set the symbol server via Visual Studio: Choose View->Solution Explorer, right click on the solution at the top and choose Properties. For Common Properties->Debug Symbol Files, put in this string for “Search these paths for symbol files”
srv*c:\symbols*http://msdl.microsoft.com/download/symbols
This indicates the web address to get the symbol files and a directory to cache them locally so they can be accessed much faster next time.
Select all in the Modules window, right click and choose to Reload symbols. (VS.Net 2003 may be a little different from VS Whidbey. You may have to Debug->Stop debugging, exit and save the solution, reattach to the same process)
Now the call stack is much more informative:
> 7ffe0304()
ntdll.dll!_ZwDelayExecution@8() Line 595 + 0xc Asm
kernel32.dll!_SleepEx@8() + 0x55
kernel32.dll!_Sleep@4() + 0xb
VFP8.exe!@EVKeyStillDown@8() - 0x188016
VFP8.exe!@EVGetNextEvent@4() + 0x80
VFP8.exe!@xeinkey_loop@28() + 0x10f
VFP8.exe!@emod@0() + 0x19feb7
VFP8.exe!@xxexpr@4() + 0x96
VFP8.exe!@FRContinueExitLoop@4() + 0xb5
VFP8.exe!@x_enddo@0() + 0x8
VFP8.exe!@EXEPostCommand@8() - 0x2315e1
VFP8.exe!@imode@0() + 0x4f
VFP8.exe!@DllWinMain2@12() + 0xb6
VFP8.exe!_DllWinMain@8() + 0x30
VFP8.exe!_WinMain@16() + 0x16
VFP8.exe!_WinMainCRTStartup() + 0x212
kernel32.dll!_BaseProcessStart@4() + 0x23
I changed the test code to do something more meaningful: execute a user form in an infinite loop. I used the Class browser as a sample.
DO WHILE INKEY(1) != 27
DO (_browser)
_obrowser.Release
DOEVENTS
ENDDO
Examining the call stack indicated that MSComCTL.OCX was in the call stack much of the time. This implements the treeview/listview controls of the class browser.
From the call stack, you can see meaningful names like KeyStillDown, EndDo, and inkey_loop.
This technique is a poor developer’s profiler: with a few asynchronous breaks you can determine where the most time is being spent.
(Keep in mind that VS is reconstructing a call stack from the optimized build of many modules and it can be very difficult and is not always correct.)
With symbols loaded, you can even put breakpoints on symbolic names. For example, @goof@4 is the symbol for goof, which is called usually when an error occurs.
BTW, Sysinternals has several tools that will allow you to see what registry entries and files are being accessed, or even to inspect various aspects of a particular process.
Happy debugging!
41045
