BSOD playing Battlefield 3, Star Trek Online after adding bluray burne

All 4 crashdumps are WHEA errors reported by your CPU. Two of them state a data write error in your L2 cache of your CPU, while the other two state an issue with the internal timer of your CPU. You had the Intel Linpack benchmark running for three of them at the time, so I assume this was during stress testing while you were checking out your OCing.

There's a couple things I've seen that would cause what appears to be CPU failure displayed by these WHEA error records. First off, if you're using any utilities or software that came with your motherboard, please uninstall them. All OCing should be done straight from the motherboard. Software-based OCing is not preferred, and often the software that runs them is riddled with bugs that actually make WHEA think that the CPU is failing. The other motherboard software I've seen do the same thing in order to perform some gimmick. It's recommended to remove em all. If you wish to OC, you should resort only to doing so with the BIOS.

If none of that seems to resolve the issue, than run MemtestCL for a few passes. I've actually seen graphics cards cause these WHEA errors before (rare, but it happens). You may also run Prime95 on Torture Test at Large FFTs overnight if you wish to test your CPU specifically.

In addition, you'll want to provide us some voltage/temp logs with HwInfo. When it starts, check Sensors only, then record two logs: one during idle and one during high load. For idle have it run 30 minutes. For high load, it'd be preferable if you have it run until the system crashes. Otherwise, have it run for 45 minutes to an hour. Send both logs to us.

Lastly, I'd like to add that it is possible that the CPU has been stressed to the point of no return with your OCing, causing these errors to now start manifesting themselves even when you reset things to factory defaults. Of course, our endeavor is to test and make sure that's not the case rather than fruitlessly spend money and/or time getting a replacement CPU, but there is always the chance that it's simply dead now. It is possible to OC a CPU and keep it stable during high loads, but it's also well capable that OCing would reduce the lifespan of your CPU in the meantime.

ALL attached dumps are x124 hardware bugchecks, so something is going on here regarding your hardware most likely, especially since you've gone ahead reformatted multiple times.

General troubleshooting for this bugcheck, thanks to H2S04.

1) Ensure that none of the hardware components are overclocked. Hardware that is driven beyond its design specifications - by overclocking - can malfunction in unpredictable ways.

2) Ensure that the machine is adequately cooled. If there is any doubt, open up the side of the PC case (be mindful of any relevant warranty conditions!) and point a mains fan squarely at the motherboard. That will rule out most (lack of) cooling issues.

3) Update all hardware-related drivers: video, sound, RAID (if any), NIC... anything that interacts with a piece of hardware. It is good practice to run the latest drivers anyway.

4) Update the motherboard BIOS according to the manufacturer's instructions. Their website should provide detailed instructions as to the brand and model-specific procedure.

5) Rarely, bugs in the OS may cause "false positive" 0x124 events where the hardware wasn't complaining but Windows thought otherwise (because of the bug). At the time of writing, Windows 7 is not known to suffer from any such defects, but it is nevertheless important to always keep Windows itself updated.

6) Attempt to (stress) test those hardware components which can be put through their paces artificially. The most obvious examples are the RAM and HDD(s). For the RAM, use the in-built memory diagnostics (run MDSCHED) or the 3rd-party memtest86 utility to run many hours worth of testing. For hard drives, check whether CHKDSK /R finds any problems on the drive(s), notably "bad sectors". Unreliable RAM, in particular, is deadly as far as software is concerned, and anything other than a 100% clear memory test result is cause for concern. Unfortunately, even a 100% clear result from the diagnostics utilities does not guarantee that the RAM is free from defects - only that none were encountered during the test passes.

7) As the last of the non-invasive troubleshooting steps, perform a "vanilla" reinstallation of Windows: just the OS itself without any additional applications, games, utilities, updates, or new drivers - NOTHING AT ALL that is not sourced from the Windows 7 disc. Should that fail to mitigate the 0x124 problem, jump to the next steps. Otherwise, if you run the "vanilla" installation long enough to convince yourself that not a single 0x124 crash has occurred, start installing updates and applications slowly, always pausing between successive additions long enough to get a feel for whether the machine is still free from 0x124 crashes. Should the crashing resume, obviously the very last software addition(s) may be somehow linked to the root cause.

