Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Note: I'm using a Samsung 830 SSD (migrated OS from defunct PC) and other than these two (interrelated?) problems it's working fine. Surprisingly well actually. Motherboard is a ASUS P8Z77-V Deluxe.

Problem 1: Crashdumps are not working. volmgr throws an event 45 "The system could not sucessfully load the crash dump driver." whenever you modify crashdump settings, or if a crashdump occurs. diskpart says that "Crashdump disk = no" which is peculiar.

Problem 2: Hibernation isn't working. Again, volmgr throws the same event 45 if you try to hibernate. The screen blanks, then you're at the password prompt. No sleepage occurs. (Yes, I know I should avoid hibernation on SSDs but it's enabled and the hibernation file is definitely there so I'd like to know why it's failing). Diskpart claims "Hibernation file = no" which is again peculiar... it's plainly there and getting created by the system.

The common factor appears to be volmgr and/or the crashdump "service" (if that's what it is). I'd much rather get this working than spend days reinstalling and reconfiguring the entire system, especially when it's working perfectly otherwise. Sleep works as well (as long as it's not hybrid sleep).

So, what defines the flags "Crashdump disk" and "Hibernation file disk" in diskpart's output? And what might be going wrong that's breaking crashdumps in particular?

share|improve this question
    
Try disabling hibernation and rebooting, then enabling it again. Windows might be struggling due to the hardware change. You might even set the swap file to "managed by the system" and reboot, followed by setting it back to what it was prior to that. –  Mark Allen Sep 17 '12 at 4:04
    
I'll fiddle with it more soon. I tried disabling the pagefile and rebooting a couple of times, will try doing that with hibernation disabled as well. The "hibernation File" thing may be unrelated... seems it's like that on the old box as well (and it has no such problems). The "Crashdump Disk = no" thing is, however, extremely weird and needs fixing - if only I knew what was broken. –  MartyMacGyver Sep 17 '12 at 17:56
    
So far no joy. It'd be a lot simpler if I knew how "Crashdump Disk = No" is actually determined. –  MartyMacGyver Sep 18 '12 at 9:22
    
I figured it out... see my answer. –  MartyMacGyver Sep 18 '12 at 10:56
add comment

1 Answer

up vote 1 down vote accepted

I ended up cloning the new disk and running some rather destructive tests on it. But somewhere between uninstalling the hard drive itself in the device manager and uninstalling TrueCrypt I managed to get it working again!

I actually think it was just uninstalling TrueCrypt to be honest. It hooks into the crash handler at a low level:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\DumpFilters

Which I knew, and even modified at one point... but evidently I didn't go deep enough. Other things hook into there as well, but in this case removing the one app was enough to kick things in the right direction.

Once I did that and rebooted the problem disappeared. No more weird volmgr events, no more hibernation problems, and I suspect crashes will be logged normally again (as rare as I hope they remain). Reinstalling TrueCrypt didn't reintroduce the problem - perhaps it wasn't that but an interaction with some other driver that got tangled up. Either way, the problem is solved!

share|improve this answer
    
Aha. See, you don't mention TrueCrypt in your question at all, or most of us would probably have jumped all over it. Good info to have though! Now I'm curious to see what they (TrueCrypt) recommend for SSDs and whole-disk encryption etc. Good stuff, glad you got it working! –  Mark Allen Sep 18 '12 at 20:28
    
Not sure why... the fact that it hooks into DumpFilters isn't widely known (what happened here is very uncommon apparently), and is only there as I recall specifically because of the system encryption functionality - so you can get crash dumps saved before halting (note: system was not encrypted during this issue). As for whole-disk performance, it's great... the only worry they raise is data leakage on initial encryption and deniability - edge cases I'm not concerned about (I just want my data secure if it's ever stolen). Encryption is in-memory first so the write cost isn't bad either. –  MartyMacGyver Sep 18 '12 at 21:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.