After the BSOD: Any suggestions?

NTDEV
1

I’ve got a first revision driver that checks out okay on two target computers in free and checked (driver) builds (with driver verifier engaged), so I thought: “Right! now’s the time to run it on my development computer so I can get on with the app which uses it.”

Trouble is, as soon as I tried it on my development computer and ran the app, I got a BSOD BAD_POOL_HEADER Stop 0x19 (0x20, 0x83885258, 0x1a510001).

When it rebooted it crashed again within seconds with a BSOD Stop 0xc4 (0x90, 0xffdff120, 0,0). (This with the 1394 test hardware unplugged so my driver should not have even loaded after the first reboot).

I recovered by rolling back to ‘last version which worked’.

The MS listing for Stop 0x19 does not show an 0x20 option for param 1, so I’m not sure what this actually means.

So, any suggestions are welcome, but what may really help me (and maybe others) is a suggestion of how to get more information after a BSOD when it is on one’s development machine (or say a customer’s machine). The event viewer just repeats the info I already have. The second crash also presumably overwrites any memory dump from the first one - anyway, what tool would one use to examine that?

Also any idea for the location of a definitive list of bug check codes?

BTW My dev computer also has driver verifier on for this driver.

Thanks in advance, Mike

2

I’m curious as to how you debugged the driver and not know how to handle a
crash dump or where to find a definitive list of bug check codes?

Download the latest “Debugger tools for Windows”. Google or use some other
browser search facility, for WinDbg. It contains all of the Windows
debugging tools. The online help provides about as comprehensive a list of
bug checks codes as is available.

The first thing to learn about driver development is to always expect the
unexpected,

The personal opinion of
Gary G. Little

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Monday, June 12, 2006 8:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] After the BSOD: Any suggestions?

I’ve got a first revision driver that checks out okay on two target
computers in free and checked (driver) builds (with driver verifier
engaged), so I thought: “Right! now’s the time to run it on my development
computer so I can get on with the app which uses it.”

Trouble is, as soon as I tried it on my development computer and ran the
app, I got a BSOD BAD_POOL_HEADER Stop 0x19 (0x20, 0x83885258,
0x1a510001).

When it rebooted it crashed again within seconds with a BSOD Stop 0xc4
(0x90, 0xffdff120, 0,0). (This with the 1394 test hardware unplugged so my
driver should not have even loaded after the first reboot).

I recovered by rolling back to ‘last version which worked’.

The MS listing for Stop 0x19 does not show an 0x20 option for param 1, so
I’m not sure what this actually means.

So, any suggestions are welcome, but what may really help me (and maybe
others) is a suggestion of how to get more information after a BSOD when
it is on one’s development machine (or say a customer’s machine). The
event viewer just repeats the info I already have. The second crash also
presumably overwrites any memory dump from the first one - anyway, what
tool would one use to examine that?

Also any idea for the location of a definitive list of bug check codes?

BTW My dev computer also has driver verifier on for this driver.

Thanks in advance, Mike

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

3

Turn Verifier on (special pool) and look at what BSODs will occur under
Verifier.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Mike Kemp”
To: “Windows System Software Devs Interest List”
Sent: Monday, June 12, 2006 5:50 PM
Subject: [ntdev] After the BSOD: Any suggestions?

I’ve got a first revision driver that checks out okay on two target computers
in free and checked (driver) builds (with driver verifier engaged), so I
thought: “Right! now’s the time to run it on my development computer so I can
get on with the app which uses it.”

Trouble is, as soon as I tried it on my development computer and ran the app, I
got a BSOD BAD_POOL_HEADER Stop 0x19 (0x20, 0x83885258, 0x1a510001).

When it rebooted it crashed again within seconds with a BSOD Stop 0xc4 (0x90,
0xffdff120, 0,0). (This with the 1394 test hardware unplugged so my driver
should not have even loaded after the first reboot).

I recovered by rolling back to ‘last version which worked’.

The MS listing for Stop 0x19 does not show an 0x20 option for param 1, so I’m
not sure what this actually means.

