Windows 10 crash dumps not saving more than one?

I had Windows set to keep as many crash dumps as possible in the drive
as there was space for. That was working fine up until Windows 7. The
machine has been updated to Win 10 now obviously, and now whenever a
BSOD occurs, it overwrites the previous crash dump. I've got it set to
save small memory dumps rather than kernel dumps or full memory dumps.
But the settings for crash dumps has the options for "Overwrite any
existing file" and "Disable automatic deletion of memory dumps" disabled
when I choose small memory dumps.

Any idea why these options are disabled?

On Wed, 30 May 2018 06:16:08 -0400, Yousuf Khan
wrote:

I had Windows set to keep as many crash dumps as possible in the drive
as there was space for. That was working fine up until Windows 7. The
machine has been updated to Win 10 now obviously, and now whenever a
BSOD occurs, it overwrites the previous crash dump. I've got it set to
save small memory dumps rather than kernel dumps or full memory dumps.
But the settings for crash dumps has the options for "Overwrite any
existing file" and "Disable automatic deletion of memory dumps" disabled
when I choose small memory dumps.

Any idea why these options are disabled?

Might be Windows 10 default.
Try enabling them.

Yousuf Khan wrote:
I had Windows set to keep as many crash dumps as possible in the drive
as there was space for. That was working fine up until Windows 7. The
machine has been updated to Win 10 now obviously, and now whenever a
BSOD occurs, it overwrites the previous crash dump. I've got it set to
save small memory dumps rather than kernel dumps or full memory dumps.
But the settings for crash dumps has the options for "Overwrite any
existing file" and "Disable automatic deletion of memory dumps" disabled
when I choose small memory dumps.

Any idea why these options are disabled?

Pictures of the interfaces are here.

https://www.tenforums.com/tutorials/...dump-bsod.html

And I see the same thing in 17034 here, with no explanation why.

You can change to one of the other modes, and change the tick
boxes, but I doubt that means the tick boxes actually apply
when they're grayed out like that.

https://s15.postimg.cc/xn4t502ln/minidump_options.gif

Paul

On 5/31/2018 1:59 AM, Paul wrote:
And I see the same thing in 17034 here, with no explanation why.

You can change to one of the other modes, and change the tick
boxes, but I doubt that means the tick boxes actually apply
when they're grayed out like that.

https://s15.postimg.cc/xn4t502ln/minidump_options.gif

Paul

Well, if you are seeing the same thing, then it's probably not a bug in
my setup, it's a feature?

Yousuf Khan

Yousuf Khan wrote:
On 5/31/2018 1:59 AM, Paul wrote:
And I see the same thing in 17034 here, with no explanation why.

You can change to one of the other modes, and change the tick
boxes, but I doubt that means the tick boxes actually apply
when they're grayed out like that.

https://s15.postimg.cc/xn4t502ln/minidump_options.gif

Paul

Well, if you are seeing the same thing, then it's probably not a bug in
my setup, it's a feature?

Yousuf Khan

It only becomes a "feature" when it screws up.

The minidump thing has traditionally supported
multiple (tiny) dump files, without a problem.
I was using dumpchk.exe on .dmp files in
WinXP, as an example. And Nirsoft has their
BlueScreenView for that.

I don't seem to have a Minidump folder.
Does yours have one ? Adding one seemed to make
no difference.

Paul

On 5/31/2018 4:04 AM, Paul wrote:
It only becomes a "feature" when it screws up.

The minidump thing has traditionally supported
multiple (tiny) dump files, without a problem.
I was using dumpchk.exe on .dmp files in
WinXP, as an example. And Nirsoft has their
BlueScreenView for that.

I don't seem to have a Minidump folder.
Does yours have one ? Adding one seemed to make
no difference.

Paul

One exists at %SystemRoot%\Minidump, but it's empty. I had a crash just
a couple of days ago, and something has already erased it, unbeknownst
to me!

Yousuf Khan

Lucifer Morningstar wrote:

Yousuf Khan wrote:

I had Windows set to keep as many crash dumps as possible in the
drive as there was space for. That was working fine up until Windows
7. The machine has been updated to Win 10 now obviously, and now
whenever a BSOD occurs, it overwrites the previous crash dump. I've
got it set to save small memory dumps rather than kernel dumps or
full memory dumps. But the settings for crash dumps has the options
for "Overwrite any existing file" and "Disable automatic deletion of
memory dumps" disabled when I choose small memory dumps.

Any idea why these options are disabled?

Might be Windows 10 default. Try enabling them.

Since a minidump is often unhelpful to analyze in-depth a continuing
problem in a Windows setup, techs want more detailed dumps. There might
be just enough info in a minidump to tell you why a BSOD occured but the
info is limited and really just for the prior Windows session.

