Random BSOD on new custom builds

[Boozad]

I don't think it's the PSU. Is there any particular reason you're setting desktops to sleep?

 

[Alan White]

Money . Until a couple of years ago we used to leave all the PCs on 24/7 then we discovered they were using 8kWh/day so we started putting them into standby or hibernation. Our electricity bills are much lower now.

 

[Boozad]

Yeah I thougth as much. I'm still pretty convinced it's to do with AOEMI backup Alan, could you uninstall that on PC #1 just for a day or two to test?

 

[Alan White]

Hi, Boozad.

I've uninstalled AOMEI Backupper as suggested, and checked that it removed its service and driver as well as the program. I can see why you suspect it and all the BSODs do have the appearance of a fault in the IO chain. Let's see how that goes now...

A few hours before I did that I had a "... has stopped working" message. This time it was igfxTray.exe but the faulting application varies and this message is usually the precursor to a crash. Sure enough, the event log reported a few event 55 and a chkntfs c: caused a BSOD. Chkdsk found no problems. I've attached an extract from the event log in case you can see anything useful.

Thanks again for your help.

 

[Alan White]

Hi, Boozad.

Less than 24 hours after uninstalling AOMEI Backupper I've had another BSOD, as usual on waking from sleep.

I believe that rules out AOMEI Backupper. I'm grateful for other suggestions.

 

[Boozad]

OK well at least that's ruled that out. Can you upload your latest logs please Alan.

 

[Alan White]

Attached.

I don't know about you but I'm running out of ideas and thinking that perhaps something more drastic is required, such as starting from scratch and installing programs and updates much more slowly until a crash occurs. It will take weeks if not months but may be the only way, especially as I really need to narrow it down to hardward or software so I can get the supplier to exchange if it's hardware.

I see from the event logs that the first crash occurred on 7 Sep on PC#1 and 9 Sep on PC#2 (Windows having been installed on 30 Aug). I can see what programs and updates were installed up until then so that may give us a clue. I'll do some more digging.

Always open to suggestions...

 

[Boozad]

Alan, a couple of tests to run just to discount your hard drives. I don't think it's them but at least it's another thing definitely ruled out, and I can't see this being any other hardware. Considering it's happening during sleep it would be just too coincidental.

http://www.sevenforums.com/tutorials/433-disk-check.html
http://www.sevenforums.com/tutorials/313457-seatools-dos-windows-how-use.html

I'll ask another couple of bods to drop in and take a look to see if I'm missing anything too.

 

[essenbe]

Alan, I'd like you to keep a close watch on the CPU temps. Your GPU temps should be about the same is you're using on board graphics. Pleas go into BIOS and give me the CPU temp reading, the Motherboard reading, the Value of the +12V, +5V and +3.3 V. Next look at your sata controller and see what mode it is in (IDE,AHCI or Raid) Then make sure your ram is set to manufacturer's timings, Frequency and Voltage. and see how it is set. Then set everything to optimized defaults. Set your Sata controller to what it is right now, set your Ram to Manufacturer's specs, especially the frequency, timings and Dram Voltage, set your boot order, save and exit.

If you continue to have problems, please download, if you don't already have it, CPU-Z CPUID - System & hardware benchmark, monitoring, reporting And post screenshots of the CPU, Mainboard, Memory and SPD tabs. On the SPD tabs you can select each tab from a dropdown list at the top left, We only need the tabs that are populated with ram. http://www.sevenforums.com/tutorials/9733-screenshots-files-upload-post-seven-forums.html .

I haven't read the entire thread, but the last one I looked at said Memory Management. Memtest86+ isn't 100% accurate, but it is the best test we have. There is another test called memtest86 (Yea, I know) but it is quite similar but, in my opinion and most others, inferior to memtest86+. Are you sure you ran the correct test? If you had a dedicated graphics card, I could say the Memory is about the graphics card, but you don't.