So, any suggestions are welcome, but what may really help me (and maybe others)
is a suggestion of how to get more information after a BSOD when it is on one’s
development machine (or say a customer’s machine). The event viewer just
repeats the info I already have. The second crash also presumably overwrites
any memory dump from the first one - anyway, what tool would one use to examine
that?

Also any idea for the location of a definitive list of bug check codes?

BTW My dev computer also has driver verifier on for this driver.

Thanks in advance, Mike

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

4

Thanks, Gary. Truth is that so far I have not had to analyse a crash dump as the problem has always been amenable to inspection of the source code and the addition of trace information for inspection with remote windbg. I’ll keep looking for how to do it.

Yes - the bug check documentation in the dev tools looks more complete than the MSDN stuff I’d been using in error for reference. Thanks for the pointer.

So I’ll look for how to do it. In the meantime am I right that a second consecutive crash will overwrite the first crash dump?

Meanwhile, an obvious option of swapping round the dev and target machine suggests itself, to get the familiar (to me) windbg output if the crash continues only on the dev machine.

In people’s experience, does Windows often behave significantly differently when /debug is switched on (apart from the obvious delays of TRACE message output of course)?

Thanks, Mike

----- Original Message -----
From: xxxxx@seagate.com
To: Windows System Software Devs Interest List
Sent: Monday, June 12, 2006 3:05 PM
Subject: RE: [ntdev] After the BSOD: Any suggestions?

I?m curious as to how you debugged the driver and not know how to handle a crash dump or where to find a definitive list of bug check codes?

Download the latest ?Debugger tools for Windows?. Google or use some other browser search facility, for WinDbg. It contains all of the Windows debugging tools. The online help provides about as comprehensive a list of bug checks codes as is available.

The first thing to learn about driver development is to always expect the unexpected,

The personal opinion of
Gary G. Little

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Monday, June 12, 2006 8:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] After the BSOD: Any suggestions?

I’ve got a first revision driver that checks out okay on two target computers in free and checked (driver) builds (with driver verifier engaged), so I thought: “Right! now’s the time to run it on my development computer so I can get on with the app which uses it.”

Trouble is, as soon as I tried it on my development computer and ran the app, I got a BSOD BAD_POOL_HEADER Stop 0x19 (0x20, 0x83885258, 0x1a510001).

When it rebooted it crashed again within seconds with a BSOD Stop 0xc4 (0x90, 0xffdff120, 0,0). (This with the 1394 test hardware unplugged so my driver should not have even loaded after the first reboot).

I recovered by rolling back to ‘last version which worked’.

The MS listing for Stop 0x19 does not show an 0x20 option for param 1, so I’m not sure what this actually means.

So, any suggestions are welcome, but what may really help me (and maybe others) is a suggestion of how to get more information after a BSOD when it is on one’s development machine (or say a customer’s machine). The event viewer just repeats the info I already have. The second crash also presumably overwrites any memory dump from the first one - anyway, what tool would one use to examine that?

Also any idea for the location of a definitive list of bug check codes?

BTW My dev computer also has driver verifier on for this driver.

Thanks in advance, Mike

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

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

5

Overwriting dumps: there is an option to NOT overwrite an existing
dumpfile.

In my opinion the dumpfile management provided by Windows, while better
than the competition, still leaves a lot to be desired. For example, why
not offer to record the last N dumps? Why not provide a standard
mechanism to move dumps to an archive location?

In terms of post mortem diagnostics, your driver can record its
activities in a ringbuffer in a format you define that you then write a
kernel debugger extension that understands how to dump. You get a
crashdump, you examine it with your debugger extension, and you figure
out what your driver was doing when the system crashed.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Monday, June 12, 2006 9:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] After the BSOD: Any suggestions?

I’ve got a first revision driver that checks out okay on two target
computers in free and checked (driver) builds (with driver verifier
engaged), so I thought: “Right! now’s the time to run it on my
development computer so I can get on with the app which uses it.”

Trouble is, as soon as I tried it on my development computer and ran the
app, I got a BSOD BAD_POOL_HEADER Stop 0x19 (0x20, 0x83885258,
0x1a510001).