https://support.microsoft.com/en-us/...ns-for-windows
Does not explicitly list Windows 10. Could be the article has not been
updated to reflect Windows 10 (although the article says "Last Updated:
Apr 17, 2018), or perhaps behavior has changed in Windows 10.

Section: Small memory dump

This kind of dump file can be useful when space is limited. However,
because of the limited information included, errors that were not
directly caused by the thread that was running at the time of the
problem may not be discovered by an analysis of this file.

A minidump is really only useful for only a single Windows session, not
for a history or timeline of BSODs, and only indicates the problem
source if the cause is not too dependent (the chain doesn't get too long
or has too many branches).

If a second problem occurs and a second small memory dump file is
created, the previous file is preserved. Each additional file is given
a distinct name. The date is encoded in the file name.

The overwrite option is disabled (although shown checked) because the
minidump files are [supposed to be] retained. While they are smaller
than the other dump schemes, someone that keeps rebooting a failing
Windows setup could end up consuming a lot of disk space with a
multitude of dump files. That's why it is recommended to NOT allow
automatic restart of Windows after a BSOD. In an unattended host, the
machine would keep rebooting, crashing, rebooting, crashing, and
continue ad naseum while creating lots of dump files on the drive.

According to Microsoft, and as expected by Yousuf, the minidump files
are or should be retained for multiple BSODs. That's why the overwrite
option is disabled: it is not applicable for minidumps (you cannot
enable the overwrite). That they are disappearing makes me wonder if
Yousuf uses some cleanup tool that deletes the minidump files, like the
Windows cleanup wizard (which can be scheduled), CCleaner (which can be
scheduled using "ccleaner.exe /auto"), or something else that includes
deleting temp files, web browser caches, cookies, and also dump files.
By default, as an example only, CCleaner will delete dump files. You
have to go into its config to deselect that option.

Another possibility is that no dump file got created. To write a copy
of memory into a file means the OS must still be sufficiently capable of
executing its system calls to read memory and write into a file. If the
problem is due to faulty hardware, the crash could be so hard and
immediate that the OS never gets a chance to read memory and create the
dump file or even to add an entry into the event logs. If the problem
is a hang instead of a crash, again, the OS may itself be hung so
perform the operations to read the memory and write into a dump file.

I don't see Yousuf ever noted what are the stop and error codes in the
BSOD. Is he actually getting BSODs or hard crashes or hangs? Also,
maybe Yousuf's Windows 10 setup is from an upgrade that lugs along all
the old pollution along with incompatible drivers instead of doing a
fresh install of Windows 10.


----------
NOTE: I'm not seeing Yousuf's posts in this newsgroup on the NNTP server
that I use (individual.net). In my client, filtered posts are not
deleted, just ignore-flagged and using a default view that hides ignored
posts, so I can use the All Messages view to even see flagged posts.
His are not getting flagged to get hidden from view in my client.
Rebuilding the thread (asking the server to get missing posts in a
thread) doesn't work.

http://al.howardknight.net/msgid.cgi...iganews.com%3E

Nothing unusual in the headers to indicate why Individual doesn't have a
peered copy of Yousuf's posts from Giganews. Whatever the cause, I
won't see Yousuf's posts, only others that reply to him. I don't have
an account at Giganews to look at their control.cancel newsgroup to
check if Yousuf is cancelling his posts.

ken1943 wrote:
On Thu, 31 May 2018 09:16:51 -0400, Yousuf Khan
wrote:

On 5/31/2018 4:04 AM, Paul wrote:
It only becomes a "feature" when it screws up.

The minidump thing has traditionally supported
multiple (tiny) dump files, without a problem.
I was using dumpchk.exe on .dmp files in
WinXP, as an example. And Nirsoft has their
BlueScreenView for that.

I don't seem to have a Minidump folder.
Does yours have one ? Adding one seemed to make
no difference.

Paul
One exists at %SystemRoot%\Minidump, but it's empty. I had a crash just
a couple of days ago, and something has already erased it, unbeknownst
to me!

Yousuf Khan

It saves as a file, not using a folder. Never had a crash to check !

There's more than one kind of crash dump.

These are minidmp files, which are less than a megabyte,
and contain a stack trace, without saving the entire
state of machine memory. And that's why they're stored
in the "minidmp" folder. There's room for lots of
them.

Whereas a full dump, there could be a MEMORY.DMP file which
is the same size as system memory. If you have 64GB of DDR4
DIMMs in the system, you could get a 64GB file. This captures
the complete state of the machine, which is helpful to at least
some people doing forensic analysis.

But if you're getting one crash after another, and the minidmp
keeps having the same driver file, you know your trouble it
somehow related to that driver (or some driver interaction).

