Diagnosing a hibernation problem

[BonzaiDuck]

Would it be likely that an aging PSU would cause a system to occasionally hang after shutdown when you expect it to beep and post the reboot, requiring a reset? Or -- similarly -- to throw an error with boot-time menu selection returning from hibernation? Or to have the system fail to complete the necessary handshaking with USB Keyboard until logon screen appears?

Or could it be a failing CMOS battery?

I have to troubleshoot this, because I was planning to re-purpose the 2600K system in my sig, and hadn't tested hibernate or sleep for some time. It absolutely positively must be able to hibernate and wake reliably.

These symptoms occur with the spotty frequency I described even after setting the clocks to default. With the OC'd clocks, the system still passes a full LinX stress-test with flying colors.

I could also flash the BIOS, reinstall all the drivers if I have to.

Just seeking some insights to this, because it would seem that an aging PSU would cause it. It's 5+ years old, past the warranty for a Seasonic 850 Gold.

And the system has been running pretty much continuously since I built it in 2011. Disks are relatively new; gfx card two years old. RAM is at most 3 years old.

 

[UsandThem]

I'd see if their were any BIOS updates, and flash that if any newer one mentions stability in the notes. Is a clean install of the OS an option?

Are the hangs/crashes causing any dumpfiles to be created? http://www.resplendence.com/whocrashed

The problem with this type of issue, if it isn't a driver/software issue, it can be caused by a flaky PSU, HDD, motherboard, ram, etc. Unfortunately the only way to rule out flaky hardware is to replace it known good hardware to rule it out, or test it. You could try running the PC with only the CPU, one stick of RAM, and the OS drive and see if you still get the crashes.

Does it do the same thing when putting the computer to sleep, or is it just with hibernation?

 

[BonzaiDuck]

The mobo shipped with version 505 BIOS, and I believe the current 606 was either the second or third revision. The problem with 606: Enabling PLL Overvoltage for the OC would cause a failure to come out of sleep. I decided I didn't need to change the default on PLL_OV -- thus disabled. Had no other reasons to update the BIOS.

Of course, this is now on the menu of options to pursue. the system has to be made reliable for the 91-year-old. I could tell her just to shutdown after using, but that's inconvenient. Extended sleep is bad for components, but to answer your question, there seems to be no problem with sleep mode.

The hangs don't cause any dumpfiles, nor any error window to be raised after boot to desktop, nor any Event ID 41 critical errors as one might find with a BSOD or hard reset.

But I've encountered descriptions on Windows forums in which all of my symptoms are in a subset. It is more likely for the problem to occur with a laptop, but again -- the fixes may overlap or be the same.

For the symptom that system post will be followed by a blank screen posing temptation for a reset (but that's the only way to restart), and the symptom that "starting windows" splash screen will progress to a blinking cursor and no desktop, the recommendation includes updating the graphics driver.

I did that. Now here's what I discovered, and I have no sense of how it may be suspect, but it is.

I wanted to replace a 20-year-old KVM (PS/2) with a USB/DVI 4K-capable KVM. I bought a particular model of Avocent 4-port KVM. I discovered it is not HDCP compliant. For switching the mouse-keyboard, it's just fine.

But here's another symptom. When coming out of hibernation and possibly sleep, the post shows "no keyboard detected." When logging on -- assuming the previously described symptoms don't occur -- the kybd and mouse (connected to the piece-a-crap Avocent KVM) Windows picks up the devices and they're fully functional, but you could see how this could be a problem for getting into BIOS.

And for doing that, I'd have to plug in another kybd before post and BIOS entry (or I couldn't "enter.") Now I'm beginning to think that hibernation works when there is a directly-connected kybd and/or mouse, and that these other problems occur when the PC is only connected to the KVM.

USB device malfunctions have also been listed as indications of PSU deterioration. I can only say from the HWMonitor information that this PSU is volting just the way it was when new. All the essential 12, 5, and 3.3V rails show an overage just within the +/- 2% ATX PSU spec.

On the other hand, this phenomenon of USB kybd and mouse also occurs on my new Z170 Skylake system -- in which Windows also picks up the device functionality at the time it is needed at logon. And it is also connected to this P-O-S KVM.

Either way this shakes out, I'm refortified in the conviction that a spare wireless kybd and mouse is a useful thing to keep around.

