Logging DbgPrint (not xen)

Another question about DbgPrint hooking -

I’d like to keep last DbgPrint messages in a ring buffer, so
that in case of bugcheck, it will be included in the dumps.
Kind of the “in-flight recorder” of KMDF, and similar to what does
the DebugView.
The target runs in no-debug mode, and due to some reasons,
using DebugView is not possible.

Should I roll my own driver to hook DebugService (or whatever)
or there’s a simpler way?

– PA
****

-------- Original Message --------
Subject: Re: hooking DbgPrint
Date: Wed, 24 Dec 2008 10:48:55 -0500
From: Mark Roddy

So the strategy that works is to patch on older os’s that don’t
export DbgSetDebugPrintCallback and use DbgSetDebugPrintCallback on os;s
that do export it. This interface should be documented, by the way, as
uses such as James guest os debug log support are entirely legitimate.

Mark Roddy

On Wed, Dec 24, 2008 at 5:13 AM, Pavel A. mailto:xxxxx> wrote:

From a quick disassembly of the DbgView driver -
it seems that it calls DbgSetDebugPrintCallback on OSes
that export this, to install it’s handler.
Also it uses DbgSetDebugFilterState.

–PA

Skywing wrote:

There is a nice pluggable function pointer (nt!KiDebugRoutine)
which handles int 2d (DebugService). This toggles between
nt!KdpStub and nt!KdpTrap based on whether KD is enabled or not
(with KdpTrap being responsible for forwarding such activity on
to the debugger).

However, as Doron noted, this mechanism is guarded by PatchGuard.

There is a sanctioned (though the documentation seems to have
fallen by the wayside) interface for capturing user mode debug
output (DBWIN), though I don’t know of an officially blessed way
to do it for kernel mode callers that won’t incur wrath of
badness on 64-bit Windows. I suspect that DbgView probably just
hooks the IDT or KiDebugRoutine, but neither of those are going
to be permitted by PatchGuard by default. It might be
interesting, however, to see if it manages to work on 64-bit
systems. Perhaps there’s some feature in the debug print
buffering support that permits one to gain access to log
messages in a less invasive fashion.

- S

From: xxxxx@lists.osr.com
mailto:xxxxx
[mailto:xxxxx@lists.osr.com
mailto:xxxxx] *On Behalf Of
*Deepak Gupta
Sent: Wednesday, December 24, 2008 1:57 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] hooking DbgPrint

On Wed, Dec 24, 2008 at 11:53 AM, Maxim S. Shatskih

mailto:xxxxx>>
wrote:

>I would like to hook into DbgPrint at a lower level though so
that all

I think it is some IDT vector (int 2c?)

I think int 2c is “KeRaiseAssertion” (Observed it on Windows
Server 2008 64bit)
Better use inline hooking mechanism by locating the address of
DbgPrint.

Regards
Deepak

–</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

IIRC, this functionality is already built in to the kernel as of Srv03; see kdbgctrl.

? S

-----Original Message-----
From: Pavel A.
Sent: Wednesday, December 24, 2008 12:39
To: Windows System Software Devs Interest List
Subject: [ntdev] Logging DbgPrint (not xen)

Another question about DbgPrint hooking -

I’d like to keep last DbgPrint messages in a ring buffer, so
that in case of bugcheck, it will be included in the dumps.
Kind of the “in-flight recorder” of KMDF, and similar to what does
the DebugView.
The target runs in no-debug mode, and due to some reasons,
using DebugView is not possible.

Should I roll my own driver to hook DebugService (or whatever)
or there’s a simpler way?

– PA
****

-------- Original Message --------
Subject: Re: hooking DbgPrint
Date: Wed, 24 Dec 2008 10:48:55 -0500
From: Mark Roddy

So the strategy that works is to patch on older os’s that don’t
export DbgSetDebugPrintCallback and use DbgSetDebugPrintCallback on os;s
that do export it. This interface should be documented, by the way, as
uses such as James guest os debug log support are entirely legitimate.

Mark Roddy

On Wed, Dec 24, 2008 at 5:13 AM, Pavel A. mailto:xxxxx> wrote:

From a quick disassembly of the DbgView driver -
it seems that it calls DbgSetDebugPrintCallback on OSes
that export this, to install it’s handler.
Also it uses DbgSetDebugFilterState.

–PA

Skywing wrote:

There is a nice pluggable function pointer (nt!KiDebugRoutine)
which handles int 2d (DebugService). This toggles between
nt!KdpStub and nt!KdpTrap based on whether KD is enabled or not
(with KdpTrap being responsible for forwarding such activity on
to the debugger).

However, as Doron noted, this mechanism is guarded by PatchGuard.

There is a sanctioned (though the documentation seems to have
fallen by the wayside) interface for capturing user mode debug
output (DBWIN), though I don’t know of an officially blessed way
to do it for kernel mode callers that won’t incur wrath of
badness on 64-bit Windows. I suspect that DbgView probably just
hooks the IDT or KiDebugRoutine, but neither of those are going
to be permitted by PatchGuard by default. It might be
interesting, however, to see if it manages to work on 64-bit
systems. Perhaps there’s some feature in the debug print
buffering support that permits one to gain access to log
messages in a less invasive fashion.

