Hibernate/volmgr/crashdump disk problem after migration to new system

I recently migrated from my aged old box to a shiny new system, but though most of the migration went flawlessly there's two glaring and possibly related problems: crash dumps appear to be broken and I cannot hibernate.


The computer is a little confused about its capabilities according to diskpart. The new drive is an SSD which reports the following:

SAMSUNG SSD 830 Series ATA Device
Disk ID: xxxxxxxx
Type : SATA
Status : Online
Path : 0
Target : 0
LUN ID : 0
Location Path : PCIROOT(0)#PCI(1F02)#ATA(C00T00L00)
Current Read-only State : No
Read-only : No
Boot Disk : Yes
Pagefile Disk : Yes
Hibernation File Disk : No
Crashdump Disk : No
Clustered Disk : No

What catches my eye is that, despite it being the only disk in the computer (and having sufficient pagefile space available and managed) its not considered a "crashdump disk". In fact, if I edit the crash dump settings in the Startup and Recovery dialog, I get an error event in volmgr (45 - "The system could not sucessfully load the crash dump driver.") Every single time. I even tested a crash dump with the ctrl-scroll technique... no crash dump was saved to the disk despite the BSOD.

As for hibernation, it's simple: if I try to hibernate, the screen goes blank for a few seconds and then I'm at my password prompt - and volmgr throws another event 45 in the log. (Note that "Hibernation File Disk" was "no" on my old rig as well... and it hibernates just fine, whereas the "Crashdump Disk" setting used to be a firm "yes").

I've used system repair to carefully remove and re-create the BCD file... the system still boots fine though this problem was not resolved by that. I strolled through HKEY_LOCAL_MACHINE\BCD00000000 but didn't find any obvious smoking gun (it's not clear that I could edit settings there if I wanted to though, given how its permissions are structured). I even might re-migrate as an offline test on another drive, just to see if this changes... though that doesn't really solve the problem. I suspect it's something really, really simple... I just wish I could zero in on what it is.

So, I wonder, has anyone run into this sort of thing before? How might I get crash dumps working again, without resorting to an extremely tedious reinstall? And I suppose, how might I get hibernation working again? I feel that the two are interrelated but I have a feeling the crash dump thing is the main problem - and it certainly would be useful were a BSOD ever to occur!

Nevermind - it boiled down to uninstalling some software that hooked into the crash dump handler. In short, should you encounter this same issue, check the registry at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\DumpFilters

And start uninstalling the parent of things there one by one. Don't just edit the list in the Registry... that may not suffice (or could cause even more problems).

It's surprising how many things are affected by this (like hibernation) that you wouldn't expect to care about crash dump filters....