Sunday, 21 February 2010

BSOD - "A clock interrupt was not received on a secondary processor within an allocated time"

I mentioned yesterday that the Hyper-V server had been experiencing the Blue Screen Of Death with the message "A clock interrupt was not received on a secondary processor within an allocated time" (0x00000101). The problem is that it doesn't really give you any clues as to what was the cause of the error.

Yesterday morning I changed the BIOS defaults to "Fail safe" and things had been working fine… until this morning, when it crashed again. Researching this error is not that encouraging:

  • There are a few posts to forums where suggestions such as BIOS settings, defective CPU cores, RAM timing, CPU VCore etc are thrown up.
  • Almost every other reference I've seen also indicates the problem is seen when running a 64-bit OS.
  • AMD lists some basic checks but nothing very specific (I've already tried resetting BIOS settings, updated the BIOS to the latest firmware version

Presumably Microsoft are slightly more interested in the crash as today's Windows Error Reporting asked for me to submit extra debugging info. I'm happy to do that, though I don't expect to get any quick answers.

This is quite frustrating as until I can identify and resolve the cause of this problem, I don't have a lot of confidence in the server.

4 comments:

David Gardiner said...

FYI Got this reply back from Gigabyte:


Dear David,

Thank you for your kindly mail and inquiry. About the issue you mentioned, because several possibilities might cause the problems, such as something wrong with memory, motherboard, BIOS, driver, power, attached hardwares...etc. We suggest that you could try to do a simple test first:

Remove such as add-on cards, devices from motherboard, only install CPU, single memory, single HDD, VGA card and power (simple environment), and make sure the components on the motherboard are installed properly, then please take off the on-board battery to leak voltage to clear CMOS data by following the steps below:

1) Turn off power.
2) Remove the power cord from the PSU.
3) Take out the battery gently and put it aside for about 5 minutes or longer. (Or you can use a metal object to connect the two pins in the battery holder to make them short-circuited.)
4) Re-insert the battery to the battery holder.
5) Connect power cord to PSU again and turn on power.
6) Power on your system.
7) If BIOS can POST, please enter the BIOS and load the fail-safe defaults setting.
7) Save changes and reboot the system.

After clearing CMOS and load the fail-safe defaults, please test your system in a simple environment to observe the result. If there's nothing wrong in simple environment, try to install several additional cards into the slot one by one to observe the result again and again.

But, if the problem still occurs in a simple environment, then a further testing or examination to your system might be required. We suggest you can contact your supplier or nearest distributor and see if they can help you to test your system directly. For distributor contact information, please click HERE.

We are really sorry for the inconvenience you have with our product.

At last, if you still have any further question or suggestion about our products/service, please do not hesitate to contact with us. We will try our best to help you resolve the problem ASAP.

Regards,
GIGABYTE TECHNOLOGY

David Gardiner said...

Just stumbled across this post by the Virtual PC Guy. Hoping this might solve my problem!

-dave

Sven De Bont said...

David,

Did you get this issue solved?

I have the exact same issue on a brand new DELL M6500 laptop with W2K8R2 & the hyper-v role?

Regards,

Sven

David Gardiner said...

Hi Sven,

Yes! That patch that Ben (The Virtual PC Guy) mentions did the trick. My machine has been rock solid since I applied that fix.

-dave