After trying to find a problem which was really due to my simplistic approach to a problem I was trying to test too simplisticly, I cracked open windbg.exe Here are the steps, but only so I remember what I did - anyone reading this rubbish is wasting their time.
download the driver SDK - it's huge install and then grab windbg.exe
copy just the exe to the system you want to trace, copy the debug executable, and it's pdb.
tell windbg.run your process, instead of trying to attach each time, it's less hastle
when the process breaks - or you hit break.
type
~*
to see all threads
then open the View/Processes and Threads
then open the View/Call stack menu
set breakpoint on thread creation is "Debug/Event Filters..."
turn the option "Create thread - disabled - not handled" on
for some reason breakpoint in CreateTHread() did not trigger
bp kernel32!CreatweThread
use
bl
to list all breakpoints.
List of Windbg commands and pretty good intro:
download the driver SDK - it's huge install and then grab windbg.exe
copy just the exe to the system you want to trace, copy the debug executable, and it's pdb.
tell windbg.run your process, instead of trying to attach each time, it's less hastle
when the process breaks - or you hit break.
type
~*
to see all threads
then open the View/Processes and Threads
then open the View/Call stack menu
set breakpoint on thread creation is "Debug/Event Filters..."
turn the option "Create thread - disabled - not handled" on
for some reason breakpoint in CreateTHread() did not trigger
bp kernel32!CreatweThread
use
bl
to list all breakpoints.
List of Windbg commands and pretty good intro:
- look in the chm file that came with windbg
- http://www.codeproject.com/KB/debug/windbg_part1.aspx#_Toc64133677
Comments
Post a Comment