If stop 0x124 errors persist despite the steps above, and the harware is under warranty, consider returning it and requesting a replacement which does not suffer periodic MCE events. Be aware that attempting the subsequent harware troubleshooting steps may, in some cases, void your warranty:8) Clean and carefully remove any dust from the inside of the machine. Reseat all connectors and memory modules. Use a can of compressed air to clean out the RAM DIMM sockets as much as possible.

9) If all else fails, start removing items of hardware one-by-one in the hope that the culprit is something non-essential which can be removed. Obviously, this type of testing is a lot easier if you've got access to equivalent components in order to perform swaps.

With this being said, I'd recommend first and foremost testing your memory, I don't see any mention of doing so in the OP, so:

Read the following to test your memory for errors.

Drivers that need to be updated:

SaiH0460.sys - Mon Nov 24 05:14:27 2008 (not listed in the carona drivers list, most likely related to Saitek as other drivers minus the "H" in SaiH are labeled Saitek. Possibly a driver for the hub on the keyboard if there is one?" Update here.

For now... and please, read before typing and jumping to conclusions. Bring every component on your system that is overclocked to stop temporarily for diagnostic purposes. With all do respect, I don't care if you believe your Overclock is stable, I don't care if ran Prime95 for 400 hours and got no crashes, an overclock can & will do unthinkable thinks to a system when unstable. So, with that being said, for testing purposes allowing us to help you better, please just bring everything to stock for NOW. When your issue is solved, you're MORE THAN WELCOME to put everything back to what it once was :)

Vir Gnarus said:

All 4 crashdumps are WHEA errors reported by your CPU. Two of them state a data write error in your L2 cache of your CPU, while the other two state an issue with the internal timer of your CPU. You had the Intel Linpack benchmark running for three of them at the time, so I assume this was during stress testing while you were checking out your OCing.

There's a couple things I've seen that would cause what appears to be CPU failure displayed by these WHEA error records. First off, if you're using any utilities or software that came with your motherboard, please uninstall them. All OCing should be done straight from the motherboard. Software-based OCing is not preferred, and often the software that runs them is riddled with bugs that actually make WHEA think that the CPU is failing. The other motherboard software I've seen do the same thing in order to perform some gimmick. It's recommended to remove em all. If you wish to OC, you should resort only to doing so with the BIOS.

Very good call, my friend! After checking OP's drivers list, he does in fact have the Asus PCProbe Utility installed.


Dump for reference:

Code:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Icarus\Downloads\Windows_NT6_BSOD_jcgriff2\020612-19656-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`0301e000 PsLoadedModuleList = 0xfffff800`03263670
Debug session time: Mon Feb  6 03:43:17.944 2012 (UTC - 4:00)
System Uptime: 0 days 0:18:30.866
Loading Kernel Symbols
...............................................................
................................................................
.....................................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 124, {0, fffffa8007349028, be000000, 800400}

Probably caused by : hardware

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

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa8007349028, Address of the WHEA_ERROR_RECORD structure.
Arg3: 00000000be000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000800400, Low order 32-bits of the MCi_STATUS value.

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


BUGCHECK_STR:  0x124_GenuineIntel

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  f

STACK_TEXT:  
fffff800`04590a98 fffff800`03619a3b : 00000000`00000124 00000000`00000000 fffffa80`07349028 00000000`be000000 : nt!KeBugCheckEx
fffff800`04590aa0 fffff800`031ab513 : 00000000`00000001 fffffa80`0734ca10 00000000`00000000 fffffa80`0734ca60 : hal!HalBugCheckSystem+0x1e3
fffff800`04590ae0 fffff800`03619700 : 00000000`00000728 fffffa80`0734ca10 fffff800`04590e70 fffff800`04590e00 : nt!WheaReportHwError+0x263
fffff800`04590b40 fffff800`03619052 : fffffa80`0734ca10 fffff800`04590e70 fffffa80`0734ca10 00000000`00000000 : hal!HalpMcaReportError+0x4c
fffff800`04590c90 fffff800`03618f0d : 00000000`00000008 00000000`00000001 fffff800`04590ef0 00000000`00000000 : hal!HalpMceHandler+0x9e
fffff800`04590cd0 fffff800`0360ce88 : fffffa80`05642700 fffffa80`056878c0 00000000`00000000 00000000`00000000 : hal!HalpMceHandlerWithRendezvous+0x55
fffff800`04590d00 fffff800`0309952c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalHandleMcheck+0x40
fffff800`04590d30 fffff800`03099393 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxMcheckAbort+0x6c
fffff800`04590e70 fffff800`030a0dd5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiMcheckAbort+0x153
fffff800`04584560 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDeferredReadyThread+0x115


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: hardware

IMAGE_NAME:  hardware

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE

BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE

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

OK, I don't overclock from Windows. I do BCLK ocing in BIOS. I've been overclocking since 1997. I don't think you understand. I didn't BSOD outside of trying lower voltages while OCing months ago until I added this Bluray burner and changed SATA config from IDE to AHCI. That nerfed the install and I had to repair the startup with my Windows XP install flash drive. The ASUS OCprobe installed with the drivers for the board and will not uninstall. I do not run it.

I already tried lowering clock speeds to stock, as well as voltages. I did a complete reset of the CMOS to accomplish this. It didn't stop the BSODs. This is an RMA'd processor, new motherboard, and RMA'd RAM.

The old driver is for an ancient joystick.

Please, cooperate with us or you will never receive the proper advice.

I understand, you take pride in your overclocking and you believe it is stable, and you know what? It probably is. However, it's so much easier for us to help you diagnose a BSOD, NO LESS a HARDWARE BUGCHECK BSOD, by returning whatever overclocks you have to stock. It really just makes our and your life much easier in this situation, as we can completely and 100% rule out something that can cause so many different things to malfunction.

Also, as I said earlier, when your issue is gone and you're able to use your system as you should be, go right ahead and overclock again.. have a blast, get some extra performance! Just right now, I recommend cooperation so we can help you get up & running.

You also have to understand that the Asus OCprobe utility monitors voltages and other readings in the OS itself. When you're overclocked, this utility and specific piece of software has been sometimes reported to causes extreme misreadings (temperatures, voltages, etc), and even BSODs. I can even attest, and I am sure many other members of the BSOD Team on this forum that we've seen tons of Asus software related BSODs after a member has enabled verifier and of course, Asus was the culprit.

I also believe in general this utility has been reported to cause a boatload of issue regardless of the system being overclocked or not.

We're not telling you this for the good of your health, or telling you this because we're trying to waste your time. We're telling you this because we're trying to help you, and not taking diagnostic steps will unfortunately get your nowhere.

So, with that being said, my suggestion to you is to follow the suggestions given to you, that way you can get your problem solved and use your system as intended :)

I'm at 2.66 Ghz with everything at bone stock and memory at XMP settings right now. Everything went along swimmingly until Tuesday when I installed a Pioneer bluray burner and changed to AHCI SATA configuration and repaired the windows startup with the flash drive I use to install windows. The ASUS utility has had every part of it removed except for the EPU part, whatever that is. That component is still there because whenever I try to remove it, my system hardlocks, requiring a forced restart. I cannot remove it. I haven't had a random reboot since yesterday so I'll go play Star Trek Online until I get another one and then make another crashdump to upload. I promise you guys that the crash logs you're looking at stem from months ago when I was trying a vcore less than 1.2875 volts.

ePeen said:

Please, cooperate with us or you will never receive the proper advice.

I understand, you take pride in your overclocking and you believe it is stable, and you know what? It probably is. However, it's so much easier for us to help you diagnose a BSOD, NO LESS a HARDWARE BUGCHECK BSOD, by returning whatever overclocks you have to stock. It really just makes our and your life much easier in this situation, as we can completely and 100% rule out something that can cause so many different things to malfunction.

Also, as I said earlier, when your issue is gone and you're able to use your system as you should be, go right ahead and overclock again.. have a blast, get some extra performance! Just right now, I recommend cooperation so we can help you get up & running.

You also have to understand that the Asus OCprobe utility monitors voltages and other readings in the OS itself. When you're overclocked, this utility and specific piece of software has been sometimes reported to causes extreme misreadings (temperatures, voltages, etc), and even BSODs. I can even attest, and I am sure many other members of the BSOD Team on this forum that we've seen tons of Asus software related BSODs after a member has enabled verifier and of course, Asus was the culprit.

I also believe in general this utility has been reported to cause a boatload of issue regardless of the system being overclocked or not.

We're not telling you this for the good of your health, or telling you this because we're trying to waste your time. We're telling you this because we're trying to help you, and not taking diagnostic steps will unfortunately get your nowhere.

So, with that being said, my suggestion to you is to follow the suggestions given to you, that way you can get your problem solved and use your system as intended :)

In particular, Debug session time: Mon Feb 6 03:43:17.944 2012 (UTC - 4:00)

Those crashdumps are not applicable to the issue at hand.

ePeen said:

ALL attached dumps are x124 hardware bugchecks, so something is going on here regarding your hardware most likely, especially since you've gone ahead reformatted multiple times.

General troubleshooting for this bugcheck, thanks to H2S04.

1) Ensure that none of the hardware components are overclocked. Hardware that is driven beyond its design specifications - by overclocking - can malfunction in unpredictable ways.

2) Ensure that the machine is adequately cooled. If there is any doubt, open up the side of the PC case (be mindful of any relevant warranty conditions!) and point a mains fan squarely at the motherboard. That will rule out most (lack of) cooling issues.

3) Update all hardware-related drivers: video, sound, RAID (if any), NIC... anything that interacts with a piece of hardware. It is good practice to run the latest drivers anyway.

4) Update the motherboard BIOS according to the manufacturer's instructions. Their website should provide detailed instructions as to the brand and model-specific procedure.

5) Rarely, bugs in the OS may cause "false positive" 0x124 events where the hardware wasn't complaining but Windows thought otherwise (because of the bug). At the time of writing, Windows 7 is not known to suffer from any such defects, but it is nevertheless important to always keep Windows itself updated.

6) Attempt to (stress) test those hardware components which can be put through their paces artificially. The most obvious examples are the RAM and HDD(s). For the RAM, use the in-built memory diagnostics (run MDSCHED) or the 3rd-party memtest86 utility to run many hours worth of testing. For hard drives, check whether CHKDSK /R finds any problems on the drive(s), notably "bad sectors". Unreliable RAM, in particular, is deadly as far as software is concerned, and anything other than a 100% clear memory test result is cause for concern. Unfortunately, even a 100% clear result from the diagnostics utilities does not guarantee that the RAM is free from defects - only that none were encountered during the test passes.

7) As the last of the non-invasive troubleshooting steps, perform a "vanilla" reinstallation of Windows: just the OS itself without any additional applications, games, utilities, updates, or new drivers - NOTHING AT ALL that is not sourced from the Windows 7 disc. Should that fail to mitigate the 0x124 problem, jump to the next steps. Otherwise, if you run the "vanilla" installation long enough to convince yourself that not a single 0x124 crash has occurred, start installing updates and applications slowly, always pausing between successive additions long enough to get a feel for whether the machine is still free from 0x124 crashes. Should the crashing resume, obviously the very last software addition(s) may be somehow linked to the root cause.

If stop 0x124 errors persist despite the steps above, and the harware is under warranty, consider returning it and requesting a replacement which does not suffer periodic MCE events. Be aware that attempting the subsequent harware troubleshooting steps may, in some cases, void your warranty:8) Clean and carefully remove any dust from the inside of the machine. Reseat all connectors and memory modules. Use a can of compressed air to clean out the RAM DIMM sockets as much as possible.

9) If all else fails, start removing items of hardware one-by-one in the hope that the culprit is something non-essential which can be removed. Obviously, this type of testing is a lot easier if you've got access to equivalent components in order to perform swaps.

With this being said, I'd recommend first and foremost testing your memory, I don't see any mention of doing so in the OP, so:

Read the following to test your memory for errors.

Drivers that need to be updated:

SaiH0460.sys - Mon Nov 24 05:14:27 2008 (not listed in the carona drivers list, most likely related to Saitek as other drivers minus the "H" in SaiH are labeled Saitek. Possibly a driver for the hub on the keyboard if there is one?" Update here.

For now... and please, read before typing and jumping to conclusions. Bring every component on your system that is overclocked to stop temporarily for diagnostic purposes. With all do respect, I don't care if you believe your Overclock is stable, I don't care if ran Prime95 for 400 hours and got no crashes, an overclock can & will do unthinkable thinks to a system when unstable. So, with that being said, for testing purposes allowing us to help you better, please just bring everything to stock for NOW. When your issue is solved, you're MORE THAN WELCOME to put everything back to what it once was :)

Vir Gnarus said:

All 4 crashdumps are WHEA errors reported by your CPU. Two of them state a data write error in your L2 cache of your CPU, while the other two state an issue with the internal timer of your CPU. You had the Intel Linpack benchmark running for three of them at the time, so I assume this was during stress testing while you were checking out your OCing.

There's a couple things I've seen that would cause what appears to be CPU failure displayed by these WHEA error records. First off, if you're using any utilities or software that came with your motherboard, please uninstall them. All OCing should be done straight from the motherboard. Software-based OCing is not preferred, and often the software that runs them is riddled with bugs that actually make WHEA think that the CPU is failing. The other motherboard software I've seen do the same thing in order to perform some gimmick. It's recommended to remove em all. If you wish to OC, you should resort only to doing so with the BIOS.

Very good call, my friend! After checking OP's drivers list, he does in fact have the Asus PCProbe Utility installed.


Dump for reference:

Code:

Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\Icarus\Downloads\Windows_NT6_BSOD_jcgriff2\020612-19656-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`0301e000 PsLoadedModuleList = 0xfffff800`03263670
Debug session time: Mon Feb  6 03:43:17.944 2012 (UTC - 4:00)
System Uptime: 0 days 0:18:30.866
Loading Kernel Symbols
...............................................................
................................................................
.....................................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 124, {0, fffffa8007349028, be000000, 800400}

Probably caused by : hardware

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

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa8007349028, Address of the WHEA_ERROR_RECORD structure.
Arg3: 00000000be000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000800400, Low order 32-bits of the MCi_STATUS value.

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


BUGCHECK_STR:  0x124_GenuineIntel

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  f

STACK_TEXT:  
fffff800`04590a98 fffff800`03619a3b : 00000000`00000124 00000000`00000000 fffffa80`07349028 00000000`be000000 : nt!KeBugCheckEx
fffff800`04590aa0 fffff800`031ab513 : 00000000`00000001 fffffa80`0734ca10 00000000`00000000 fffffa80`0734ca60 : hal!HalBugCheckSystem+0x1e3
fffff800`04590ae0 fffff800`03619700 : 00000000`00000728 fffffa80`0734ca10 fffff800`04590e70 fffff800`04590e00 : nt!WheaReportHwError+0x263
fffff800`04590b40 fffff800`03619052 : fffffa80`0734ca10 fffff800`04590e70 fffffa80`0734ca10 00000000`00000000 : hal!HalpMcaReportError+0x4c
fffff800`04590c90 fffff800`03618f0d : 00000000`00000008 00000000`00000001 fffff800`04590ef0 00000000`00000000 : hal!HalpMceHandler+0x9e
fffff800`04590cd0 fffff800`0360ce88 : fffffa80`05642700 fffffa80`056878c0 00000000`00000000 00000000`00000000 : hal!HalpMceHandlerWithRendezvous+0x55
fffff800`04590d00 fffff800`0309952c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalHandleMcheck+0x40
fffff800`04590d30 fffff800`03099393 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxMcheckAbort+0x6c
fffff800`04590e70 fffff800`030a0dd5 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiMcheckAbort+0x153
fffff800`04584560 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDeferredReadyThread+0x115


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: hardware

IMAGE_NAME:  hardware

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE

BUCKET_ID:  X64_0x124_GenuineIntel_PROCESSOR_MAE

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

Have you tried safe mode when it comes to removing the EPU part of probe?

And as far as the crash dumps go, that's fine my friend, those were just the only ones you had / had attached, so that's what we're telling you :)

I will further wait any more dumps.

No, a BSOD not being written can be a wide variety of things. See if it crashes again and doesn't write a dump.