Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having an interesting problem with my recent Core i7 Digital Audio workstation build that I am curious to see if others have encountered. First, here are the specs on the machine.

ASUS P6TD Deluxe Intel X58 Socket LGA1366 MB Intel Core i7-950 3.06Ghz 8M LGA1366 CPU CORSAIR DOMINATOR 6GB (3 x 2GB) 240-Pin DDR3 SDRAM DDR3 1600 Western Digital Caviar Black WD5001AALS 500GB

Plus a couple ASUS optical drives and a 750W Corsair PSU. Running Windows 7 x64.

All this is connected to the nefarious Digi 002 firewire audio interface for use with Pro Tools. I following mostly the specs posted by many other I7 users in the digidesign community who pooled their collective knowledge in this thread.

Now after completing my build, I fell victim to the "UD5 squeal" described at that forum thread. So taking the advice posted, I disabled c1e advanced halt state and Intel speed stepping (I would likely have done this anyway to maintain a stable clock, power consumption isn't really a relevant concern on this machine.)

I enabled XMP to set the ram timings properly as well.

What I am experiencing is a BSOD upon shutdown, but only immediately after windows fully exits and ends all processes. The error is a MACHINE_CHECK_EXCEPTION 0x000000. The funny thing is that it is extremely intermitent and only occurs if the shutdown immediately followed a period of relative idleness. It does not a generate a minidump, I suspect because windows monitoring has terminated by the time this error occurs. No damage is evident and one can simply turn off manually and the system will act as though a proper shutdown had occurred. If anything it is a annoyance, I just want to be certain it is not affecting my long term stability.

I have read that the i7 950 does not like DRAM voltages past 1.65, but that they are acceptable if they are within .5 of the BLCK setting. I have tried disabling XMP and setting all timings to auto and the problem still manifests in an identical way. It is suspect that the cpu idleness preceding shutdown is the determining factor, as both c1e and speedstepping are both settings intended to modify handling of this state.

Any suggestions or prior experiences would be greatly appreciated.

EDIT: The behavior very closely resembles what's described in this thread:

The benign nature of it of is identical. I can't seem to download the hotfix cited there however.

share|improve this question
For the Googler's out there, this problem seems to have been resolved by Microsoft in a recent windows update. I found nothing faulty with my hardware and it's been running stable now for more than a year. I just would like to record this for posterity and any new system builders doing a stock install who might get alarmed by this issue with their new hardware =) – DeaconDesperado Jun 7 '12 at 20:49

A machine check exception is a hardware problem -- the CPU has thrown an interrupt indicating that it's internal state isn't valid. My guess given that the chip was being overvolted is that at least a portion of your chip is damaged.

I have read that the i7 950 does not like DRAM voltages past 1.65, but that they are acceptable if they are within .5 of the BLCK setting.

Revert to stock voltages and see if this persists. From my understanding one fries the i7 pretty quickly by pushing it past 1.65 -- this limit is because of the breakdown voltages of transistors inside the i7's memory controller.

Unfortunately to me it just sounds like a damaged chip :(

EDIT: From Anandtech: (Emphasis mine)

Exactly what the impact to the processor will be is dependent upon several factors. Put simply, if you go crazy with VDimm, let’s say around 2.0V~2.2V without additional tuning, then expect to greatly reduce the processor lifespan to a few weeks or maybe days. We have already witnessed several CPUs being damaged or destroyed at the motherboard partners with high VDimm settings, especially those that ran at 2.0V or higher with base settings. By base settings, we mean configuring an i7/X58 platform in the same manner a typical user now sets up a Penryn/X48 DDR3 platform. The rules have changed completely for Intel, just we cannot discuss the playbook at this time (hey, it is frustrating for us also).

Likewise, we have seen high VCore/VDimm test beds operate without a problem for benchmarking purposes (yet still fail with long-term bench testing) provided a multitude of BIOS settings for the core, DIMM, IMC, Uncore, and QPI selections were properly set. The base secret (there are more) is maintaining correct amplitude levels, something we will discuss at product launch. For now, high VDimm is not necessarily the true problem here, but it is the quickest way to damage/destroy an i7 if the rest of the system is not properly tuned.

share|improve this answer
Would there be any other problems that could manifest in the case that this was a damaged chip? The system is remarkably stable within the OS, much more so than the previous build for this purpose. I have had no other troubles and the memtest us clean. – DeaconDesperado Dec 16 '10 at 15:35
Also, at stock voltages this still happens if the shutdown follows at least a 5 minute period of low cpu load (web browsing, etc.) Reenableing c1e and speedstepping seems to solve the problem completely. – DeaconDesperado Dec 16 '10 at 15:38
@DeaconDesperado: I don't know too much about the i7 specifically -- I just know that the only time a CPU throws that interrupt is when there's a problem with the chip itself. – Billy ONeal Dec 16 '10 at 15:47
Thanks for your help in any event. That last bit of info is helpful in of itself! I'm going to open a support ticket with ASUS when I have the box handy and see what they think. My curiousity on the matter pertains to the fact that it ONLY happens on shutdown and is otherwise totally stable, as well as the way it is affected by the power saving BIOS options (as though they were mandatory.) – DeaconDesperado Dec 16 '10 at 15:50
ASUS is recommending a BIOS Flash - will attempt that tonight and post results here. – DeaconDesperado Dec 16 '10 at 16:22

Perform a clean boot, see if the problem continues when shutting down from a clean boot environment, if it does, then you can suspect some service, software or driver is causing it.

Here is an article that covers a general troubleshooting procedure for XP and a different problem but could be used in your case (W7) to eliminate a 3rd party service, software or driver causing your problem.


If you do not get it sorted out, suspect a possible defective motherboard or other piece of hardware connected to it.

I assume you have stress tested your Memory modules using

share|improve this answer
memtest shows stable, this was my first thought as well. – DeaconDesperado Dec 16 '10 at 15:36
Disconnect all unneeded hardware from the mobo, see if it stops the bsod. Hopefully the bios flash will cure it. – Moab Dec 16 '10 at 16:29
Will do. I would not be surprised if the Digi itself was causing some conflicts although avid did release a driver update and I did install it, we all know how that can go. Unfortunately if it is I will need to find a way to make it work because that's the whole point of the DAW lol. – DeaconDesperado Dec 16 '10 at 16:41
More info on the bug check code, definitely caused by low level – Moab Dec 16 '10 at 16:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .