Computer does not reliably enter Standby/S3 mode

[maxseven]

EDIT: For anyone surfing on this issue and arriving here, be advised I've decided simply that the ancient motherboard in this computer simply did not work reliably with my SSD and so I've abandoned the effort.
END EDIT
I'd love if someone here would help me out. This PC does not reliably go into S3 standby, such that while a WOL or keystroke will wake it, this means only that it powers-up but does not start the monitor nor show the keyboard LEDs resetting with Numlock ON as normal. I have to hit reset or power off/on and the I get a startup screen that says it didn't shut down cleanly and usually I Start Windows Normally and it boots fine. Later I do diskchecks and have never had any serious corruptions.

I tried S1 mode, where it seems to work reliably, and after setting BIOS to S3 again on Thursday afternoon it's worked fine i.e. go into Standby, wake automatically for backup to WHS2011 Server, sleep again, a couple of wake/sleeps yesterday by me, and this morning it awakened for Backup fine, and I awakened it from Standby after Backup fine, but then I put it to sleep with AFAIK the standard Windows API (via control gadget) and I got a bad start again about a half hour ago. This is a typical scenario, where it works some times but not (maddeningly) others, and I can't find the "why not".

What is most peculiar to me about these instances is that the System Log never records anything at the time it actually went into Standby--there are no status or error messages, e.g. this morning I had sent the PC into Standby at 09:11AM CST, and in the log is stated at 10:22AM when I woke it again that "The previous shutdown at 9:11:03 AM on 2/21/2015 was unexpected" but the last entry in the System log is at 8:58:32 AM!? Nothing after that at all, until I restarted some 10 minutes later. Also I almost *never* get a dmp file but this time I did, so....

My WhoCrashed says about the minidump only the following:

On Sat 2/21/2015 4:21:04 PM GMT your computer crashed
crash dump file: C:\Windows\Minidump\022115-16099-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x74EC0)
Bugcheck code: 0xD1 (0xFFFFF80403885DA0, 0x2, 0x8, 0xFFFFF80403885DA0)
Error: DRIVER_IRQL_NOT_LESS_OR_EQUAL
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.

I hope someone here will find some clues in the attachment to help me!

 

[Arc]

BugCheck D1, {fffff80403885da0, 2, 8, fffff80403885da0}

[COLOR=Red]Probably caused by : storport.sys[/COLOR] ( storport!RaidpAdapterTimerDpcRoutine+5b )

Followup: MachineOwner
---------

    Image name: storport.sys
[COLOR=Red]    Timestamp:        Tue Feb 04 07:06:50 2014[/COLOR] (52F04432)

Storport.sys is the generic storage port driver. It is not the actual cause of the BSOD, but it indicates about the storage controller elements of the chipset.

Your SATA/AHCI controller is the element of the nvidia nforce chipset. Which is too old.

    Image name: nvstor64.sys
    Timestamp:        Fri Apr 09 14:52:41 2010 (4BBEF1E1)

About nforce updates, what I see that nvidia is pretty out of the market of chipsets, nforce is almost obsolete nowadays. There is not a big scope of update to it.

Still, search for any possible Chipset/BIOS update for your MSI MS-7380. If you get any, apply it.

Please be aware that the BIOS update process is risky. If you dont have any prior experience with it, dont do it yourself. Take assistance of anybody who knows. (I am not aware of your skill levels. So please dont take this word otherwise.).

Let us know the situation.

 

[maxseven]

Thank you so much Arc for looking and commenting! Yes my BIOS for this now-ancient board is "latest" which means from 2011 iirc, and hopefully was done after W7 was released and tested as clearly no further BIOS will be made available for this old mobo.

I've been trying to eradicate from my system (i.e. drivers) anything non-Windows, which is not easy to do, and while I have tried in the past to replace the storage drivers with any/all chipset-appropriate versions I could find, I have not yet struck upon a fix for this maddening problem. I have even tried replacing the NVIDIA nForce Serial ATA Controller drivers with MS, to at least so far no good effect.

I did not myself ever see a storport.sys error so am glad you spotted it. I will continue to dig...

