Freigeben über

Debugging Attached Process on Devices

  • Artikel

Very often I need to build a quick test EXE or DLL and test it using device emulator. I can of course do this by using Platform Builder's "load from release directory" feature with a KITL enabled image. But this will require a full booting up of the image.

I can also use the "Attach to Process" feature of Visual Studio Smart Device component. First run the test application on a device emulator, then attach the VS debugger to the process. Then when you break the process, you probably see some disassembly code with unresolved addresses. So the question is, how to make better use of this feature for source code debugging?

First, you need to check if the symbol of the test application is loaded. Open the 'Modules' windows and see if the symbol file (PDB) of the test application is showing up there. You should see 'symbol loaded' if you have the PDB file and the EXE/DLL in the same directory where you run the test application.

Then, think about what code is running when you break the process. If you see symbol of the test application is loaded but you did not see any symbol in the disassembly window when you break the process, chances are the process is running code that you don't have the symbols. For example, for a simple Win32 window application created using the wizard, if you break it, you will end up in the message loop somewhere in coredll.dll. If you don't have symbol for it, you will not see any meaningful information in the disassembly window and the call stack window.

A good way to break the test application is to create a breakpoint that you know it will be hit. After attaching the debugger to the process, add a new breakpoint such as "func" (whereas func is a function in the test application).

NOTE: DO NOT USE THE PB METHOD OF ADDING A BREAKPOINT HERE! That is, just enter the function name, not the PB way of "{,,yourapp.exe} func".

Then you should see the breakpoint is resolved and a solid red circle shows up next to it in the breakpoint window. Then when you do something with the application to trigger this breakpoint, you will see the application breaks and its source code shows up! Well, that is based on the assumption that the source code path indicated in the PDB file exists on this computer. If the debugger has trouble finding the source files using that path, it will pop up a nice dialog box for you to specify a path. In that case, just browse to the place where you have the source files.

Now, you can do source code debugging of the process you just attached.

Comments