At first glance, it seems to be just an alternative for System.Diagnostics.Debug.
What about on-site debugging? It's common that we use windbg in this scenario. We can also take advantage of similar feature in windbg. When set a break point in windbg, you can also specify a command string that will be executed automatically while the break point is hit. The command string can be composed of several statements that will be executed in sequence.
Here is a sample code, suppose we want to trace when and where foo is invoked:
#include "Windows.h" void foo() { Sleep(2000); } int main() { while(true) foo(); return 0; }
Then we compile and execute the code. Now attach the windbg to the target and add a break point with:
bp foo ".echo enter foo;k;g;"
Note that we need at least public symbol file to debug this.
Every time foo is invoked, following output will be printed in the debugger. And the process continues.
enter foo ChildEBP RetAddr 0012ff54 004010d3 1!foo [d:\documents and settings\raymond\desktop\dbg\1.cpp @ 35] 0012ff78 0040138c 1!main+0x53 [d:\documents and settings\raymond\desktop\dbg\ 1.cpp @ 45] 0012ffc0 7c816fe7 1!__tmainCRTStartup+0xfb [f:\dd\vctools\crt_bld\self_ x86\crt\src\crt0.c @ 266] 0012fff0 00000000 kernel32!BaseProcessStart+0x23
Let's explain the preceding command string. It composes of three statements. First, echo a string saying we enter the foo function. Then, print the call stack with k command. Finally, use g command to continue the process.
No comments:
Post a Comment