Viewing Code at a Non-Active Thread's Restart Address at Source-Level



We commonly debug multi-process applications. When a problem occurs and SoftICE stops due to an exception

or breakpoint, I want to know what the other processes were doing. With the "thread -x" command I can see the restart

address of another process. I don't know how I can relate that to an actual line of source code. The "phys" command

will translate from a virtual to physical address. Do I need to do the reverse operation to map the restart address to an address of source code?

Please explain what steps I should follow in order to determine where in the source code processes are currently running. I have symbols loaded for the code I want to debug.


You can use the table -x cmd to get the restart eip value & call stack. However, if you debugging on a uniprocessor machine the return address will almost always be in @KiSwapThread, or SwapContext, which, as you may have guessed, are the kernel routines used by ntoskrnl to swap threads in & out. Therefore, you will almost always have to find the return address that you're interested in (in some ring 3 module) from the thread stack & use it as the "true" return address value, not the value contained in your thread context's EIP psuedoregister. Using SI 3.25 or above is highly recommended because of it's use of FPO data to generate the best possible stack trace.Similarly, you should make sure that any image that you build has FPO data.You can verify that your image has FPO symbolic information in it by issuing a dumpbin /FPO <myimg.ext> on it.See MSDN for information on generating images containing FPO data.

Once you've obtained this value, you will have to switch address contexts if you're not already in the proper process context using the ADDR cmd.You can then switch to the symbol table for the image that the return address is contained using the TABLE cmd.Finally, issuing a U <return_address> command will unassembly at the proper return address & should display source code if your symbol table is mapped properly.

Old KB# 11059
Comment List
Related Discussions