At one time, Dr.Watson would "steal" the dump info, not keep
a copy locally, and forward it to Microsoft. And you had to
configure the System control panel setting for what to do,
to change that, plus maybe edit a registry setting or two.

Paul

Yousuf Khan wrote:
On 5/31/2018 4:04 AM, Paul wrote:
It only becomes a "feature" when it screws up.

The minidump thing has traditionally supported
multiple (tiny) dump files, without a problem.
I was using dumpchk.exe on .dmp files in
WinXP, as an example. And Nirsoft has their
BlueScreenView for that.

I don't seem to have a Minidump folder.
Does yours have one ? Adding one seemed to make
no difference.

Paul

One exists at %SystemRoot%\Minidump, but it's empty. I had a crash just
a couple of days ago, and something has already erased it, unbeknownst
to me!

Yousuf Khan

Windows 10 has a Reliability Monitor, which produces a summary
of "events" on the machine, such as your BSODs. You could
use that to track down the events, and see if the dump
information is stored elsewhere.

https://images.techhive.com/images/a...789-large.jpeg

Typing "Reliability Monitor" in Cortana should get you there.

Paul

On 5/31/2018 9:39 AM, ken1943 wrote:
One exists at %SystemRoot%\Minidump, but it's empty. I had a crash just
a couple of days ago, and something has already erased it, unbeknownst
to me!

Yousuf Khan

It saves as a file, not using a folder. Never had a crash to check !

Not the minidumps, they save as files within a separate folder. That way
you could save as many dumps as you have space for historical analysis.
That's what I used to do on pre-Windows 10 days, keep small crash dumps
around to see if something is repeating consistently.

Yousuf Khan

On 5/31/2018 3:04 PM, Paul wrote:
Windows 10 has a Reliability Monitor, which produces a summary
of "events" on the machine, such as your BSODs. You could
use that to track down the events, and see if the dump
information is stored elsewhere.

https://images.techhive.com/images/a...789-large.jpeg


Typing "Reliability Monitor" in Cortana should get you there.

Paul

Yes, totally forgot about that tool, used to use it quite a lot! I'll
see how much info it retains. I gather probably not nearly as much as
the crash dump itself would?

On 5/31/2018 2:52 PM, Paul wrote:
There's more than one kind of crash dump.

These are minidmp files, which are less than a megabyte,
and contain a stack trace, without saving the entire
state of machine memory. And that's why they're stored
in the "minidmp" folder. There's room for lots of
them.

Whereas a full dump, there could be a MEMORY.DMP file which
is the same size as system memory. If you have 64GB of DDR4
DIMMs in the system, you could get a 64GB file. This captures
the complete state of the machine, which is helpful to at least
some people doing forensic analysis.

But if you're getting one crash after another, and the minidmp
keeps having the same driver file, you know your trouble it
somehow related to that driver (or some driver interaction).

At one time, Dr.Watson would "steal" the dump info, not keep
a copy locally, and forward it to Microsoft. And you had to
configure the System control panel setting for what to do,
to change that, plus maybe edit a registry setting or two.

Paul

So far, I've asked this question on Microsoft's Answers and Technet
communities, have received absolutely no answers on either one. This is
the only place getting answers.

Yousuf Khan

Yousuf Khan wrote:
On 5/31/2018 2:52 PM, Paul wrote:
There's more than one kind of crash dump.

These are minidmp files, which are less than a megabyte,
and contain a stack trace, without saving the entire
state of machine memory. And that's why they're stored
in the "minidmp" folder. There's room for lots of
them.

Whereas a full dump, there could be a MEMORY.DMP file which
is the same size as system memory. If you have 64GB of DDR4
DIMMs in the system, you could get a 64GB file. This captures
the complete state of the machine, which is helpful to at least
some people doing forensic analysis.

But if you're getting one crash after another, and the minidmp
keeps having the same driver file, you know your trouble it
somehow related to that driver (or some driver interaction).

At one time, Dr.Watson would "steal" the dump info, not keep
a copy locally, and forward it to Microsoft. And you had to
configure the System control panel setting for what to do,
to change that, plus maybe edit a registry setting or two.

Paul

So far, I've asked this question on Microsoft's Answers and Technet
communities, have received absolutely no answers on either one. This is
the only place getting answers.

Yousuf Khan

But we still haven't figured out that interface quirk.

And I'm not seeing any hints in the registry section
that claims to control this stuff. The minidump folder
location should be stored in the registry. The registry
entry names have changed a bit since WinXP. There's a
"flags" entry, which I haven't been able to decode.
Previously, they used a boolean per feature for whatever
the "flags" byte controls.

The Microsoft MVP system rewards "evangelism", not
"question answering", so naturally the pool of information
sources will be different now.

Paul