Sometimes I just can't get crash dump files to generate...

Every once in a while I run across a customer who experiences a blue
screen but just can’t seem to generate a crash dump file. I have them
make sure that their page file is on their boot volume, and that their
page file size is greater than the amount of installed RAM, but still no
crash dump file is generated during the BSOD.

What am I missing here? What are some of the other requirements for
successful dump file generation?

I just heard a (likely distorted) third-hand rumor, supposedly sourced
at Microsoft, that crash dump files will never be generated for certain
bug check codes. Can this be true? If so, why, and for which codes?

Nate

It has been my experience that certain low-level bluescreens (such as
0x00000080 parity errors) will not generate dumps. This kinda makes sense
in that the system is in such as state at that point that the dump can’t be
done.

I have had this exact same problem on my own computer. I’ve been trying
various settings - full memory dump, kernel dump, reboot automatically or
not, but I never got a dump from my blue screens.

The specs:

Windows 2000 Professional, sp3, swedish
Pentium III, 256 MB ram
500-some MB swap file on C:, which runs NTFS and is boot drive

In one instance, the blue screen was generated by a double irp completion in
a capture card driver I was developing. I have no reason to believe that the
driver would be corrupting anything to disrupt the dump writing.

When the system blue screened, I could see hard drive activity as if the
dump was being written, but when the system got back up, there was no dump.
I don’t know exactly how the dump writing works, but it seems to me like the
dump was written down to hard drive but not copied out of the pagefile on
the next reboot?

I have since upgraded the system to 768 MB ram and sp4 and haven’t tried to
generate any crash dumps since, but if anyone has any ideas for getting dump
writing working I’d be happy to try again.

Andreas

----- Original Message -----
From: “Nate Bushman”
To: “Kernel Debugging Interest List”
Sent: Wednesday, September 03, 2003 12:29 AM
Subject: [windbg] Sometimes I just can’t get crash dump files to generate…

Every once in a while I run across a customer who experiences a blue
screen but just can’t seem to generate a crash dump file. I have them
make sure that their page file is on their boot volume, and that their
page file size is greater than the amount of installed RAM, but still no
crash dump file is generated during the BSOD.

What am I missing here? What are some of the other requirements for
successful dump file generation?

I just heard a (likely distorted) third-hand rumor, supposedly sourced
at Microsoft, that crash dump files will never be generated for certain
bug check codes. Can this be true? If so, why, and for which codes?

Nate

Tjena,

As I understand it, when a blue screen occurs and the system is
configured to generate a crash dump file, some or all of the data in RAM
(depending on the dump configuration) will be written (if possible) to
the page file. When the system reboots, before paging is activated the
crash data is copied out of the page file into the dump file. For this
reason you need to ensure that, for full memory dumps, the page file
size is at least as large as the amount of installed RAM. I’ve also
heard that it’s necessary to ensure that the page file resides on the
boot volume if you want to successfully generate crash dump files.

I don’t know if this flush of RAM data to the paging file involves the
drivers in the paging path. My guess is that it doesn’t, but that there
are some smarts built into the kernel to be able to write to the page
file independent of the storage stack drivers. Anyone?

So maybe failed crash dump file generation is caused when the crash
interferes with the kernel’s built-in ability to write to the page file
(independent of the storage stack) or as MaryBeth suggested, perhaps
someone has a bad BugCheckCallback in their driver.

Ha det bra!

Nate

-----Original Message-----
From: Andreas Hansson [mailto:xxxxx@briljant.se]
Sent: Wednesday, September 03, 2003 9:17 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to
generate…

I have had this exact same problem on my own computer. I’ve been trying
various settings - full memory dump, kernel dump, reboot automatically
or
not, but I never got a dump from my blue screens.

The specs:

Windows 2000 Professional, sp3, swedish
Pentium III, 256 MB ram
500-some MB swap file on C:, which runs NTFS and is boot drive

In one instance, the blue screen was generated by a double irp
completion in
a capture card driver I was developing. I have no reason to believe that
the
driver would be corrupting anything to disrupt the dump writing.

