• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Machine randomly shutting off

K

Kainzo

Gawd
Joined
Nov 12, 2009
Messages
972
Greetings!

I'm a pretty avid builder but I'm a bit stumped with this issue. The machine will, at random, shut off completely (including lights) and then come back on, during normal activities and gameplay.

The temps do not appear to be reaching astronomic levels, maxing out at around 60-65c (cpu) and 45c for the GPU.

Parts:
cpu - i7 3960x (turbo enabled normal at 3.3, w/ turbo at 3.9ghz)
mobo - MSI X79A-GD45 /// Intel DX79SI (have tried both, it still happens with either, MSI is a new board.
psu - 750 Antec Gold High Current Pro
gpu - MSI Lightning 680 (no OC)
sdd - samsung 840 pro
hdd - Black 1TB
case - HAF 942-x
cooler - x40 kraken
ram - G.SKILL Ripjaws Z Series 32GB (DDR1600)

Here's what I tried
1. Bought a new motherboard (MSI $260) to see if the issue would go away. - Failed.
2. Was able to reproduce the issue VERY quickly when using the OC Genie2 on the MSI board, with teh button pressed, I could boot up OCCT and have it reproduce the issue with the power-off in around 2 minutes of the test. - Failed
3. Attempted PSU and GPU stress test with stock BIOS, tests ran 1 hr+ each with no issues. Shut down my machine and restarted it this morning and the issue came back within 5 minutes of use just sitting at the Windows Desktop. - Failed.
4. Turned the 32 GB of ram to 1600 and enabled XMP, crashed after 3-5 days.
5. Attempting to test each DIMM individually.
6. Issue happened again after about two weeks of not happening.
7. Issue still happening

I've run OCCT for an hour with the "stock" bios and it didn't crash for an entire hour. I've also attempted to use the "OC genie2" overclock function and that triggered a crash within 2 minutes of the run.
Can anyone give me some more things to try? I'm thinking its possible it could be the PSU, but after running OCCT PSU test for 30+ minutes it had no issues.

Update: just found that windows was noticing there was an error and created logs - I was unable to send them to windows but I have a rar with them so maybe someone can make sense out of it.
http://www.mediafire.com/download/juwuzck8wpq6j0r/issues.rar
UpdatE: Cross posted here https://social.technet.microsoft.co...-off-and-then-comes-back-on?forum=w7itproperf
 
Last edited:
When you say "come back on during normal activities and gameplay" do you mean that it comes back on to where you left off or completely reboots? Have you tried safe mode or another OS (Linux live distro)?
 
JGAN said:
When you say "come back on during normal activities and gameplay" do you mean that it comes back on to where you left off or completely reboots? Have you tried safe mode or another OS (Linux live distro)?
Click to expand...

It restarts to Windows 7. So i lose all progress, etc.

I have not tried any other OS yet... but this was with a fresh install of windows and nothing in the windows error other than "unexpected power loss"
 
Here's what I tried
1. Bought a new motherboard (MSI $260) to see if the issue would go away. - Failed.
2. Was able to reproduce the issue VERY quickly when using the OC Genie2 on the MSI board, with teh button pressed, I could boot up OCCT and have it reproduce the issue with the power-off in around 2 minutes of the test. - Failed
3. Attempted PSU and GPU stress test with stock BIOS, tests ran 1 hr+ each with no issues. Shut down my machine and restarted it this morning and the issue came back within 5 minutes of use just sitting at the Windows Desktop. - Failed.
4. Turned the 32 GB of ram to 1600 and enabled XMP - awaiting a crash.
 
I was going through this recently. One of your sticks of RAM is bad, most likely.

Download Memtest86+, and test each module in each slot (so 16 runs for 4 modules). One (or more) will probably error out.
 
Yeah... it hasnt happened in 3 days so far... what im going to do is test the ram, first. Its just been hard with work and all!

Thanks for the responses and ill post back.... My last change was.. setting the ram manually to 1600 and enabling the XMP profile.
 
Alright - I just had a reboot/power off again, going to run memtest 86 now.
 
This may be a minority opinion but I never had good luck with memtest!

If it passes run the system with one stick of RAM at a time. But before that - get a LINUX Live CD - boot off of that and check for stability. You may get some errors right away just trying to boot up!

This is a good one:

http://www.stresslinux.org/sl/ - memory test is an option.
 
I'm getting to the root of the issue, I believe.

I'm running memtest86+ i've tested two sticks of ram so far. When I run the "stable" test (one core), each DIMM managed to get past 2-5 hrs of testing with zero errors and several passes.

Just to see, I decided to enable "f2" which enables all cpu cores to test the ram at a much faster rate. Within 5-10 minutes of the tests, the machine crashed/reset like it would during normal play.