What troubles me about this board, an MSI P7N Platinum, is that in all the surfing I've done on this issue I can never find any specific posts about Standby problems with it, as if my own setup was somehow unique. I realize it is old enough that maybe there aren't all that many W7 x64 systems installed to it though. I do not want to just toss it, as in every other way this Q6600 machine works perfectly and I have a myriad of specialized programs on it that I don't want to rebuild (ie replace) it without good reason.

 

[Arc]

The only problem is nforce is out of the market.

IMHO you may try to use the storage drivers via windows update and not the nforce one, by starting it from the scratch.
http://www.sevenforums.com/tutorials/219487-clean-reinstall-factory-oem-windows-7-a.html

 

[maxseven]

The only problem is nforce is out of the market.

IMHO you may try to use the storage drivers via windows update and not the nforce one, by starting it from the scratch.
http://www.sevenforums.com/tutorials/219487-clean-reinstall-factory-oem-windows-7-a.html

Well I had done a recent Repair Install to assure all system files and have pared-back all non-MS and non-hardware related items so am going to continue down this track for now.

In any case that you found a pointer to the storage system is something I needed to regain my focus on this difficult problem.

 

[Arc]

Nothing very special ATM, just install the drivers via windows update only. Sometimes it is seen that those drivers are more stable than the drivers obtained from the device manufacturer.

Then we may wishfully expect that the BSODs will stop.

 

[maxseven]

...just install the drivers via windows update only.

I have to try this route because nothing else is working. Thanks for reading--I really needed another pair of eyes on this thing.

If it weren't for the fact that MSI sold a lot of these boards I'd give up on S3, but in fact it seems that since I installed an SSD as the C:\Windows drive that S3 has become way less reliable than before. Maybe that's a clue again re: the storage drivers.

When surfing on this problem weeks back I found a site where the P7N Platinum and the P7N Diamond were reviewed together and it was stated that MSI was doing something special (i.e. tricky) with the Platinum re: the chipsets but I've not been able to find that site again. Maybe I will try again as that may help further. Funny, last year I thought "Never Again" re: Nvidia, thinking my next mobo would be manufactured by Intel, and just as I did that Intel went out of the motherboard-making business!!!!

:bangshead:

 

[Arc]

Some SSDs are not for standby or hibernation.

Keep it away from the power configuration and see how it goes. I guess you know how to do it ..... http://www.sevenforums.com/tutorials/778-power-plan-settings-change.html ... point 5 (B) ... Hard disc > sleep time set to 0 or never.

If it works, then everything is alright.

 

[maxseven]

Some SSDs are not for standby or hibernation.

Ha, ha! Do I ever know it! I had an OCZ that bricked a few years ago, going into Standby. I got it replaced and put it into a different PC where it's been fine (with a new firmware too). This Kingston has Sandforce also and (knocking on wood) has done well with all my shenanigans. But yes I know about Sleep Never!

Well I don't know if my Standby problem is solved yet, but after using DevMgr to do an "Update Driver" with the NVIDIA, and selecting MS' "Standard Dual Channel PCI IDE Controller" instead (it worked), I found there were two instances of the nvstor driver still in the system. nvstor.sys and nvstor64.sys were hidden in the Non-Plug and Play Drivers area and man it was tricky to get rid of them. I had to select the driver and change from Boot to Disabled and then Reboot and then go-back and Uninstall them and Reboot again and finally Delete them from system32\drivers. Until I did it in this fashion, Windows considered them essential files and refused to boot until it "repaired" the problem i.e. replaced these files. What a trip...

What I learned along this journey was that NVIDIA CONTROLLER DRIVERS DON'T ALLOW TRIM! So a side benefit (a big one AFAI'm concerned) to switching to the MS drivers is TRIM.

I will report back if it solves my S3 woes or if I am forced to S1...

 

[Arc]

....... I found there were two instances of the nvstor driver still in the system. nvstor.sys and nvstor64.sys were hidden......

Please let me see the changed situation? Upload your MSINFO32.nfo file.