When the system blue screened, I could see hard drive activity as if the
dump was being written, but when the system got back up, there was no
dump.
I don’t know exactly how the dump writing works, but it seems to me like
the
dump was written down to hard drive but not copied out of the pagefile
on
the next reboot?

I have since upgraded the system to 768 MB ram and sp4 and haven’t tried
to
generate any crash dumps since, but if anyone has any ideas for getting
dump
writing working I’d be happy to try again.

Andreas

----- Original Message -----
From: “Nate Bushman”
To: “Kernel Debugging Interest List”
Sent: Wednesday, September 03, 2003 12:29 AM
Subject: [windbg] Sometimes I just can’t get crash dump files to
generate…

Every once in a while I run across a customer who experiences a blue
screen but just can’t seem to generate a crash dump file. I have them
make sure that their page file is on their boot volume, and that their
page file size is greater than the amount of installed RAM, but still no
crash dump file is generated during the BSOD.

What am I missing here? What are some of the other requirements for
successful dump file generation?

I just heard a (likely distorted) third-hand rumor, supposedly sourced
at Microsoft, that crash dump files will never be generated for certain
bug check codes. Can this be true? If so, why, and for which codes?

Nate


You are currently subscribed to windbg as: xxxxx@powerquest.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

That is a fairly accurate description of how I understand kernel crash
dumps to work.

It implies that not only there be enough space in the page file, but
enough disk free space for the dump file to be copied out of the page
file at reboot.

Writing a crash dump is a tricky operation, because the OS is crashed,
but enough of the system still needs to be running. Due to the strict
requirements this places on the storage stack non-HCL storage stacks
typically have issues writing crash dumps.

I suggest checking the storage hardware on the machine and verify it is
HCL. Also I suggest checking the event log for clues as to why the dump
was not written.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Wednesday, September 03, 2003 8:34 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to
generate…

Tjena,

As I understand it, when a blue screen occurs and the system is
configured to generate a crash dump file, some or all of the data in RAM
(depending on the dump configuration) will be written (if possible) to
the page file. When the system reboots, before paging is activated the
crash data is copied out of the page file into the dump file. For this
reason you need to ensure that, for full memory dumps, the page file
size is at least as large as the amount of installed RAM. I’ve also
heard that it’s necessary to ensure that the page file resides on the
boot volume if you want to successfully generate crash dump files.

I don’t know if this flush of RAM data to the paging file involves the
drivers in the paging path. My guess is that it doesn’t, but that there
are some smarts built into the kernel to be able to write to the page
file independent of the storage stack drivers. Anyone?

So maybe failed crash dump file generation is caused when the crash
interferes with the kernel’s built-in ability to write to the page file
(independent of the storage stack) or as MaryBeth suggested, perhaps
someone has a bad BugCheckCallback in their driver.

Ha det bra!

Nate

-----Original Message-----
From: Andreas Hansson [mailto:xxxxx@briljant.se]
Sent: Wednesday, September 03, 2003 9:17 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to
generate…

I have had this exact same problem on my own computer. I’ve been trying
various settings - full memory dump, kernel dump, reboot automatically
or not, but I never got a dump from my blue screens.

The specs:

Windows 2000 Professional, sp3, swedish
Pentium III, 256 MB ram
500-some MB swap file on C:, which runs NTFS and is boot drive

In one instance, the blue screen was generated by a double irp
completion in a capture card driver I was developing. I have no reason
to believe that the driver would be corrupting anything to disrupt the
dump writing.

When the system blue screened, I could see hard drive activity as if the
dump was being written, but when the system got back up, there was no
dump. I don’t know exactly how the dump writing works, but it seems to
me like the dump was written down to hard drive but not copied out of
the pagefile on the next reboot?

I have since upgraded the system to 768 MB ram and sp4 and haven’t tried
to generate any crash dumps since, but if anyone has any ideas for
getting dump writing working I’d be happy to try again.

