DbgPrint performance

I’m attempting to output a minimal amount of information via DbgPrint from
a kernel component to Windbg. The code generating the DbgPrint is very
time-sensitive, and it appears that windbg uses a blocking print to the
host (temporarily altering the timing of the target) to output the
information.

Debugview appears to use an asynchronous print to output information to a
connected debug viewer, where the print is offloaded and there is little
if any affect on the timing of the target executing the DbgPrint.

I’m wondering if it is possible to configure windbg to use asynchronous
prints similar to debugview such that the timing of my kernel is not
affected. If not, is there a way to continue to use windbg as a debugger
but to use debugview for DbgPrints?

I’ve explored KDbgCtrl, but don’t see any relevant options exposed.

If you are timing sensitive, I would investigate WPP/TraceView since writing to the debug print buffer itself can cause perf issues across the entire machine.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jason Tongen
Sent: Monday, August 14, 2006 1:30 PM
To: Kernel Debugging Interest List
Subject: [windbg] DbgPrint performance

I’m attempting to output a minimal amount of information via DbgPrint from a kernel component to Windbg. ?The code generating the DbgPrint is very time-sensitive, and it appears that windbg uses a blocking print to the host (temporarily altering the timing of the target) to output the information.

Debugview appears to use an asynchronous print to output information to a connected debug viewer, where the print is offloaded and there is little if any affect on the timing of the target executing the DbgPrint.

I’m wondering if it is possible to configure windbg to use asynchronous prints similar to debugview such that the timing of my kernel is not affected. ?If not, is there a way to continue to use windbg as a debugger but to use debugview for DbgPrints?

I’ve explored KDbgCtrl, but don’t see any relevant options exposed. — You are currently subscribed to windbg as: xxxxx@microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com

You can suspend the kernel debugger for a time via kdbgctrl -d. Debug
prints will not be send to kd but will accumulate in the kernel debug
print buffer. When you’re done with the timing sensitive code you can
use kdbgctrl -e to resume kd and then !dbgprint from kd to see the
kernel debug print buffer.

This will still have a perf impact, as access to the dbgprint buffer is
synchronized. If you want high-rate markers or logging you’re better
off using a purely target-side solution.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jason Tongen
Sent: Monday, August 14, 2006 1:30 PM
To: Kernel Debugging Interest List
Subject: [windbg] DbgPrint performance

I’m attempting to output a minimal amount of information via DbgPrint
from a kernel component to Windbg. The code generating the DbgPrint is
very time-sensitive, and it appears that windbg uses a blocking print to
the host (temporarily altering the timing of the target) to output the
information.

Debugview appears to use an asynchronous print to output information to
a connected debug viewer, where the print is offloaded and there is
little if any affect on the timing of the target executing the DbgPrint.

I’m wondering if it is possible to configure windbg to use asynchronous
prints similar to debugview such that the timing of my kernel is not
affected. If not, is there a way to continue to use windbg as a
debugger but to use debugview for DbgPrints?

I’ve explored KDbgCtrl, but don’t see any relevant options exposed. —
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

“Jason Tongen” <jason.tongen> wrote in message news:xxxxx@windbg…

> is there a way to continue to use windbg as a debugger
> but to use debugview for DbgPrints?

Have you noticed the “pass thru” option in dbgview?
When unchecked, it won’t pass prints to the debugger.

–PA</jason.tongen>