KeRegisterBugCheck - II

NTDEV
1

Hi. :slight_smile:
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. :wink: 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… :slight_smile:

Thank you all in advance (again), :slight_smile:

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

2

Miguel,

From your postings on this topic, it appears that you are trying very hard
to make sure that if you cause a bugcheck, you can write your own diagnostic
information somewhere so that you don’t need a debugger to see it. While
that’s admirable, I don’t think it’s realistic.

First, in case I need to state the obvious, don’t ever *call* KeBugCheck().
If you have made a mistake, the OS will eventually do it for you. :slight_smile: And
there are very few instances I can think of where calling it due to a known
error is preferable to trying to recover from the error. If you know it’s
an error, deal with it, instead of a panic shutdown.

Second, to accomplish your apparent goal, you need much more stability than
you are guaranteed at a BugCheck. The reason for registering a callback is
to get a notification when the OS BugChecks, so you can flush any data that
you need to flush to your device, clean up after yourself (maybe), and
hopefully put your device in a protective state, so it doesn’t get trashed
by a spurious event. If you are the system boot disk driver, that’s pretty
much impossible, but it should be reasonably possible for most other
non-volatile storage. Your device may have unique/uncommon requirements for
this. The BugCheck callback is not so you can do your own diags. If you
*caused* a BugCheck, it’s unlikely you will be able to sort out the state of
your driver without a debugger attached, or at least a dump image after the
fact. Almost certainly not in the few mSecs you have before you get halted.

Phil

-----Original Message-----
From: Miguel Monteiro [mailto:xxxxx@criticalsoftware.com]
Sent: Friday, March 30, 2001 8:15 AM
To: NT Developers Interest List
Subject: [ntdev] KeRegisterBugCheck - II

Hi. :slight_smile:
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. :wink: 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… :slight_smile:

Thank you all in advance (again), :slight_smile:

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@intel.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

3

> >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… :slight_smile:

Looks like the only way suggested by the OS manufacturer is to use the
kernel’s memory dump file. If your intent is to analyze the bugcheck cause -
which can be very far from your driver - then this suits perfectly.
Otherwise - what kind of information do you want to save at bugcheck? Some
state of your driver? For what? The bugcheck can be caused by some other
driver’s bug. Your state will be irrelevant for this.
Also - your state will be saved to memory dump without any bugcheck
callbacks.
The primary reason in the bugcheck callback is to give the last chance of
accessing the hardware (to shut it down in a controlled manner), not to
write to files.
At the moment of the bugcheck, the FSDs can be in uncontrolled state and
thus trying to write to a file can fail.

Max

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

4

> Looks like the only way suggested by the OS manufacturer is to use the

kernel’s memory dump file. If your intent is to analyze the bugcheck
cause -
which can be very far from your driver - then this suits perfectly.
Otherwise - what kind of information do you want to save at bugcheck? Some
state of your driver? For what? The bugcheck can be caused by some other
driver’s bug. Your state will be irrelevant for this.
Also - your state will be saved to memory dump without any bugcheck
callbacks.
The primary reason in the bugcheck callback is to give the last chance of
accessing the hardware (to shut it down in a controlled manner), not to
write to files.
At the moment of the bugcheck, the FSDs can be in uncontrolled state and
thus trying to write to a file can fail.

If FSD is uncontrolled state how OS will Create .dmp files?

Max

You are currently subscribed to ntdev as: xxxxx@aalayance.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

5

Hi Miguel,

Max and Rob give you not so bad solution.
Just make your own log file inside your own memory space
and search it thrue dump and extract it if you really want
to put it into the separate file :slight_smile:

Igor
ua3qrz

----- Original Message -----
From: “Miguel Monteiro”
To: “NT Developers Interest List”
Sent: Friday, March 30, 2001 11:14 AM
Subject: [ntdev] KeRegisterBugCheck - II

> Hi. :slight_smile:
> 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. :wink: 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… :slight_smile:
>
> Thank you all in advance (again), :slight_smile:
>
> 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@qosnetics.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

6

> If FSD is uncontrolled state how OS will Create .dmp files?

IIRC it dumps all memory to the pagefile and then renames the pagefile to
MEMORY.DMP on next reboot.

Max

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

7

> > If FSD is uncontrolled state how OS will Create .dmp files?

IIRC it dumps all memory to the pagefile and then renames the pagefile
to
MEMORY.DMP on next reboot.

Max

I mean if FSD is uncontroll state how com it will identify PageFile?. How
come it will dump all memory to PageFile ?

Regards,
Satish K.S

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

8

The file system is never called.

The code that generates the crashdump has a cached (in non-page pool) list
of disk blocks which represent that pagefile on disk. This code calls the
crash dump disk driver to write block by block on the disk.

This is why you need a pagefile to generate a dump file, and is one of the
reason the pagefile can not move once you have booted the machine.

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

9

Miguel Monteiro :

  1. Create 1 dummy file for ex : 1 MB
  2. Get all the sectors numbers which is used by this dummy file.
  3. when ever u need to write ur own log file, write a log sector by sector
    using Disk driver.

Extended the file size based on ur need.

Hope this will give u some ideas,

Regards,
Satish K.S

----- Original Message -----
From:
To: “NT Developers Interest List”
Sent: Wednesday, April 04, 2001 12:42 AM
Subject: [ntdev] Re: KeRegisterBugCheck - II

> The file system is never called.
>
> The code that generates the crashdump has a cached (in non-page pool) list
> of disk blocks which represent that pagefile on disk. This code calls the
> crash dump disk driver to write block by block on the disk.
>
> This is why you need a pagefile to generate a dump file, and is one of the
> reason the pagefile can not move once you have booted the machine.
>
> —
> You are currently subscribed to ntdev as: xxxxx@aalayance.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