UPDATE: Only for two time-series observations in a row and begging for an accumulation of similar tests, the wireless kybd and mouse directly-connected seems to resolve this.

I bought the KVM in an interest-free promotional purchase above a dollar-limit. I had to test everything within the 30-day RMA window, and got it set up at the very end. Only noticed the HDCP compliance problem a week or so later. This comes six weeks after that.

UPDATE2: Also -- about the OS reinstall option -- this is indeed on the table. Sources like Maximum PC magazine had recommended annual re-installs. I don't believe this is necessarily true, if you do regular maintenance. CCleaner has also been of help. In fact, this installation is really a "recovered" re-tread from our WHS'11. I had cleaned up an incredible amount of stuff, and the event logs look very clean except for benign warnings, errors loading NetTV for Media Center (I think I can fix that, too), and errors of known origin that I can fix.

My concerns for Moms' "new" sandy bridge and the urgency of her use of it give me time to set all this straight. If I don't, there will be more trouble down the road.

And PS: We now have three successful wake-from-hibernate observations in a row with another USB keyboard connected. Still inconclusive, but we'll see . . .

 

[BonzaiDuck]

Last post was probably TLTR.

Revelations. I suspect the chipset driver contains usb drivers. I've now updated the chipset driver, for another battery of tests. 1st observation: success coming out of hibernation, no USB problems. It seems to boot into "resuming" faster. Next step: replacing the MSAHCI native storage driver with the Intel. But only if this hasn't cured it.

 

[Ketchup]

You probably saw this question coming but I am going to ask it anyway - does the problem go away or change when you remove the overclock and step down memory timings a tad?

 

[BonzaiDuck]

You probably saw this question coming but I am going to ask it anyway - does the problem go away or change when you remove the overclock and step down memory timings a tad?

Been through that. It persisted when the 2600K was reset to its stock settings, and it persisted just as vigorously. Further, I understand the wisdom of your insinuation there, and over the past three years, I had other problems eventually resolved which also turned out not linked to the clocks, since I'd explored that possibility first of all each time. The most puzzling of those cases -- and my remembrance has it as either one of two or three which took the longest to sort out -- was due to the C3/C6 reporting options in BIOS being enabled. This board and/or the z68 chipset exhibited the problem for OC settings that enabling those features caused idle instability occurring infrequently (thus the problem of troubleshooting.) All that stuff has been solved now for about 2 years.

My thoughts about some "USB" glitch or the PSU exhibiting symptoms through USB glitches were possibly naïve. We'll only know over the next day or two. But updating the chipset . . . .well, let's test it again by trying to come out of hibernation: . . . . back in a jiffy . . . . Yeah -- so far that's "2 out of 2" successful returns from hibernate.

If it's not the chipset driver, then I can still try the Intel SATA drivers. I'd been using the MS native drivers for a long time. And updating the BIOS is still an option.

This might not be an interesting problem for folks, or it's a rare and obtuse problem (despite the web dialogs I'd found about it). But I'll keep checking back for insights from you-all, and report anything I discover.

I'm beginning to think that the PSU is good, the motherboard is good, the RAM certainly tests good, the processor has never been abused except for the clock speed. If it's a Windows installation problem, that's also on the table, but we're pursuing the easiest most obvious or likely causes first.

UPDATE UNTIL TOMORROW: 3 out of 3 successful returns from hibernate so far. Even with digital technology, I think I want to see a longer string of those before I declare this fixed.

 

[BonzaiDuck]

MOSTLY RESOLVED ON THIS, BUT I COULD COME BACK IF THERE'S THE SLIGHTEST HINT OF TROUBLE.

Haven't flashed the BIOS yet, and may not need to.

Reset the BIOS to default. Cleared the CMOS. Replaced the CMOS battery with a good fresh American-made unit. Replaced the 16GB RAM with an 8GB G.SKILL "GBRL" 1600 kit. [Moms doesn't need 16 GB, and the 1866-ers can be put to better use.]

The biggest problem I have is this F***stick Avocent KVM switch. Followed all advice about tweaking the USB power-management settings -- no cigar. But the final resting place for this Sandy won't have a KVM switch, and keyboard recognition is no problem without it. One computer is almost too much for Moms to handle.