What happends during writing out a dump file in case of a bug in a SCSI miniport driver?

What would happen if during writing out a full memory dump file the SCSI
miniport driver used for dumping also faults?
Would the BSOD show the original fault or miniport’s fault?
Would be there any record of the BSOD if the miniport faults before writing
out any data?

Dmitriy Budko
VMware

It’s difficult to say as it depends on the kind of dump, the crash, the
timing of the crash and the version of the OS. On newer OS’s the
bugcheck code will only attempt to generate a crash dump on the first
bugcheck. If a fault occurs during the generation and leads to another
bugcheck that will not attempt to write a new dump, so you’ll end up
with a partial dump that may or may not be recognized as invalid on the
next boot. If it does come up as a valid dump it would be for the
original bugcheck. If the dump generation dies before writing any data
there won’t be a dump.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dmitriy Budko
Sent: Monday, April 03, 2006 8:59 PM
To: Kernel Debugging Interest List
Subject: [windbg] What happends during writing out a dump file in case
of a bug in a SCSI miniport driver?

What would happen if during writing out a full memory dump file the SCSI
miniport driver used for dumping also faults?
Would the BSOD show the original fault or miniport’s fault?
Would be there any record of the BSOD if the miniport faults before
writing out any data?

Dmitriy Budko
VMware


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Would the second fault lead to a second call to KeBugCheckXXX ?

If so, is there a lock that is claimed to prevent the second dump
happening or it is just a flag that is set by the kernel that
essentially says “I am dumping now” ?

If not so, then how exactly is the 2nd dumping prevented ?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Tuesday, April 04, 2006 12:52 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] What happends during writing out a dump file in
case of a bug in a SCSI miniport driver?

It’s difficult to say as it depends on the kind of dump, the crash, the
timing of the crash and the version of the OS. On newer OS’s the
bugcheck code will only attempt to generate a crash dump on the first
bugcheck. If a fault occurs during the generation and leads to another
bugcheck that will not attempt to write a new dump, so you’ll end up
with a partial dump that may or may not be recognized as invalid on the
next boot. If it does come up as a valid dump it would be for the
original bugcheck. If the dump generation dies before writing any data
there won’t be a dump.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dmitriy Budko
Sent: Monday, April 03, 2006 8:59 PM
To: Kernel Debugging Interest List
Subject: [windbg] What happends during writing out a dump file in case
of a bug in a SCSI miniport driver?

What would happen if during writing out a full memory dump file the SCSI
miniport driver used for dumping also faults?
Would the BSOD show the original fault or miniport’s fault?
Would be there any record of the BSOD if the miniport faults before
writing out any data?

Dmitriy Budko
VMware


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Whether a second bugcheck happens or not depends on exactly what the
problem is. If it’s a garden variety fault that is caught by the
kernel’s unhandled exception filter then it’ll turn into a bugcheck.
There’s a counter in the bugcheck code (not directly related to the dump
code, it’s built into the bugcheck itself and affects several pieces of
bugcheck behavior) which ensures that full bugcheck processing only
occurs for the first bugcheck.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Wednesday, April 05, 2006 1:55 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] What happends during writing out a dump file in
case of a bug in a SCSI miniport driver?

Would the second fault lead to a second call to KeBugCheckXXX ?

If so, is there a lock that is claimed to prevent the second dump
happening or it is just a flag that is set by the kernel that
essentially says “I am dumping now” ?

If not so, then how exactly is the 2nd dumping prevented ?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Tuesday, April 04, 2006 12:52 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] What happends during writing out a dump file in
case of a bug in a SCSI miniport driver?

It’s difficult to say as it depends on the kind of dump, the crash, the
timing of the crash and the version of the OS. On newer OS’s the
bugcheck code will only attempt to generate a crash dump on the first
bugcheck. If a fault occurs during the generation and leads to another
bugcheck that will not attempt to write a new dump, so you’ll end up
with a partial dump that may or may not be recognized as invalid on the
next boot. If it does come up as a valid dump it would be for the
original bugcheck. If the dump generation dies before writing any data
there won’t be a dump.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dmitriy Budko
Sent: Monday, April 03, 2006 8:59 PM
To: Kernel Debugging Interest List
Subject: [windbg] What happends during writing out a dump file in case
of a bug in a SCSI miniport driver?

What would happen if during writing out a full memory dump file the SCSI
miniport driver used for dumping also faults?
Would the BSOD show the original fault or miniport’s fault?
Would be there any record of the BSOD if the miniport faults before
writing out any data?

Dmitriy Budko
VMware


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com