Andreas

----- Original Message -----
From: “Nate Bushman”
To: “Kernel Debugging Interest List”
Sent: Wednesday, September 03, 2003 12:29 AM
Subject: [windbg] Sometimes I just can’t get crash dump files to
generate…

Every once in a while I run across a customer who experiences a blue
screen but just can’t seem to generate a crash dump file. I have them
make sure that their page file is on their boot volume, and that their
page file size is greater than the amount of installed RAM, but still no
crash dump file is generated during the BSOD.

What am I missing here? What are some of the other requirements for
successful dump file generation?

I just heard a (likely distorted) third-hand rumor, supposedly sourced
at Microsoft, that crash dump files will never be generated for certain
bug check codes. Can this be true? If so, why, and for which codes?

Nate


You are currently subscribed to windbg as: xxxxx@powerquest.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Here is one I’ve experienced,

During dump initialization, the boot driver is restarted as a seperate
driver instance. If the driver cannot allocate enough memory for its
internal structures, the dump will fail.

-----Original Message-----
From: Nate Bushman [mailto:xxxxx@powerquest.com]
Sent: Tuesday, September 02, 2003 3:29 PM
Subject: Sometimes I just can’t get crash dump files to generate…

Every once in a while I run across a customer who experiences a blue
screen but just can’t seem to generate a crash dump file. I have them
make sure that their page file is on their boot volume, and that their
page file size is greater than the amount of installed RAM, but still no
crash dump file is generated during the BSOD.

What am I missing here? What are some of the other requirements for
successful dump file generation?

I just heard a (likely distorted) third-hand rumor, supposedly sourced
at Microsoft, that crash dump files will never be generated for certain
bug check codes. Can this be true? If so, why, and for which codes?

Nate

Hej Nate, and the list

I have tried generating a crash dump again, and had no success. I increased my paging file to 1024 MB on C: (boot drive, 14 GB free space) (768 MB RAM in the machine). I set the recovery options to write an event log entry, send an administrative alert, dump kernel memory to %SystemRoot%\MEMORY.DMP and overwrite any existing file.

I then tried to generate a crash dump using BANG! from OSR online, http://www.osronline.com/article.cfm?id=153, but was unsuccessful. I got a blue screen, claiming to write a crash dump, with disk activity and the counter going from 0 to 100 %. After it had completed and been quiet for 10 or so seconds, I proceeded to reset the machine and look for the crash dump and found nothing. No crash dump, no event log entry. The only entries I got were “Microsoft (R) Windows 2000 (R) 5.0 2195 Service Pack 4 Uniprocessor Free.” and that the EventLog service had been started.

I have a Seagate ST3120026A 120 GB IDE hard drive, sitting as a single master connected to the primary onboard IDE channel on a Giga-Byte GA-6VX7-4X motherboard. There is no anti-virus software running on the machine.

How can I check for drivers with BugCheckCallback functions? Or check the storage stack for misbehaving drivers?

Unfortunately, the only machine anywhere near this one is a 486 running Windows 95 that I don’t think windbg will run on, and a modern laptop without a serial port, which makes windbg kernel debugging hard.

Grateful for any advice / tacksam f?r r?d

Andreas

----- Original Message -----
From: “Nate Bushman”
To: “Kernel Debugging Interest List”
Sent: Wednesday, September 03, 2003 5:34 PM
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to generate…

Tjena,

As I understand it, when a blue screen occurs and the system is
configured to generate a crash dump file, some or all of the data in RAM
(depending on the dump configuration) will be written (if possible) to
the page file. When the system reboots, before paging is activated the
crash data is copied out of the page file into the dump file. For this
reason you need to ensure that, for full memory dumps, the page file
size is at least as large as the amount of installed RAM. I’ve also
heard that it’s necessary to ensure that the page file resides on the
boot volume if you want to successfully generate crash dump files.

I don’t know if this flush of RAM data to the paging file involves the
drivers in the paging path. My guess is that it doesn’t, but that there
are some smarts built into the kernel to be able to write to the page
file independent of the storage stack drivers. Anyone?