1. Click on the start button
2. Type "msinfo32" (without quotes) in the search bar of the start menu, click the resulting link. It will open the System Information window.
3. File>Save. In the "File Name" filed, put "MSINFO32" (without Quote), give the save location to desktop, and click the "save" button.
4. Give the time for processing, it will save a .nfo file on your desktop.
5. Zip it, and upload it following the instruction.

 

[maxseven]

....... I found there were two instances of the nvstor driver still in the system. nvstor.sys and nvstor64.sys were hidden......

Please let me see the changed situation? Upload your MSINFO32.nfo file.

Certainly Arc. Thanks for your interest.

You will note the nvstor items are gone (I believe). I did have a good complete cycle since yesterday (Standby, wake for WHS2011 Backup then Standby again, wake for this session A-OK) and while it's encouraging thus far, I have sometimes gone several days before the "fails into Standby" problem appears again. So it's a bit early to declare success.

 

[Arc]

Yes, nvstor is gone for good! Very well done!! IDE mode controller is very properly installed.

Now let us wait and see how it goes with pciide.

 

[maxseven]

Bah, I had another bad Standby. Upon resume the HDD LED was lit for some 10 seconds then went out, and as before I got no video nor did the keyboard/mouse wake. Nothing in the logs to indicate a good Standby, and no Minidump file despite that on restart Windows knew it hadn't shut-down properly.

I will run a diskcheck now but I'm beginning to think this motherboard has a hardware problem (though I did run Memtest86+ successfully for many passes the other day). Can't imagine why it doesn't go into Standby reliably.



I am going to disable the last few non-MS drivers via the trick above but I have a very low level of confidence at this point that this will help anything. If you have any more ideas for me Arc...

 

[Arc]

Have you tried excluding the HDD from power plan settings?

 

[maxseven]

Have you tried excluding the HDD from power plan settings?

I am not sure what you mean by this but I do certainly have "Turn HDD Off" set to Never. This PC has an SSD/SATA) as the system drive, then two PATA drives, another PATA DVD drive, a couple of SATA BD drives I've disconnected during this process, and finally two eSATA ports that I'd ignored too to this point.

But yesterday I made some changes and again had a "successful cycle" of Sleep last evening, auto-wake for WHS2011 backup this morning, auto-Standby after that, and now I've just started-up again successfully from Sleep. The changes:

