c @ 464]
0012fed0 00403270 meet!doexit+0xd6
[f:\vs70builds\3077\vc\crtbld\crt\src\crt0dat.c @ 414]
0012fee4 004013b5 meet!exit+0x10
[f:\vs70builds\3077\vc\crtbld\crt\src\crt0dat.c @ 303]
0012ffc0 77e7eb69 meet!mainCRTStartup+0x185
[f:\vs70builds\3077\vc\crtbld\crt\src\crt0.c @ 267]
0012fff0 00000000 kernel32!BaseProcessStart+0x23
As you can see, in addition to the initial breakpoint before the program starts executing,
the Windows debugger also breaks in after the program has finished executing, just before
the process terminates. You can bypass this breakpoint by passing cdb the -G flag. Next let??™s
quit out of the debugger and relaunch it (or use the .restart command) to explore the data
manipulated by the program and to look at the assembly generated by the compiler.
Exploring the Windows Debugger
We??™ll next explore how to find the data the debugged application is using. First, let??™s
launch the debugger and set breakpoints on main and the greeting function. In this section,
again, the memory addresses shown will likely be different from the memory
addresses you see, so be sure to check where a value is coming from in this example output
before using it directly yourself.
C:\grayhat>c:\debuggers\cdb.
Pages:
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465