So maybe failed crash dump file generation is caused when the crash
interferes with the kernel’s built-in ability to write to the page file
(independent of the storage stack) or as MaryBeth suggested, perhaps
someone has a bad BugCheckCallback in their driver.

Ha det bra!

Nate

The reason it didn’t reset automatically was that I hadn’t set that option in the crash recovery settings. Originally it was set to write a small 64kb memory dump and automatically reset, which made it seem like the machine just spontaneously rebooted - the dump was “written” so fast, and then the machine rebooted without a trace of dump or event logs.

When I first got a blue screen on this machine, this quick reboot had me thinking it was a triple fault or an overheating CPU. It wasn’t until I removed the automatic reboot that I realized I was actually seeing a bluescreen. I’ve left it off to make sure I see the difference between bluescreens and self-resets.

To reset the machine now, when testing, I just hit the physical reset switch. Since the hard drive activity had stopped, and I had left it time to settle, I think resetting it should be safe.

Andreas

----- Original Message -----
From: “Croci, MaryBeth”
To: “Kernel Debugging Interest List”
Sent: Monday, September 08, 2003 2:45 PM
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to g enerate…

Well, I don’t know how helpful this is, but I can tell you that this does
NOT sound like the symptom of a buggy BugCheckCallback routine. In that
case, the KeBugCheck code wouldn’t even execute the crash dump code. Since
you are seeing the dump reporting from 0 to 100%, this rules out that
possibility.

Your statement “After it had completed and been quiet for 10 or so seconds,
I proceeded to reset the machine…” might be a clue. Once the OS has
completed writing the crash dump, it should reboot on its own. You
shouldn’t have to reset it. Exactly what did you do to “reset” it?

Sorry I can’t provide anything more useful, other than don’t waste your time
looking for BugCheckCallback routines. Maybe someone else will be able to
add more…

Marybeth Croci

-----Original Message-----
From: Andreas Hansson [mailto:xxxxx@briljant.se]
Sent: Monday, September 08, 2003 8:38 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to
generate…

Hej Nate, and the list

I have tried generating a crash dump again, and had no success. I increased
my paging file to 1024 MB on C: (boot drive, 14 GB free space) (768 MB RAM
in the machine). I set the recovery options to write an event log entry,
send an administrative alert, dump kernel memory to %SystemRoot%\MEMORY.DMP
and overwrite any existing file.

I then tried to generate a crash dump using BANG! from OSR online,
http://www.osronline.com/article.cfm?id=153, but was unsuccessful. I got a
blue screen, claiming to write a crash dump, with disk activity and the
counter going from 0 to 100 %. After it had completed and been quiet for 10
or so seconds, I proceeded to reset the machine and look for the crash dump
and found nothing. No crash dump, no event log entry. The only entries I got
were “Microsoft (R) Windows 2000 (R) 5.0 2195 Service Pack 4 Uniprocessor
Free.” and that the EventLog service had been started.

I have a Seagate ST3120026A 120 GB IDE hard drive, sitting as a single
master connected to the primary onboard IDE channel on a Giga-Byte
GA-6VX7-4X motherboard. There is no anti-virus software running on the
machine.

How can I check for drivers with BugCheckCallback functions? Or check the
storage stack for misbehaving drivers?

Unfortunately, the only machine anywhere near this one is a 486 running
Windows 95 that I don’t think windbg will run on, and a modern laptop
without a serial port, which makes windbg kernel debugging hard.

Grateful for any advice / tacksam f?r r?d

Andreas

> Unfortunately, the only machine anywhere near this one is a 486 running Windows 95 that I don’t think windbg will run on, and a modern laptop without a serial port, which makes windbg kernel

debugging hard.

Hmm, you can use a usb-to-serial adapter on the host (Notebook).

or

If host(notebook) and target(Ga-6XF…) are WinXP and you already have
Firewire in the notebook you might consider to buy a cheap
Firewire-PCI-Card for the target and use that for kernel-debugging.