1. Disabled the last of the non-MS drivers for a couple things like VirtualBox and truecrypt
2. Did an Update on the NVIDIA System Management driver and it automagically installed an MS one 6.1.7601.17514
3. Uninstalled a greyed-out duplicate UMBus Enumerator which has appeared in the past & I dunno what this is about
4. Updated my NVIDIA Graphics Driver to latest 341.44 supposedly has security fixes
5. Did a DriveCleanup using Uwe Sieber's tool
6. Clicked on Windows Update and it offered me a driver I don't think I've ever seen before, another nvstor64.sys to replace the Standard driver I'd tried yesterday. Says NVIDIA nForce Sata Performance Driver v5.10.2600.998 dated 8/9/2007 but this is an ancient board so what the heck I installed it. I've tried every other bloody driver I could find, why not...
7. I had previously uninstalled the JMicron driver for the JMB363 chip this mobo uses for eSATA, and I installed it again since it seems the standard drivers didn't work with that chip. I had to change the eSATA's BIOS from IDE to AHCI for this (no I don't use RAID which is a key feature of this chip, but I do have a Mediasonic eSATA Probox with 4 drives and now all are seen individually again).

I know, this was way too many changes to make at one time but believe me, over the months I've worked on this problem now (yes months) I've tried most everything twice...!

If this doesn't work I think I must accept defeat and I will uninstall the WHS2011 Connector software, the prime benefit of which is to automatically BU the PC every day on schedule. Then I will not bother to use S3 or even S1 and instead just turn the PC off every day.

 

[Arc]

I am not sure what you mean by this but I do certainly have "Turn HDD Off" set to Never.

Yes, that is what I wanted to make sure.

 

[maxseven]

I should mention one more thing: In looking at my drivers and finding/surfing on the three dump_dump ones that apparently are Windows-related, I tried to make them go-away by turning-off "Write debugging information" in System CP advanced settings. I have only VERY RARELY gotten minidumps from these failure-to-Standby incidents, so I am left to wonder why. In any case since I don't get them very often anyway (last one is in the dm log collection in my 1st post) I will leave that turned-off for now.These things remain though, not having gone-away at all as I expected:

Driver Name Load Count File Type
dump_diskdump.sys 2 Unknown
dump_dumpfve.sys 1 Unknown
dump_nvstor64.sys 1 Unknown

And despite that Nirsoft DriverView shows them, I can find no actual files that are named as such. Puzzling as to how they're generated and why DriverView picks them up but nothing else seems to know about them.

 

[Arc]

dump_diskdump.sys and the other two are of same use, they are the drivers created to provide disk access during crash dump file generation. You need not to be concerned about them. Let them remain there.

What appears to me that you have an ongoing issue with power configuration. Sometimes it causes BSODs as well.

As far as it is a BSOD, I am the right person to assist you. But for the base power configuration issue, I am not the right person, as no other member active in the BSOD threads.

It would be the best for you that you start a new thread in the General Discussions about the power config issue. There are people like Brink and some others who are gods for those issues.
You may give a link of this thread there, as a reference.

If it BSODs again at any point of time, post here.

 

[maxseven]

OK Arc I've appreciated your input here. I do believe you were correct from the beginning to suspect the storage drivers so thanks anyway for giving me some focus.

I had forgotten already that the NVIDIA drivers don't TRIM, so reverted again to the MS Standard Dual Channel PCI IDE Controller drivers so that TRIM again works.

It does seem like my Standby woes started with the installation of the SSD last year, and my best guess at this point is that this motherboard is too old to work gracefully with modern controllers for it (no AHCI for example). So I either revert to a spinner and Sleep again, or stay with the SSD and Shut-Down instead...

 

[Arc]

OK Arc I've appreciated your input here. I do believe you were correct from the beginning to suspect the storage drivers so thanks anyway for giving me some focus.

I had forgotten already that the NVIDIA drivers don't TRIM, so reverted again to the MS Standard Dual Channel PCI IDE Controller drivers so that TRIM again works.

It does seem like my Standby woes started with the installation of the SSD last year, and my best guess at this point is that this motherboard is too old to work gracefully with modern controllers for it (no AHCI for example). So I either revert to a spinner and Sleep again, or stay with the SSD and Shut-Down instead...

The two alternatives that you have decided are all inclusive. Yes, it is somehow true that there is always a possibility of non-compatibility between old (technically old) and new (technically new) hardware components. It is also a very widely noticed scenario that a good lot of SSDs are not for the sleep configurations, in whichever machine they are attached to.

If the SSD is not configured to go to sleep, then the unsuccessful sleep-wakeup power transitions might not be due to the disc only. Some other PnP devices also needed to be watched thoroughly. That is why I referred you to some expert of that very field.

One very common way to determine which driver is causing an issue is to enable driver verifier. If you are interested, you may use it, just to be sure that if it is anything else other than the disc that is playing in there.

enable Driver Verifier to monitor the drivers.

Driver Verifier - Enable and Disable
​

Run Driver Verifier for 24 hours or the occurrence of the next crash, whichever is earlier.

   Information

Why Driver Verifier:
It puts a stress on the drivers, ans so it makes the unstable drivers crash. Hopefully the driver that crashes is recorded in the memory dump.

How Can we know that DV is enabled:
It will make the system bit of slow, laggy.

   Warning

Before enabling DV, make it sure that you have earlier System restore points made in your computer. You can check it easily by using CCleaner looking at Tools > System Restore.

If there is no points, make a System Restore Point manually before enabling DV.

   Tip

• If you fail to get on the Desktop because of DV, Boot into Advanced Boot Options > Safe mode. Disable DV there. Now boot normally again, and try following the instruction of enabling DV again.
• If you cannot boot in Safe mode too, do a System Restore to a point you made earlier.

Let us know the results, with the subsequent crash dumps, if any.

When DV is enabled, put the computer to sleep and wake it up. That means, force it to BSOD. If anything other than the storage drivers are playing any role there, DV will be able to discover those.