How to set breakpoints in windbg that does not stop the execution of the program just logs the function called

Question

I am debugging a windows component and want to view all the functions of a particular dll that are called (also in the exact order they are called). I can do this by attaching the component to windbg and setting breakpoints over all the exported functions (bm *module_name!*) of the dll in question.

This works as expected. Whenever an exported function of that dll is called windbg breaks the execution and prints on the screen information about the breakpoint that is hit. After that I can manually resume execution by pressing F5 or giving the go command.

The problem: Some functions of the dll have to return very quickly (immediately) else the component crashes. In that case the breakpoint causes the component to crash. I can remove the breakpoint in question but then there would be no log of it being hit.

I looked around and found that I can run a command whenever a breakpoint is hit. bm module_name!func_name ".printf \"func_name\n\";gc" But this is not feasible for every exported function. The dll has about a few 100 exported functions.

What can I do to log (on the screen itself) every exported function that is hit (even the breakpoint number would do if nothing else can be done). Is there a variable name I can use in the printf command that can print the function name (or the breakpoint number if not the function name)?

Gregale

What is the problem here, you want a list of the functions being hit and then continue but remove the breakpoints or are you wanting to just output the first line of the call stack? You could try .kframes=1;bm *modulename!* "kb;gc", this will set the call stack to 1, for every breakpoint hit it will dump just the first call which will be the function hit but you will get a lot of hits though – Variorum

Numeric expression missing from '=1;bm *modulename!* "kb;gc"' – Gregale

FTR: I dont want to remove the breakpoint. – Gregale

sorry do you just want to dump the call stack for every breakpoint hit, the command string "kb;gc" will do that, if this is too verbose and you just want the function name then .kframes=0n1 will set the call stack depth to 1, sorry I had a typo in my original comment – Variorum

Still doesn't work. Same error. When and where do I type in .kframes=0n1 ? – Gregale

what doesn't work specifically? – Variorum

You call .kframes=0n1 before you enter the command to set the breakpoints – Variorum

OK I see where I went wrong .kframes 1 sets the call stack to a depth of 1, this will reduce the verbosity of the call stacks being displayed – Variorum

The k commands actually take a count argument, so you don't necessarily need to run .kframes first: bm blah "k 1;gc" – Ludwick

@KurtHutchinson Where in the docs is this stated? Is this a hidden feature (wouldn't surprise me) but I wasn't aware of this – Variorum

@Variorum It's documented: msdn.microsoft.com/en-us/library/ff551943.aspx. FrameCount: Specifies the number of stack frames to display. – Ludwick

@KurtHutchinson thanks for the link was looking in wrong place, never used it so wasn't aware – Variorum

Answer 1

Figured it out. Thanks to EdChum.

The command: bm *module_name!* ".frame;gc"

Gregale

how did you get around the 32 breakpoint limit ? "You have attempted to enable XX KD breakpoints, which exceeds the currently supported limit of 32 breakpoints for Windows kernel debugging. Breakpoints exceeding this limit are ignored" – Grandpa

Fortunately/Unfortunately the component I was debugging had no such limits. And I don't have a windows machine anymore to try things out. I think it would serve you better to ask a new question. Good luck! – Gregale

I'm guessing thats a user mode application, perhaps there is no such limits there. – Grandpa

It wasn't. It was spoolsv.exe which runs as the system user, IIRC. – Gregale

Executable are user mode. Kernel mode would be .sys drivers / core OS :) – Grandpa

Oh well, TIL. Thanks. – Gregale