Please, open a elevated command prompt ( click start, type cmd in the search box, right click on the cmd entry and select run as administrator) in the black box that opens, copy/paste sfc /scannow. If you decide to type it, notice the space between the sfc and the /. It is a system file checker which will scan your system files and attempt to correct any missing or corrupt files. What we want are the results to say windows found no integrity violations. If it says files were found but could not be repaired, close the box, reboot and run it again, after opening the administrative command prompt. You may have to reboot and run it three times for it to repair all system files. If it can't repair them after 3 reboots, let us know.

After setting your BIOS to defaults and making the above adjustments, please look at your C state settings, they are usually under CPU Management on Asus boards but I am not familiar with Gigabyte.

I would also look up your PSU and make sure it says it is 'Haswell Ready', Most are but some are not. Haswell goes into such a low power state that some PSU's think they are off and will cause a BSOD. Haswell has a much lower power state than any previous CPU.

 

[Alan White]

Thanks, Boozad,

You may recall we ran chkdsk and SeaTools further up the thread. I've also run WD diagnostics. I've run long tests using both SeaTools and WD diags without error. I've just run chkdsk c: /f five times in quick succession and every time I get
Windows has checked the file system and found no problems.

However, I also get
Cleaning up 15 unused index entries from index $SDH of file 0x9.
Cleaning up 15 unused security descriptors.
then the next time
Cleaning up 2 unused index entries from index $SDH of file 0x9.
Cleaning up 2 unused security descriptors.
then
Cleaning up 1 unused index entries from index $SDH of file 0x9.
Cleaning up 1 unused security descriptors.
then
Cleaning up 1 unused index entries from index $SDH of file 0x9.
Cleaning up 1 unused security descriptors
then
Cleaning up 3 unused index entries from index $SDH of file 0x9.
Cleaning up 3 unused security descriptors.

Previous runs of chkdsk show the same pattern. These messages aren't shown on the console while chkdsk is running: they appear only in the event log, which is why I've not noticed them before.

So it seems that no matter how many times I run chkdsk it says it found no problems but always has to clean something up. Some googling suggests that this is a long-standing but harmless bug in NTFS.

I've just run WD diagnostics (quick test only) with no problems reported.



Hi, essenbe. Thanks for dropping in - all help appreciated. Love the sig!

I can't see anywhere that gives GPU temp.

CPU temp reading = 37°C after about two hours up
the Motherboard reading = I can't see a motherboard temp? system = 27°C
the Value of the +12V, +5V and +3.3 V = 12.168, 5.01, 3.284

Next look at your sata controller and see what mode it is in (IDE,AHCI or Raid) = AHCI

Then make sure your ram is set to manufacturer's timings, Frequency and Voltage. and see how it is set.
I don't pretend to understand all the numbers but they look OK to me. No doubt the CPU-Z info below will confirm.

Then set everything to optimized defaults. - Done

Set your Sata controller to what it is right now, set your Ram to Manufacturer's specs, especially the frequency, timings and Dram Voltage, set your boot order, save and exit.
Optimized defaults kept all these as above

View attachment 338962

View attachment 338963

View attachment 338964

View attachment 338965

View attachment 338966

Is it correct that slots 1 & 3 are used (there are only two slots on this motherboard) and that the frequency is shown as 800 rather than 1600?

Definitely Memtest86+ as per method 2 at http://www.sevenforums.com/tutorials/105647-ram-test-memtest86.html

I run sfc /scannow on a schedule a couple of times a wek, just to keep an eye on things. Mostly it returns "no integrity violations". Very occasionally it will return something else but after a reboot has always returned "no integrity violations". I've just run it now and it says:
Windows Resource Protection did not find any integrity violations.

The only references I can find in the BIOS to C state are "C3 State Support" and "C6/C7 State Support". Both are set to Auto, with other options of Disabled and Enabled.

PSU is FSP Raider 550W Quiet PSU, 80+ Bronze FSP Raider Series PSUs says "Intel 4th Gen (Haswell) compatible". RAIDER 550 | RAIDER Series | Power Supply | FSPLifeStyle says "100% Compatible with Haswell CPUs.".