- S

From: xxxxx@lists.osr.com
mailto:xxxxx
[mailto:xxxxx@lists.osr.com
mailto:xxxxx] *On Behalf Of
*Deepak Gupta
Sent: Wednesday, December 24, 2008 1:57 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] hooking DbgPrint

On Wed, Dec 24, 2008 at 11:53 AM, Maxim S. Shatskih

mailto:xxxxx>>
wrote:

>I would like to hook into DbgPrint at a lower level though so
that all

I think it is some IDT vector (int 2c?)

I think int 2c is “KeRaiseAssertion” (Observed it on Windows
Server 2008 64bit)
Better use inline hooking mechanism by locating the address of
DbgPrint.

Regards
Deepak




NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Skywing wrote:

IIRC, this functionality is already built in to the kernel as of Srv03; see kdbgctrl.

Thanks for reply, Ken.
Unfortunately, this is for XP. may be even win2k.

–PA

-----Original Message-----
From: Pavel A.
> Sent: Wednesday, December 24, 2008 12:39
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Logging DbgPrint (not xen)
>
>
> Another question about DbgPrint hooking -
>
> I’d like to keep last DbgPrint messages in a ring buffer, so
> that in case of bugcheck, it will be included in the dumps.
> Kind of the “in-flight recorder” of KMDF, and similar to what does
> the DebugView.
> The target runs in no-debug mode, and due to some reasons,
> using DebugView is not possible.
>
> Should I roll my own driver to hook DebugService (or whatever)
> or there’s a simpler way?
>
>
> – PA
> ****
>
>
> -------- Original Message --------
> Subject: Re: hooking DbgPrint
> Date: Wed, 24 Dec 2008 10:48:55 -0500
> From: Mark Roddy
>
> So the strategy that works is to patch on older os’s that don’t
> export DbgSetDebugPrintCallback and use DbgSetDebugPrintCallback on os;s
> that do export it. This interface should be documented, by the way, as
> uses such as James guest os debug log support are entirely legitimate.
>
> Mark Roddy
>
>
> On Wed, Dec 24, 2008 at 5:13 AM, Pavel A. > mailto:xxxxx> wrote:
>
> From a quick disassembly of the DbgView driver -
> it seems that it calls DbgSetDebugPrintCallback on OSes
> that export this, to install it’s handler.
> Also it uses DbgSetDebugFilterState.
>
> --PA
>
>
> Skywing wrote:
>
>
>
> There is a nice pluggable function pointer (nt!KiDebugRoutine)
> which handles int 2d (DebugService). This toggles between
> nt!KdpStub and nt!KdpTrap based on whether KD is enabled or not
> (with KdpTrap being responsible for forwarding such activity on
> to the debugger).
>
>
> However, as Doron noted, this mechanism is guarded by PatchGuard.
>
>
> There is a sanctioned (though the documentation seems to have
> fallen by the wayside) interface for capturing user mode debug
> output (DBWIN), though I don’t know of an officially blessed way
> to do it for kernel mode callers that won’t incur wrath of
> badness on 64-bit Windows. I suspect that DbgView probably just
> hooks the IDT or KiDebugRoutine, but neither of those are going
> to be permitted by PatchGuard by default. It might be
> interesting, however, to see if it manages to work on 64-bit
> systems. Perhaps there’s some feature in the debug print
> buffering support that permits one to gain access to log
> messages in a less invasive fashion.
>
>
> - S
>
>
> From: xxxxx@lists.osr.com
> mailto:xxxxx
> [mailto:xxxxx@lists.osr.com
> mailto:xxxxx] *On Behalf Of
> *Deepak Gupta
> Sent: Wednesday, December 24, 2008 1:57 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] hooking DbgPrint
>
>
>
> On Wed, Dec 24, 2008 at 11:53 AM, Maxim S. Shatskih
>
> mailto:xxxxx>>
> wrote:
>
> >I would like to hook into DbgPrint at a lower level though so
> that all
>
> I think it is some IDT vector (int 2c?)
>
> I think int 2c is “KeRaiseAssertion” (Observed it on Windows
> Server 2008 64bit)
> Better use inline hooking mechanism by locating the address of
> DbgPrint.
>
> Regards
> Deepak
>
>
>
> –
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

I’m not sure this is exactly what Pavel wants. “To use KDbgCtrl, you must
have already enabled kernel debugging in the boot settings of the target
computer before the last boot. KDbgCtrl cannot be used to enable kernel
debugging if this was not done.”
The system has to be running with debug enabled.

Systems I work on implement the ringbuffer mechanism Pavel mentions, hooking
via the discussed methods as appropriate, and capture all debug output in a
rather large kernel buffer that can be processed in realtime from user mode
or analyzed post mortem in a crash dump. I really like this feature, in fact
I consider it essential, and really wish that Microsoft had done this
instead of the over-complicated ETW.

