Windows minidump not generated

Hi i am using vista ultimate x64 and 8 month's ago system stopped generating minidumps, reloading after bsod (even with proper settings) and showing "problem occurred" window after reboot. I have been viewing lots of forums, reading articles and even powerpoint presentation specifically on this issue and posted on technet forum, yet no one was able to help and propose a solution for that problem, xept perhaps reinstalling vista.

I have been gradually removing possible causes for that and so far found that this isn't related to:

1)minidumps settings and pathway - they seem to be perfectly fine even in registry
2)DEP (data execution prevention) - i don't know if its possible to switch this off completely but currently it only applies to vital windows processes and shouldn't be a problem
3)hardware - cant be 100% sure but apart from memory sticks (which i have swapped and tested) nothing else should cause this
4)paging files - are big enough and present on all disks same as when minidumps used to work

5)By checking last successfully created minidump through system logs i found that it happened 8 months ago, on the same day when i installed nvidia forceware network access manager, so i uninstalled it and by manually generating BSOD found that pc reboots now, though it might be a coincidence.

6)I also checked running services and tried to activate "Diagnostic System Host" and "Diagnostic Service Host", though only system host actually activated im not sure if they are supposed to be working at all and related to this issue.

Thing that bothers me the most is that vista no longer shows "problem occurred" window upon reboot after BSOD happened, also windows logs actually just show that last session ended unexpectedly or abruptly but doesn't mention anything about dumps or problems. Im not sure if that infamous window supposed to pop only when minidump created but perhaps its just that some service or registry responsible for both dump and that window broke.

If anyone has any suggestions or had same issue and found radical solution that seems to elude me, i really would like to hear it.

Do you currently have a pagefile on the boot partition (where \Windows is located) and how big is it?

Failure to generate kernel dumps can sometimes be caused by the fact that the specific problem is in the I/O path which leads to HDD data committment - the disk driver suffered a heart-attack for example.

I'd like to understand why you're interested in seeing dumps generated in this context. Is the machine bluescreening currently? Can you actually see a BSoD (white text on blue background...), or is it perhaps simply rebooting for reasons unknown? If it's the latter, the problem may not actually be a bugcheck ("BSoD"). Reboots can happen for all sorts of reasons that are not directly triggered by software.

Yes as i wrote above i have sufficient pagefiles on all disks including boot partition. And no for the past few month's i didn't have any BSOD's. I can however manually create BSOD's and i can see both blue window, white text and infact windows sais that it has created minidump.

Again as i wrote above my system USED to create minidumps when i had occasional problems, then for some reason it STOPPED doing so, no i dont really need them because i proly know every single system proccess, file and driver related issue on vista.

Yet i do want my system to create minidumps and show me "problem occured" window after reboot, because it supposed to do so and this issue has been bothering me for a long time.