Appreciate the help, guys.

 

[essenbe]

The only suggestion I would make at this point is change Command rate in your ram timings from 1T to 2T. 2T is what is called for in your SPD JEDC specs for those timings and is more stable than 1T.

The 800MHz is correct. Remember you are running DDR3, which stands for Double Data Rate so 800 X 2 = 1600MHz

You should also see if there are any updated drivers on your Motherboard's web site http://www.gigabyte.com/products/product-page.aspx?pid=4965#driver

 

[Alan White]

Thanks, essenbe.

Assuming that's tCMD in the advanced memory timings in the BIOS then I've just set it to 2 on both channels. Let's see how that goes...

All the drivers are up to date, I believe. Some of the Intel ones are from Intel's own site as Gigabyte seems a little slow to update.

 

[essenbe]

They are all slow to update unless you have the latest chipset. And some are slow even then.

 

[Alan White]

Hi, essenbe.

You may have read that I have two theoretically identical PCs both exhibiting the same problem.

I made the command rate change you suggested on PC#1 yesterday and I see that CPU-Z now reports 2T on the Memory tab. It's too early to say whether that's fixed the problem on PC#1 so to speed up testing I applied the same change to PC#2.

PC#2's BIOS reports 2T but CPU-Z continues to show 1T and nothing I've tried will get it to say any different.

So has the change taken effect on PC#2? Or is CPU-Z not reporting correctly?

 

[essenbe]

I would be inclined ti think it hasn't changed or that your BIOS is Not reporting correctly.

 

[essenbe]

Alan, My motherboard is an Asus, but we had a bad bios bug in the code at one point where the same thing would happen. We could change bios, but it would not transfer to the OS. After a lot of complaints, they finally were able to reproduce it and came out with an new BIOS file which fixed it. I'm just curious if your board may have the same thing. I would try to update my bios if there is a newer one, as long as you think the computer is stable enough to update it. If you get a BSOD during the update, it will take an RMA for a new bios chip to fix it. During the problem I had, I could update the bios with the same version I had and it would work fine until I saved everything and went back into the OS, then it was the same thing. But, CPUz is pretty much the standard everyone goes by to find their settings. I don't know of anything more accurate. I usually accept whatever CPUz says over anything else. Most in the Overclocking community do.

 

[Alan White]

I've got it to take the 2T setting on PC#2 now - CPU-Z correctly reports it. The trick seems to have been a cold reboot: disconnect power, wait five minutes, boot, set BIOS, all OK. Perhaps when doing PC#1 I turned off the power for some other reason which is why it worked first time there.

Thanks for your continuing help. Now back to waiting...

 

[essenbe]

That's pretty strange. I have an Asus board and sometimes it works the same way, a reboot won't take it. I have to completely shut down and it takes a cold boot to load things. Crazy isn't it.

 

[Alan White]

Three weeks further on I thought it time to post an update...

The 2T command rate change unfortunately had no effect on the stability: both machines would still randomly crash on entering or during sleep.

As you know, I've long thought this is a problem related to sleep so I started using hibernation rather than sleep. Since then both machines have been perfectly stable.

This says to me that the hardware doesn't properly support sleep. As an experiment I disabled C6/C7 State Support and went back to using sleep but within a couple of days there was a BSOD.

So I'm now using just hibernation and all is well. Of course, this is a workround not a solution and even though these machines wake quickly from hibernation it would be good to have the even quicker benefit of sleep. If there are any other ideas I'd really appreciate them.

 

[essenbe]

Alan, do you have the latest BIOS version for your board? At default settings, is C6/C7 enabled or Disabled? This has been a problem since Haswell and actually since Sandy Bridge was released. Haswell just added more C states. Your PSU says it is Haswell compliant which means it should work. With most boards, the problem seems to be that the CPU will wake up, but some of the drivers do not.