Mark Roddy

On Wed, Dec 24, 2008 at 1:47 PM, Skywing wrote:

> IIRC, this functionality is already built in to the kernel as of Srv03; see
> kdbgctrl.
>
> ? S
>
> -----Original Message-----
> From: Pavel A.
> Sent: Wednesday, December 24, 2008 12:39
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Logging DbgPrint (not xen)
>
>
> Another question about DbgPrint hooking -
>
> I’d like to keep last DbgPrint messages in a ring buffer, so
> that in case of bugcheck, it will be included in the dumps.
> Kind of the “in-flight recorder” of KMDF, and similar to what does
> the DebugView.
> The target runs in no-debug mode, and due to some reasons,
> using DebugView is not possible.
>
> Should I roll my own driver to hook DebugService (or whatever)
> or there’s a simpler way?
>
>
> – PA
> ****
>
>
> -------- Original Message --------
> Subject: Re: hooking DbgPrint
> Date: Wed, 24 Dec 2008 10:48:55 -0500
> From: Mark Roddy
>
> So the strategy that works is to patch on older os’s that don’t
> export DbgSetDebugPrintCallback and use DbgSetDebugPrintCallback on os;s
> that do export it. This interface should be documented, by the way, as
> uses such as James guest os debug log support are entirely legitimate.
>
> Mark Roddy
>
>
> On Wed, Dec 24, 2008 at 5:13 AM, Pavel A. > mailto:xxxxx> wrote:
>
> From a quick disassembly of the DbgView driver -
> it seems that it calls DbgSetDebugPrintCallback on OSes
> that export this, to install it’s handler.
> Also it uses DbgSetDebugFilterState.
>
> --PA
>
>
> Skywing wrote:
>
>
>
> There is a nice pluggable function pointer (nt!KiDebugRoutine)
> which handles int 2d (DebugService). This toggles between
> nt!KdpStub and nt!KdpTrap based on whether KD is enabled or not
> (with KdpTrap being responsible for forwarding such activity on
> to the debugger).
>
>
> However, as Doron noted, this mechanism is guarded by PatchGuard.
>
>
> There is a sanctioned (though the documentation seems to have
> fallen by the wayside) interface for capturing user mode debug
> output (DBWIN), though I don’t know of an officially blessed way
> to do it for kernel mode callers that won’t incur wrath of
> badness on 64-bit Windows. I suspect that DbgView probably just
> hooks the IDT or KiDebugRoutine, but neither of those are going
> to be permitted by PatchGuard by default. It might be
> interesting, however, to see if it manages to work on 64-bit
> systems. Perhaps there’s some feature in the debug print
> buffering support that permits one to gain access to log
> messages in a less invasive fashion.
>
>
> - S
>
>
> From: xxxxx@lists.osr.com
> mailto:xxxxx
> [mailto:xxxxx@lists.osr.com
> mailto:xxxxx] *On Behalf Of
> *Deepak Gupta
> Sent: Wednesday, December 24, 2008 1:57 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] hooking DbgPrint
>
>
>
> On Wed, Dec 24, 2008 at 11:53 AM, Maxim S. Shatskih
>
> mailto:xxxxx>>
> wrote:
>
> >I would like to hook into DbgPrint at a lower level though so
> that all
>
> I think it is some IDT vector (int 2c?)
>
> I think int 2c is “KeRaiseAssertion” (Observed it on Windows
> Server 2008 64bit)
> Better use inline hooking mechanism by locating the address of
> DbgPrint.
>
> Regards
> Deepak
>
>
>
> –
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

> I’d like to keep last DbgPrint messages in a ring buffer, so

that in case of bugcheck, it will be included in the dumps.
Kind of the “in-flight recorder” of KMDF, and similar to what does
the DebugView.
The target runs in no-debug mode, and due to some reasons,
using DebugView is not possible.

Should I roll my own driver to hook DebugService (or whatever)
or there’s a simpler way?

Define a macro in your driver called MyPrint which will maintain this buffer and then do KdPrint.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

However that does not capture dbgprints from other drivers. So you get to
analyze runtime data from your driver and hope you can work back from that
to the root cause of the problem. Capturing everyone’s screams as the system
starts to go south is generally more informative.
Mark Roddy

On Wed, Dec 24, 2008 at 2:58 PM, Maxim S. Shatskih
wrote:

> > I’d like to keep last DbgPrint messages in a ring buffer, so
> > that in case of bugcheck, it will be included in the dumps.
> > Kind of the “in-flight recorder” of KMDF, and similar to what does
> > the DebugView.
> > The target runs in no-debug mode, and due to some reasons,
> > using DebugView is not possible.
> >
> > Should I roll my own driver to hook DebugService (or whatever)
> > or there’s a simpler way?
>
> Define a macro in your driver called MyPrint which will maintain this
> buffer and then do KdPrint.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>