When it rebooted it crashed again within seconds with a BSOD Stop 0xc4
(0x90, 0xffdff120, 0,0). (This with the 1394 test hardware unplugged so
my driver should not have even loaded after the first reboot).

I recovered by rolling back to ‘last version which worked’.

The MS listing for Stop 0x19 does not show an 0x20 option for param 1,
so I’m not sure what this actually means.

So, any suggestions are welcome, but what may really help me (and maybe
others) is a suggestion of how to get more information after a BSOD when
it is on one’s development machine (or say a customer’s machine). The
event viewer just repeats the info I already have. The second crash also
presumably overwrites any memory dump from the first one - anyway, what
tool would one use to examine that?

Also any idea for the location of a definitive list of bug check codes?

BTW My dev computer also has driver verifier on for this driver.

Thanks in advance, Mike

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

6

Marks ring buffer idea works very well, but we use a liberal sprinkling of
debug spew, or debug prints, that go to the debugger console. You can see
this spew on the machine running the driver by simply downloading OSR’s
DbgMon and installing it. I believe mini-dumps, 64K, write themselves
serially, unfortunately you generally need much more info than a mini-dump
provides. Finally, in any kind of post mortem analysis, it is imperative
that you have the latest symbol files for the version of the code you are
targeting.

Gary G. Little

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Monday, June 12, 2006 9:35 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] After the BSOD: Any suggestions?

Thanks, Gary. Truth is that so far I have not had to analyse a crash dump
as the problem has always been amenable to inspection of the source code
and the addition of trace information for inspection with remote windbg.
I’ll keep looking for how to do it.

Yes - the bug check documentation in the dev tools looks more complete
than the MSDN stuff I’d been using in error for reference. Thanks for the
pointer.

So I’ll look for how to do it. In the meantime am I right that a second
consecutive crash will overwrite the first crash dump?

Meanwhile, an obvious option of swapping round the dev and target machine
suggests itself, to get the familiar (to me) windbg output if the crash
continues only on the dev machine.

In people’s experience, does Windows often behave significantly
differently when /debug is switched on (apart from the obvious delays of
TRACE message output of course)?

Thanks, Mike

----- Original Message -----

From: xxxxx@seagate.com

To: Windows System mailto:xxxxx Software Devs Interest
List

Sent: Monday, June 12, 2006 3:05 PM

Subject: RE: [ntdev] After the BSOD: Any suggestions?

I’m curious as to how you debugged the driver and not know how to handle a
crash dump or where to find a definitive list of bug check codes?

Download the latest “Debugger tools for Windows”. Google or use some other
browser search facility, for WinDbg. It contains all of the Windows
debugging tools. The online help provides about as comprehensive a list of
bug checks codes as is available.

The first thing to learn about driver development is to always expect the
unexpected,

The personal opinion of
Gary G. Little

_____

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Monday, June 12, 2006 8:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] After the BSOD: Any suggestions?

I’ve got a first revision driver that checks out okay on two target
computers in free and checked (driver) builds (with driver verifier
engaged), so I thought: “Right! now’s the time to run it on my development
computer so I can get on with the app which uses it.”

Trouble is, as soon as I tried it on my development computer and ran the
app, I got a BSOD BAD_POOL_HEADER Stop 0x19 (0x20, 0x83885258,
0x1a510001).

When it rebooted it crashed again within seconds with a BSOD Stop 0xc4
(0x90, 0xffdff120, 0,0). (This with the 1394 test hardware unplugged so my
driver should not have even loaded after the first reboot).

I recovered by rolling back to ‘last version which worked’.

The MS listing for Stop 0x19 does not show an 0x20 option for param 1, so
I’m not sure what this actually means.

So, any suggestions are welcome, but what may really help me (and maybe
others) is a suggestion of how to get more information after a BSOD when
it is on one’s development machine (or say a customer’s machine). The
event viewer just repeats the info I already have. The second crash also
presumably overwrites any memory dump from the first one - anyway, what
tool would one use to examine that?

Also any idea for the location of a definitive list of bug check codes?

BTW My dev computer also has driver verifier on for this driver.

Thanks in advance, Mike

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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