In the BSoD details, sometimes a description of the bug check code and
the driver that possibly caused the bug check is shown.
KeRegisterBugCheckCallback allows the logging of the 5 numbers
associated with the crash, but is there any way to get the rest of the
information that gets printed on the screen?
Thanks
James
You should really just enable crash dump creation (at the very least minidump creation), instead. This provides a *far* better debugging experience, and is much less brittle and likely to cause secondary failures than mucking around with the bug check callbacks.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
Sent: Tuesday, February 22, 2011 4:26 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] logging bug check driver details
In the BSoD details, sometimes a description of the bug check code and the driver that possibly caused the bug check is shown.
KeRegisterBugCheckCallback allows the logging of the 5 numbers associated with the crash, but is there any way to get the rest of the information that gets printed on the screen?
Thanks
James
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
I think the use case here is for reporting information about crashed
VMs from the VM host (aka DOM0) rather than from the VM itself. It is
a legitimate use case, and I do not believe the message base used by
the bugcheck path for writing the BSOD is exposed in any reasonable
way to other entities. Then again I can no longer look to verify that.
Mark Roddy
On Tue, Feb 22, 2011 at 10:08 AM, Skywing wrote:
> You should really just enable crash dump creation (at the very least minidump creation), instead. ?This provides a far better debugging experience, and is much less brittle and likely to cause secondary failures than mucking around with the bug check callbacks.
>
> - S
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
> Sent: Tuesday, February 22, 2011 4:26 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] logging bug check driver details
>
> In the BSoD details, sometimes a description of the bug check code and the driver that possibly caused the bug check is shown.
>
> KeRegisterBugCheckCallback allows the logging of the 5 numbers associated with the crash, but is there any way to get the rest of the information that gets printed on the screen?
>
> Thanks
>
> James
>
> —
> 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
>
>
You should really just enable crash dump creation (at the very least
minidump
creation), instead. This provides a *far* better debugging
experience, and is
much less brittle and likely to cause secondary failures than mucking
around
with the bug check callbacks.
It’s simply to write a message like:
Bug check 0x12345678 (0x0000000000000000, 0x0000000000000000,
0x0000000000000000, 0x0000000000000000)
To the xen logs. Crash dumps are great but they don’t always work,
especially if it’s your storport driver that caused the crash, or if the
crash happened too early in boot (or xen migrate or windows hibernate
resume) and the interface to xen isn’t initialized yet.
It seems that there is also a mechanism to intercept the bug check IO
with KeRegisterBugCheckReasonCallback and write a copy to Xen for
separate storage. Unfortunately it looks like that is in addition to the
normal dump mechanism so if the normal dump mechanism bails the
KeRegisterBugCheckReasonCallback won’t be that useful either… I’d have
to detect in my bug check driver that the system is too broken to do I/O
and to just fake it… might not be that hard actually…
James
James - I often do raw dumps using xm dumpcore and then create a WinDBG debuggable dump after the fact. The only thing you have to do for this is first (upon boot perhaps) stash a dump header somewhere in memory by using KeInitializeCrashDumpHeader. It’s best to rewrite the header when the crash actually happens in a callback set up by KeRegisterBugCheckCallback, but even if you don’t you should be able to get in and view all the call stacks in the system.
>
James - I often do raw dumps using xm dumpcore and then create a
WinDBG
debuggable dump after the fact. The only thing you have to do for
this is
first (upon boot perhaps) stash a dump header somewhere in memory by
using
KeInitializeCrashDumpHeader. It’s best to rewrite the header when the
crash
actually happens in a callback set up by KeRegisterBugCheckCallback,
but even
if you don’t you should be able to get in and view all the call stacks
in the
system.
That sounds really cool!
What is the ‘after the fact’ bit that you need to do?
James
The docs say how to create a crash dump file:
“To create a crash-dump file, call KeInitializeCrashDumpHeader to create the header, then append the contents of memory to the header. Note that the driver is not required to record the contents of memory immediately after calling the routine: the header can normally be created at any time before the crash-dump file is written.”
You need to store somewhere “on the side” the address of your structure, though. It can be printed to dom0 using port 0xE9, but that’s not really optimal. Better, write it to xenstore and removed just before a successful shutdown. It takes really unlucky timing to crash between the removal of the key and the shutdown of the domain.
Does libxl allows you to set up a watch on domains? If so, you could have a dump daemon in dom0 that keeps a watch on xenstore for the value and a watch on the domain to make a Windows crash dump before the domain is destroyed.
Well I’ve found that even if the support people don’t give me the page number from xenstore, it only takes dumpconverter less than a minute to go ahead and find the header. There’s also a bunch of pages that you have to skip early in the raw memory dump - I don’t know why, I just figured it out by eyeballing the dumps, and the rules differ slightly with a 32 and 64 bit dump. I’m waiting on an answer from someone that is responsible for licensing - hopefully I’ll be able to release this soon.