From the DDK docs:
«KeRegisterBugCheckCallback sets up a driver-supplied routine
to be called if a bug check occurs so a device driver can save
state information, such as the contents of device registers, that
would not otherwise be saved in a system crash-dump file.
A driver-supplied bug-check callback routine writes whatever
information the driver designer chooses into the memory at Buffer.
The format of the data written at Buffer is driver-determined.
This memory cannot be freed unless the driver first calls
KeDeregisterBugCheckCallback.»
QUESTIONS:
- In the callback routine, should I perform the device state
clean-up and call KeDeregisterBugCheckCallBack before
leaving, trusting my driver-specific data will be saved *with* the
memory dump file?
- If the first question answers «Yes», then I suppose one way
to go would be to write an app that performed a “log analysis”
of *the memory dump file* (like DumpChk does). But then, I had
to *know* the memory dump file format?!.. Any clue on this?..
«Humour and love are God’s answers
to Human weaknesses»
----- Original Message -----
From: “Miguel Monteiro”
To: “NT Developers Interest List”
Sent: Friday, March 30, 2001 5:14 PM
Subject: [ntdev] KeRegisterBugCheck - II
Hi. 
Following my first message, the original question was:
«Is it possible/wise to use ZwWriteFile() from a callback routine
- registered with KeRegisterBugCheck() - in order to save some
“user-defined” information into a simple log (text) file?»
Maxim S. Shatskih (Max) answered clearly and said no (thank
you, Max). He pointed out that I could rely on the kernel’s
memory dump facility, by having the system creating the
small/kernel/complete memory dump (.dmp) file.
But let’s assume I need to log some extra, “user-defined”
information (say, something quite simple like a descriptive text
to a non-technical user or some binary information adapted to
an hipotetical application which reads that log file and produces
a kind of “diagnostic” in a human readable form).
I understand that at the moment the system crashes, it might be
unstable and though there are few guarantees the log file would
be created at all.
However, let’s assume a “best-effort” approach to produce
such a file. Using ZwWriteFile() from the callback routine is not
possible/recommended at all (as Max correctly stated; btw, I
tried it and the call returned assertion errors reporting that the
code was running at the wrong IRQL - which makes a lot of
sense, anyway).
Now, Rob Green said:
>The system passes to the callback a buffer you can write
>data to. You can then access the data via windbg, or maybe
>open the file and search for it.
Thank you, Rob. You’re right, and I know that. At present
stage I could manage to pass and view that buffer from
WinDbg (actually, the buffer contents are nothing less than
the stuff I need to store into the log file. 
But, as I mentioned
above, I need to produce that log file and not just implement
the debug facility through WinDbg.
Finally, Satish K.S. said:
>Why dont u try with ROM Bios File operation functions?
>This will be available after Dead of OS also.
Thank you, Satish. Yes, I was planning to move in to that
step if nothing else works. But that implies using Assembly,
and I’d prefer to stuck with plain C for now, if possible. Not
that I have something against the topic, but I was willing to
find out a “well-behaved” way to achieve this goal without
going much deeper into the hardware. However, I realize
that if such way does not exist at all, I’ll have to proceed as
you suggest.
Hmmm… I just received another mail. Let’s see what Max
says about this:
>There is NO BIOS functions for working with files. Only
>with low-level sectors - and only for IDE drives (SCSI
>drive is supported by BIOS only if it is bootable one).
>
>Also - I have great doubts NT performs return to real
>mode at bugcheck, so, it is not guaranteed that BIOS
>functions will be available at this moment.
>
> Max
Well pointed, Max. What do you suggest, then? I would
mostly appreciate your tips (or anyone else’s tips, btw…
Thank you all in advance (again),
Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com
------------------------------------------------------------
«Humour and love are God’s answers
to Human weaknesses»
------------------------------------------------------------
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You can do basically the same thing NT does, when it boots up it executes
“savedump.exe” which detects that there is a memory.dmp file in the
pagefile.sys, and copies it to memory.dmp (or whatever you named it). You
could have an app execute at bootup, check to see if the system bsod (by
looking in event viewer??) and copy your part of the dump to your own file.
i am sure the memory.dmp format is specified somewhere.
rob
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Miguel Monteiro
Sent: Friday, March 30, 2001 11:48 AM
To: NT Developers Interest List
Subject: [ntdev] KeRegisterBugCheck - III
From the DDK docs:
«KeRegisterBugCheckCallback sets up a driver-supplied routine
to be called if a bug check occurs so a device driver can save
state information, such as the contents of device registers, that
would not otherwise be saved in a system crash-dump file.
A driver-supplied bug-check callback routine writes whatever
information the driver designer chooses into the memory at Buffer.
The format of the data written at Buffer is driver-determined.
This memory cannot be freed unless the driver first calls
KeDeregisterBugCheckCallback.»
QUESTIONS:
- In the callback routine, should I perform the device state
clean-up and call KeDeregisterBugCheckCallBack before
leaving, trusting my driver-specific data will be saved *with* the
memory dump file?
- If the first question answers «Yes», then I suppose one way
to go would be to write an app that performed a “log analysis”
of *the memory dump file* (like DumpChk does). But then, I had
to *know* the memory dump file format?!.. Any clue on this?..
«Humour and love are God’s answers
to Human weaknesses»
----- Original Message -----
From: “Miguel Monteiro”
> To: “NT Developers Interest List”
> Sent: Friday, March 30, 2001 5:14 PM
> Subject: [ntdev] KeRegisterBugCheck - II
>
>
> Hi.
> Following my first message, the original question was:
>
> «Is it possible/wise to use ZwWriteFile() from a callback routine
> - registered with KeRegisterBugCheck() - in order to save some
> “user-defined” information into a simple log (text) file?»
>
> Maxim S. Shatskih (Max) answered clearly and said no (thank
> you, Max). He pointed out that I could rely on the kernel’s
> memory dump facility, by having the system creating the
> small/kernel/complete memory dump (.dmp) file.
>
> But let’s assume I need to log some extra, “user-defined”
> information (say, something quite simple like a descriptive text
> to a non-technical user or some binary information adapted to
> an hipotetical application which reads that log file and produces
> a kind of “diagnostic” in a human readable form).
>
> I understand that at the moment the system crashes, it might be
> unstable and though there are few guarantees the log file would
> be created at all.
>
> However, let’s assume a “best-effort” approach to produce
> such a file. Using ZwWriteFile() from the callback routine is not
> possible/recommended at all (as Max correctly stated; btw, I
> tried it and the call returned assertion errors reporting that the
> code was running at the wrong IRQL - which makes a lot of
> sense, anyway).
>
> Now, Rob Green said:
> >The system passes to the callback a buffer you can write
> >data to. You can then access the data via windbg, or maybe
> >open the file and search for it.
>
> Thank you, Rob. You’re right, and I know that. At present
> stage I could manage to pass and view that buffer from
> WinDbg (actually, the buffer contents are nothing less than
> the stuff I need to store into the log file. But, as I mentioned
> above, I need to produce that log file and not just implement
> the debug facility through WinDbg.
>
> Finally, Satish K.S. said:
> >Why dont u try with ROM Bios File operation functions?
> >This will be available after Dead of OS also.
>
> Thank you, Satish. Yes, I was planning to move in to that
> step if nothing else works. But that implies using Assembly,
> and I’d prefer to stuck with plain C for now, if possible. Not
> that I have something against the topic, but I was willing to
> find out a “well-behaved” way to achieve this goal without
> going much deeper into the hardware. However, I realize
> that if such way does not exist at all, I’ll have to proceed as
> you suggest.
>
> Hmmm… I just received another mail. Let’s see what Max
> says about this:
>
> >There is NO BIOS functions for working with files. Only
> >with low-level sectors - and only for IDE drives (SCSI
> >drive is supported by BIOS only if it is bootable one).
> >
> >Also - I have great doubts NT performs return to real
> >mode at bugcheck, so, it is not guaranteed that BIOS
> >functions will be available at this moment.
> >
> > Max
>
> Well pointed, Max. What do you suggest, then? I would
> mostly appreciate your tips (or anyone else’s tips, btw…
>
> Thank you all in advance (again),
>
> Miguel Monteiro
> xxxxx@criticalsoftware.com
> www.criticalsoftware.com
> ------------------------------------------------------------
> «Humour and love are God’s answers
> to Human weaknesses»
> ------------------------------------------------------------
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@cdp.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
from the OS code:
N.B. Bug check callback routines are called at HIGH_LEVEL
and may not acquire ANY resources.
All you can do in your bugcheck callback is to store the data in the
buffer. Since the buffer must be non-paged pool, just have a global buffer
in your driver (system can only bugcheck once). When the system crashes,
store the information in there.
When the system reboots, the OS will go and save the dump file. You can
not do that yourself. After the dump file is saved, you can have a tool or
script that calls the debugger to extract your data from the dump file.
Even if we documented the format of the dump file, you’d need to load it,
know how to interpret the file and resolve address and resolve symbols
(i.e. write a debugger). So just call the debugger to do that - especially
since there are multiple formats of dump files.
Also keep in mind your data will not be available in a minidump file.
NOTE: You will need symbols though to resolve the address of your buffer in
the dump file.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com