How big is that sufficient pagefile on the boot partition? (The other pagefiles don't matter at all in this context.)

What type of machine is this? If it's server hardware, it may have an ASR agent running which causes the BIOS to trigger a hard reboot when it detects a lack of response from the software component. That usually leads to truncated dumps though.

Is a full dump being generated? The existence/ability to generate a full dump is necessary for a minidump "summary".

What type of drive is backing the boot partition? SAN-attached drives can be very problematic for dump generation. Again, that's (upper end) server hardware, so nothing to worry about if the machine is consumer hardware.

How are you triggering a bugcheck for test purposes? CrashOnCtrlScroll? NotMyFault.exe? Something else? Same if you attempt that from safe mode?

Boot partition has 4700-5000mb pagefile set - more than enough to create minidump. This is isn't a server but a normal PC. Full dump cant be generated with 4gb of memory, but i will remove 3 planks and try it with 1 gb. Boot partition is located on sata raid-0 with 2 150gb raptors. I trigger bsod's with notmyfault.exe, tho i did try to use invalid drivers once and result was the same - minidump weren't produced. And i will try to do that in safemode too.

A "full" dump is a kernel dump in this context. If the settings are for a "kernel" dump, theoretically you should see a 200MB-1GB memory.dmp file from which the minidump is subsequently extracted. Is there a memory.dmp file being generated when you bugcheck the box?

A "complete" dump, including user-mode pages, shouldn't make any difference, but if you do wish to try that it's easier to use the removememory parameter with BCDEDIT than to physically rip out DIMMs:

bcdedit /set {GUID} removememory <MbToRemove>

For example, if you create another boot config entry (not a good idea to experiment on the default boot entry), you could "... removememory 3072" and the OS will then limit itself to 1GB and allow the selection of a complete dump configuration. There's also a hack that can be done to display the complete dump option in the UI even with >2GB but the method above has advantages.

The most likely explanation is a driver in the I/O stack which is interfering.

Well i have done several tests and it turned out that minidumps were created perfectly fine with 1 and 3 planks installed, full dump also worked with 1 gb plank and each time "problem occurred" window poped out properly upon reboot.

But with 4 planks it just doesn't work. So any suggestions on why would vista deny minidump creation when 4gb ram installed? It used to work just fine.

I have also just tried to create kernel dump. During bluescreen it actually had progress in % going, but upon reboot memory.dmp wasn't present.

Celarion said:

I have also just tried to create kernel dump. During bluescreen it actually had progress in % going, but upon reboot memory.dmp wasn't present.

Click to expand...

What brand/model is the machine?

Did you see it hit "100%" while it was writing a kernel dump or did it seem to abort before it got to the 100% mark?

Ehum its asus striker 2 formula motherboard with corsair xms2 6400 planks, 9800 gtx nvidia videocard, two 150gb raptors in raid and 500 gb seagate spare, plus 1200W thermaltake PSU and e8500 processor. Yes i saw it hit 100% and it didnt seem to abort. I have just removed another plank from different slot and again minidumps and bug reports worked fine.

This has to be settings issue, either vista doesn't want to create dumps for more than 4gb or something else prevents it.

I've got a 4GB x64 machine which generates dumps happy-as, so there's more to it than that.

My guess is that you've got an interfering driver which is making some sort of memory alloc (that fails) at a critical time, but direct debugging of that situation is not worth it for a single box - it would be quicker to reinstall if nothing jumps out at you from the list of drivers.

But why it happens only with 4gb then? What sort of driver would actually care whether its 1 2 3 or 4 gb ram installed? Maybe you know what part of vista, or which vista driver directly connected to amount of ram installed?

Celarion said:

But why it happens only with 4gb then? What sort of driver would actually care whether its 1 2 3 or 4 gb ram installed? Maybe you know what part of vista, or which vista driver directly connected to amount of ram installed?

Click to expand...

There's little point in me speculating because the actual reasons for the failure are unknown at this point, at least to me. I've seen situations where drivers attempted to malloc at critical times ("thanks, I'll want more memory for myself if I'm being asked to process another 2GB after the first 2GB..."), and that can lead to a complete breakdown when it happens during a bugcheck. However, I don't know whether your situation matches that in any way.

I'm relatively confident that it's not a default Vista driver because, like I said, I've got a test x64 machine with 4GB that dumps without problem. Instead, the cause is likely environmental - a driver which was introduced on your machine at the time that memory dumping ceased.

Did you end up testing what happens in safe mode?

notmyfault couldn't be run under safe mode and for some reason i cant set CrashOnCtrlScroll on vista.

Celarion said:

notmyfault couldn't be run under safe mode and for some reason i cant set CrashOnCtrlScroll on vista.

Click to expand...

Sorry dude. It's possible to deterministically troubleshoot anything at all, including very low-level problems like this one, and if you want I'll keep making suggestions for how you might get closer to the cause. In this case, however, I think the effort outweighs the benefits, especially since you don't actually have an ongoing bugcheck issue per se.

It might be a very low-level problem for a person who doesn't have any other ongoing issues or a person who knows what causes an issue. I noticed however other peoples on on other forums not having minidumps created and not finding obvious causes for that and having ongoing bsod's issues and not be able to analyse dumps.

Anyway thx for all the help and suggestions, im still somehow convinced that its vista's driver's fault, ill keep looking.

Celarion said:

It might be a very low-level problem for a person who doesn't have any other ongoing issues or a person who knows what causes an issue. I noticed however other peoples on on other forums not having minidumps created and not finding obvious causes for that and having ongoing bsod's issues and not be able to analyse dumps.

Anyway thx for all the help and suggestions, im still somehow convinced that its vista's driver's fault, ill keep looking.

Click to expand...

I meant low-level as in "close to the hardware and tricky to troubleshoot", not "low in importance".

Good luck with your search.