Please note that this is "Stock" / default settings of the mobo save for XMP being enabled (as a requirement of the ram and I've spoken to many, also tested with/without and no change in the tests)

I could probably disable turbo mode, but I believe the issue is the CPU. Thoughts?
 
Kainzo said:
I'm getting to the root of the issue, I believe.

I'm running memtest86+ i've tested two sticks of ram so far. When I run the "stable" test (one core), each DIMM managed to get past 2-5 hrs of testing with zero errors and several passes.

Just to see, I decided to enable "f2" which enables all cpu cores to test the ram at a much faster rate. Within 5-10 minutes of the tests, the machine crashed/reset like it would during normal play.

Please note that this is "Stock" / default settings of the mobo save for XMP being enabled (as a requirement of the ram and I've spoken to many, also tested with/without and no change in the tests)

I could probably disable turbo mode, but I believe the issue is the CPU. Thoughts?
Click to expand...

Like I said I personally have never had good success with memtest. I just use a different stick of ram known to be good. Memtest has never helped me solve a problem. see this:

http://forum.canardpc.com/threads/8...n-w-forced-multithread-around-start-of-test-7 - there's also a link to the same problem.

A bad cpu unlikely unless you have a bent pin. Can you use one memory stick at a time to test?
 
I've tested each DIMM and all of them passed between 3-5 tests (8+ hours each).

The only time issues would arise in the tests is when I used the "force multi-core" - the machine would shut down after 5-10 minutes of testing (no errors)

So I'm beginning to think its not the ram.
 
Kainzo said:
I've tested each DIMM and all of them passed between 3-5 tests (8+ hours each).

The only time issues would arise in the tests is when I used the "force multi-core" - the machine would shut down after 5-10 minutes of testing (no errors)

So I'm beginning to think its not the ram.
Click to expand...

I may have missed it - but did you try a different PSU? Stress testing the PSU alone won't cut it. If you have not tried another PSU get one ASAP. Always good to have a spare anyway just in case! Better yet - can you borrow a PSU that is known to work? Old is OK.
 
I'm going to borrow my GF's psu, she has almost the same setup as I do. 750 watt psu, i7 980x and a 680 MSI lightning.

I'll be throwing hers in to test things.

This has been a massive headache and I wish I didnt own this computer. I ran the memtest86+ on her machine with her 24GB of patriot sector 7 ram and it is doing the multicore test for 20+ minutes no crashes.
 
Tested out Gf's PSU, Memtest86+ failed on Test #7 as it did with the multi-core support enabled, it passed with the "failsafe" f1 test on Test #7.

Unsure what else it could be unless its the CPU that's bad.
 
I tried different ram, the same thing happened with memtest86+. I'm beginning to think its either the CPU or Memtest's multicore test (though it worked fine her machine)

Note that the "compatibility" for this ram (and her ram) doesnt show up under either of my boards' compatible ram list.
 
And another crash with no rhyme or reason, so frustrating... Thinking it may be the CPU has something misfiring, temps are fine, ran a stress test for 3+ hours with temps not going over 70c and all cores at 100%.
 
Kainzo said:
It happened again when I was gaming, temps were normal.

Update: just found that windows was noticing there was an error and created logs - I was unable to send them to windows but I have a rar with them so maybe someone can make sense out of it.
http://www.mediafire.com/download/juwuzck8wpq6j0r/issues.rar
Click to expand...

I can't open that on the PC I'm on right now. I'd only open the rar in a virtual machine, no offense.

Did you try a Linux live CD? Linux is much less tolerant of hardware issues. If something is bad with the hardware it may catch it right away! I urge you to try that.
 
Just restarted yet again, probably 3 times today - no setting changes nothing. I haven't clue why this is happening now, haha.
 
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffffa802224f9e0, The pool entry we were looking for within the page.
Arg3: fffffa802224fa50, The next pool entry.
Arg4: 0000000004070006, (reserved)

Debugging Details:
------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: GetPointerFromAddress: unable to read from fffff800036ca100
GetUlongFromAddress: unable to read from fffff800036ca1c0
fffffa802224f9e0 Nonpaged pool

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: chrome.exe

++++++++++++++++++===============================++++++++++++++++++++++==========4

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

VIDEO_TDR_TIMEOUT_DETECTED (117)
The display driver failed to respond in timely fashion.
(This code can never be used for real bugcheck).
Arguments:
Arg1: fffffa80262bc4e0, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
Arg2: fffff8800fa2be20, The pointer into responsible device driver module (e.g owner tag).
Arg3: 0000000000000000, The secondary driver specific bucketing key.
Arg4: 0000000000000000, Optional internal context dependent data.

Debugging Details:
------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

FAULTING_IP:
nvlddmkm+153e20
fffff880`0fa2be20 ?? ???
 
You must log in or register to reply here.
Back
Top