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.
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.
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...
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.
Yes, that is what I wanted to make sure.I am not sure what you mean by this but I do certainly have "Turn HDD Off" set to Never.
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.
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.
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...
Last edited by maxseven; 26 Feb 2015 at 15:52.
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.
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.enable Driver Verifier to monitor the drivers. Run Driver Verifier for 24 hours or the occurrence of the next crash, whichever is earlier.
InformationWhy 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.
WarningBefore 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.
Let us know the results, with the subsequent crash dumps, if any.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.
Quote