Norbert.

By any chance do you have this registry key set?

[HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
“ProtectNonPagedPool”=dword:00000001

In order to create crash dumps you must either delete this key or set it to 0.

Niraj

-----Original Message-----
From: Croci, MaryBeth [mailto:xxxxx@stratus.com]
Sent: Monday, September 08, 2003 8:31 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to g enerate…

Well, the reset might be safe, but it’s worth ruling out. Since you no
longer have the 64kb dump configured, and you know that the bug check code
seems to be writing the dump, you might want to configure the automatic
reboot and see if that helps.

If savedump had trouble writing MEMORY.DMP, I think it should log something,
and you said you’re not seeing that, right?

-----Original Message-----
From: Andreas Hansson [mailto:xxxxx@briljant.se]
Sent: Monday, September 08, 2003 10:15 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to
generate…

The reason it didn’t reset automatically was that I hadn’t set that option
in the crash recovery settings. Originally it was set to write a small 64kb
memory dump and automatically reset, which made it seem like the machine
just spontaneously rebooted - the dump was “written” so fast, and then the
machine rebooted without a trace of dump or event logs.

When I first got a blue screen on this machine, this quick reboot had me
thinking it was a triple fault or an overheating CPU. It wasn’t until I
removed the automatic reboot that I realized I was actually seeing a
bluescreen. I’ve left it off to make sure I see the difference between
bluescreens and self-resets.

To reset the machine now, when testing, I just hit the physical reset
switch. Since the hard drive activity had stopped, and I had left it time to
settle, I think resetting it should be safe.

Andreas

----- Original Message -----
From: “Croci, MaryBeth”
To: “Kernel Debugging Interest List”
Sent: Monday, September 08, 2003 2:45 PM
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to g
enerate…

Well, I don’t know how helpful this is, but I can tell you that this does
NOT sound like the symptom of a buggy BugCheckCallback routine. In that
case, the KeBugCheck code wouldn’t even execute the crash dump code. Since
you are seeing the dump reporting from 0 to 100%, this rules out that
possibility.

Your statement “After it had completed and been quiet for 10 or so seconds,
I proceeded to reset the machine…” might be a clue. Once the OS has
completed writing the crash dump, it should reboot on its own. You
shouldn’t have to reset it. Exactly what did you do to “reset” it?

Sorry I can’t provide anything more useful, other than don’t waste your time
looking for BugCheckCallback routines. Maybe someone else will be able to
add more…

Marybeth Croci

-----Original Message-----
From: Andreas Hansson [mailto:xxxxx@briljant.se]
Sent: Monday, September 08, 2003 8:38 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to
generate…

Hej Nate, and the list

I have tried generating a crash dump again, and had no success. I increased
my paging file to 1024 MB on C: (boot drive, 14 GB free space) (768 MB RAM
in the machine). I set the recovery options to write an event log entry,
send an administrative alert, dump kernel memory to %SystemRoot%\MEMORY.DMP
and overwrite any existing file.

I then tried to generate a crash dump using BANG! from OSR online,
http://www.osronline.com/article.cfm?id=153, but was unsuccessful. I got a
blue screen, claiming to write a crash dump, with disk activity and the
counter going from 0 to 100 %. After it had completed and been quiet for 10
or so seconds, I proceeded to reset the machine and look for the crash dump
and found nothing. No crash dump, no event log entry. The only entries I got
were “Microsoft (R) Windows 2000 (R) 5.0 2195 Service Pack 4 Uniprocessor
Free.” and that the EventLog service had been started.

I have a Seagate ST3120026A 120 GB IDE hard drive, sitting as a single
master connected to the primary onboard IDE channel on a Giga-Byte
GA-6VX7-4X motherboard. There is no anti-virus software running on the
machine.

How can I check for drivers with BugCheckCallback functions? Or check the
storage stack for misbehaving drivers?

Unfortunately, the only machine anywhere near this one is a 486 running
Windows 95 that I don’t think windbg will run on, and a modern laptop
without a serial port, which makes windbg kernel debugging hard.

Grateful for any advice / tacksam f?r r?d

Andreas


You are currently subscribed to windbg as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@netapp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Thanks for the suggestions! Unfortunately, I have had no luck with the dump writing yet. I have done the following tests:

Tried setting the computer to reboot automatically after writing the dump - computer does reboot automatically but there’s still no dump.

Verified that the registry key mentioned below wasn’t set - it wasn’t.

Did a secondary Windows 2000 install to another partition and tried to get dumps from it - produces exactly the same results as the first one.

I’m getting no event log entries other than the ones indicating a normal boot, and no dump files. No entries at all from savedump.

I have an idea however that maybe someone could comment on: The BIOS in this machine was unable to handle hard drives larger than 36 some gigabytes, so when I installed this hard drive (120 GB) I had to install something called a “disk overlay”. I had been assuming that that would only affect the early stages of bootup going through int 13, but is it possible (and likely?) that this is somehow interfering with the dump writing?

I have tried to remove the disk overlay after upgrading the BIOS to one compatible with large hard drives, but the tool I used to write it to the hard drive doesn’t want to remove it without wiping the entire hard drive and I’m not quite willing to do that at this time. I may reformat this later when I have time to reinstall all the applications if I can’t find a tool to do it without reformatting.

Andreas

----- Original Message -----
From: “Jaiswal, Niraj”
To: “Kernel Debugging Interest List”
Sent: Friday, September 19, 2003 7:33 AM
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to generate…

By any chance do you have this registry key set?

[HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
“ProtectNonPagedPool”=dword:00000001

In order to create crash dumps you must either delete this key or set it to 0.

Niraj

-----Original Message-----
From: Croci, MaryBeth [mailto:xxxxx@stratus.com]
Sent: Monday, September 08, 2003 8:31 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to g enerate…

Well, the reset might be safe, but it’s worth ruling out. Since you no
longer have the 64kb dump configured, and you know that the bug check code
seems to be writing the dump, you might want to configure the automatic
reboot and see if that helps.

If savedump had trouble writing MEMORY.DMP, I think it should log something,
and you said you’re not seeing that, right?

-----Original Message-----
From: Andreas Hansson [mailto:xxxxx@briljant.se]
Sent: Monday, September 08, 2003 10:15 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to
generate…

The reason it didn’t reset automatically was that I hadn’t set that option
in the crash recovery settings. Originally it was set to write a small 64kb
memory dump and automatically reset, which made it seem like the machine
just spontaneously rebooted - the dump was “written” so fast, and then the
machine rebooted without a trace of dump or event logs.

When I first got a blue screen on this machine, this quick reboot had me
thinking it was a triple fault or an overheating CPU. It wasn’t until I
removed the automatic reboot that I realized I was actually seeing a
bluescreen. I’ve left it off to make sure I see the difference between
bluescreens and self-resets.

To reset the machine now, when testing, I just hit the physical reset
switch. Since the hard drive activity had stopped, and I had left it time to
settle, I think resetting it should be safe.

Andreas

----- Original Message -----
From: “Croci, MaryBeth”
To: “Kernel Debugging Interest List”
Sent: Monday, September 08, 2003 2:45 PM
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to g
enerate…

Well, I don’t know how helpful this is, but I can tell you that this does
NOT sound like the symptom of a buggy BugCheckCallback routine. In that
case, the KeBugCheck code wouldn’t even execute the crash dump code. Since
you are seeing the dump reporting from 0 to 100%, this rules out that
possibility.

Your statement “After it had completed and been quiet for 10 or so seconds,
I proceeded to reset the machine…” might be a clue. Once the OS has
completed writing the crash dump, it should reboot on its own. You
shouldn’t have to reset it. Exactly what did you do to “reset” it?

Sorry I can’t provide anything more useful, other than don’t waste your time
looking for BugCheckCallback routines. Maybe someone else will be able to
add more…

Marybeth Croci

-----Original Message-----
From: Andreas Hansson [mailto:xxxxx@briljant.se]
Sent: Monday, September 08, 2003 8:38 AM
To: Kernel Debugging Interest List
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to
generate…

Hej Nate, and the list

I have tried generating a crash dump again, and had no success. I increased
my paging file to 1024 MB on C: (boot drive, 14 GB free space) (768 MB RAM
in the machine). I set the recovery options to write an event log entry,
send an administrative alert, dump kernel memory to %SystemRoot%\MEMORY.DMP
and overwrite any existing file.

I then tried to generate a crash dump using BANG! from OSR online,
http://www.osronline.com/article.cfm?id=153, but was unsuccessful. I got a
blue screen, claiming to write a crash dump, with disk activity and the
counter going from 0 to 100 %. After it had completed and been quiet for 10
or so seconds, I proceeded to reset the machine and look for the crash dump
and found nothing. No crash dump, no event log entry. The only entries I got
were “Microsoft (R) Windows 2000 (R) 5.0 2195 Service Pack 4 Uniprocessor
Free.” and that the EventLog service had been started.

I have a Seagate ST3120026A 120 GB IDE hard drive, sitting as a single
master connected to the primary onboard IDE channel on a Giga-Byte
GA-6VX7-4X motherboard. There is no anti-virus software running on the
machine.

How can I check for drivers with BugCheckCallback functions? Or check the
storage stack for misbehaving drivers?

Unfortunately, the only machine anywhere near this one is a 486 running
Windows 95 that I don’t think windbg will run on, and a modern laptop
without a serial port, which makes windbg kernel debugging hard.

Grateful for any advice / tacksam f?r r?d

Andreas


You are currently subscribed to windbg as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@netapp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@briljant.se
To unsubscribe send a blank email to xxxxx@lists.osr.com

Further testing, and I now think that I suffer from this problem:

“Hard Disk May Become Corrupted When Entering Standby or Hibernation or When Writing a Memory Dump”

http://support.microsoft.com/default.aspx?scid=kb;[LN];331958

To verify, I tried setting up hibernation on the machine, and I get exactly the results described in that article - the machine does a regular reboot after telling it to hibernate, and the SOFTWARE hive was corrupted and had to be restored.

The one problem remaining is that this is a Windows 2000 system, not Windows XP, so the fix mentioned in the article can’t be applied, and I can’t find a corresponding article for Windows 2000.

Either way, I’m pretty sure that this is the answer to the problem - so it’s a Windows 2000 bug, not anything wrong with the crash dump writing.

Andreas

----- Original Message -----
From: “Andreas Hansson”
To: “Kernel Debugging Interest List”
Sent: Monday, January 01, 2001 8:33 PM
Subject: [windbg] Re: Sometimes I just can’t get crash dump files to generate…

Thanks for the suggestions! Unfortunately, I have had no luck with the dump writing yet. I have done the following tests:

Tried setting the computer to reboot automatically after writing the dump - computer does reboot automatically but there’s still no dump.

Verified that the registry key mentioned below wasn’t set - it wasn’t.

Did a secondary Windows 2000 install to another partition and tried to get dumps from it - produces exactly the same results as the first one.

I’m getting no event log entries other than the ones indicating a normal boot, and no dump files. No entries at all from savedump.

I have an idea however that maybe someone could comment on: The BIOS in this machine was unable to handle hard drives larger than 36 some gigabytes, so when I installed this hard drive (120 GB) I had to install something called a “disk overlay”. I had been assuming that that would only affect the early stages of bootup going through int 13, but is it possible (and likely?) that this is somehow interfering with the dump writing?

I have tried to remove the disk overlay after upgrading the BIOS to one compatible with large hard drives, but the tool I used to write it to the hard drive doesn’t want to remove it without wiping the entire hard drive and I’m not quite willing to do that at this time. I may reformat this later when I have time to reinstall all the applications if I can’t find a tool to do it without reformatting.

Andreas