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