Clock Interrupt not received and hyperthreading

[PaulKay]

First my computer details:
HP Pavilion e9150t
Core i7-920, 2.66 ghz
8 Gb DDR-3
nVidia GeForce 220 w/1 Gig
Hauppauge WinTV HVR-1800
Soundblaster x-fi extreme
Windows 7 Ultimate 64-bit

I've had an ongoing blue screen problem whenever I was playing back video. This was both internet based playback, but also TV video in the media center as well.
I updated all the video and TV card drivers as well as the BIOS, no change.
I ran a complete hardware diagnostic and no problems were found

The particular blue screen error was "clock interrupt not received from peripheral within the required time interval". The computer would reset before the crash dump could complete.

After trying every suggested fix I could find, I came across a somewhat related forum post on the internet that called into question the hyperthreading feature of the i7. So as and experiment I went into the BIOS and disabled hyperthreading. So far, the problem has disappeared. I'm convinced the problem was in one of the drivers, but I could never track down which one. But it appears that the bug was related to how it was handling the hyperthreading feature. Turn off hyperthreading and bug cannot exhibit itself. I'm sure the bug is still there, but at least the BSODs are gone for now.

I'm curious if anyone else has seen this problem and if they've done the same thing to resolve it?

 

[usasma]

Although there's not a lot of info about this on the web, take a look here for what I was able to gather: BSOD Index

If the problem was that the unknown program couldn't handle working processors that are using HyperThreading - then the fix is to figure out which program it is. Disabling HyperThreading may stop it - but that will also slow down the system.

I'd suggest looking at all of your installed devices and programs - and start with the oldest one first.
Uninstall it and test to see if it fixes the problem.
If not, remove the next one and so on - until you've found the offending device.

This presumes that there isn't a problem with the processor or with Windows

 

[PaulKay]

Thank you! That information will be very useful in trying to track this down. As it turns out the crash still happened after all even with hyperthreading turned off. I powered down the unit and powered it back up and while watching a video it crashed. Once the crash occurs, it doesn't seem to happen again after the reboot. So apparently it isn't related to hyperthreading after all.

 

[usasma]

Can you make the system crash? If so, boot into Safe Mode (with networking if needed) and see if you can also make it crash there.

Also, try using Driver Verifier according to these directions (you may be able to get a driver name off the Blue Screen):

Using Driver Verifier is an iffy proposition. Most times it'll crash and it'll tell you what the driver is. But sometimes it'll crash and won't tell you the driver. Other times it'll crash before you can log in to Windows. If you can't get to Safe Mode, then you'll have to resort to offline editing of the registry to disable Driver Verifier.

So, I'd suggest that you first backup your stuff and then make sure you've got access to another computer so you can contact us if problems arise. Then make a System Restore point (so you can restore the system using the Vista/Win7 Startup Repair feature).

In Windows 7 you can make a Startup Repair disk by going to Start....All Programs...Maintenance...Create a System Repair Disc - with Windows Vista you'll have to use your installation disk or the "Repair your computer" option at the top of the Safe Mode menu .

Then, here's the procedure:
- Go to Start and type in "verifier" (without the quotes) and press Enter
- Select "Create custom settings (for code developers)" and click "Next"
- Select "Select individual settings from a full list" and click "Next"
- Select everything EXCEPT FOR "Low Resource Simulation" and click "Next"
- Select "Select driver names from a list" and click "Next"
Then select all drivers NOT provided by Microsoft and click "Next"
- Select "Finish" on the next page.

Reboot the system and wait for it to crash to the Blue Screen. Continue to use your system normally, and if you know what causes the crash, do that repeatedly. The objective here is to get the system to crash because Driver Verifier is stressing the drivers out. If it doesn't crash for you, then let it run for at least 36 hours of continuous operation (an estimate on my part).

Reboot into Windows (after the crash) and turn off Driver Verifier by going back in and selecting "Delete existing settings" on the first page, then locate and zip up the memory dump file and upload it with your next post.

If you can't get into Windows because it crashes too soon, try it in Safe Mode.
If you can't get into Safe Mode, try using System Restore from your installation DVD to set the system back to the previous restore point that you created.

If that doesn't work, post back and we'll have to see about fixing the registry entry off-line:

Delete these registry keys (verified in Win7):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel


More info on this at this link: Using Driver Verifier to identify issues with Windows drivers for advanced users

 

[PaulKay]

It crashes pretty reliably the first time I turn on the computer. But generally not reliably or at all after that first reboot. The stop code I'm getting is the 0x101 which in you BSOD list is described as:
STOP 0x00000101: CLOCK_WATCHDOG_TIMEOUT (go to top of page)

Usual causes: Device driver, BIOS bug, hardware defect (see Significant Posts section below)

Knowledge Base Articles:
KB 955076 Stop error message on a Windows Vista or Windows Server 2008-based computer that has multiple processors installed: "STOP: 0x00000101 CLOCK_WATCHDOG_TIMEOUT"

Significant Posts: http://www.sevenforums.com/crashes-debugging/35427-win-7-clock-interrupt-bsod-101-error.html#post356791

These types of error messages are relatively simple, from a certain viewpoint: as frequently happens during normal processing, one core (processor) attempted to get the attention of another core, in order to synchronise their activites with respect to an operation that requires processor coordination. Described using "official" terminology:

"CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts."

The trigger for the crash is the "sender/requestor" processor going "wtf? why is there still no response after almost half a second?!?" Those inter-processor interrupts (IPIs) are some of the most critical activity imaginable, and an unrequited IPI is absolutely lethal - hence the crash.

AMD procs had known issues which manifested themselves in this manner under Vista and Windows 7. There were/are many possible problem permutations, some solved through BIOS updates, and some necessitating fiddling with the "Translation Lookaside Buffer" (TLB), as per torrentg's suggestion to look up 0x101 and AMD and TLB.

Your real aim is to give yourself the best possible chance of discovering a software cause for the target processor to go unresponsive, and thereby avoid the most obvious conclusion - that the processor is periodically unresponsive because of hardware-level defects

I can confidently tell you that the browsers, apps, and games cannot be the root cause of this problem, even though I don't doubt your observation that the operation of certain software seems to more easily trigger the crash. What you're looking for will be in one of the following categories:

a) BIOS bug
b) a driver whose activity is causing the target processor to lock up
c) a hardware defect (temperature, voltage, dust, RFI, outright borkedness...)
- H2SO4

WinDbg Help File Entry:

The CLOCK_WATCHDOG_TIMEOUT bug check has a value of 0x00000101. This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.
Parameters
The following parameters are displayed on the blue screen.
ParameterDescription1Clock interrupt time-out interval, in nominal clock ticks 203The address of the processor control block (PRCB) for the unresponsive processor 40

Cause
The specified processor is not processing interrupts. Typically, this occurs when the processor is nonresponsive or is deadlocked.
WinDbg Output Example:

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000019, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: fffff88002f64180, The PRCB address of the hung processor.
Arg4: 0000000000000002, 0.

At least if it turns out to be a hardware problem, the computer is still under warranty.

My next step is to power down the computer and restart in safe mode to see if it happens there. Then I'll try the driver verify.

I really appreciate all the help in tracking this down. I'd like to figure this out.

 

[PaulKay]

I did try booting in safe mode with networking and it crashed with code 0xF4 this time. I took a lot longer for it to happen though. A different code, but it still crashed even in safe mode w/networking.

So I guess I need to try the driver verifier.

 

[usasma]

The STOP 0xF4 error is usually caused by software - and not by hardware.
It's possible for software to initiate conditions that cause the mishandling of interrupts - so the STOP 0x101 error can be caused by software also.

As H2SO4 describes it:

Your real aim is to give yourself the best possible chance of discovering a software cause for the target processor to go unresponsive, and thereby avoid the most obvious conclusion - that the processor is periodically unresponsive because of hardware-level defects

In other words, hardware problems are most likely with this error - BUT - software issues can cause this also. You could spend the money on a new processor (and the pain/expense of installing it) - only to find that the error still exists.

So, try the Driver Verifier and then upload/attach the zipped up minidumps to your next post.

 

[PaulKay]

I installed the driver verifier this morning and tried a normal boot. It never got to Windows, it crashed with error code 0x0A IRQL_Not_Less_Or_Equal
I can't seem to find any crash dump file.

I rebooted to safe mode with Networking and am now waiting for it to crash in this condition.
The only drivers that are available to crash here of course is only limited to networking drivers

 

[PaulKay]

Crash dump from 5/26

Since I can't get driver verify to generate a crash dump...it never gets into windows without safe mode and safe mode doesn't want to crash, here is a dump from 5/26 that was without driver verify on.

 

[usasma]

The error occurs in normal mode boot - but not in Safe Mode boot.
Therefore it's most likely due to a driver that loads in normal mode, but not in Safe Mode.

So, let's give "Clean boot" troubleshooting a shot: How to troubleshoot a problem by performing a clean boot in Windows Vista or in Windows 7

If it doesn't BSOD fast enough for you, you may try enabling Driver Verifier.
Please be advised that this may not fix (or even identify) the problem. (In general drivers load as services - so it should work)
If not, then we'll have to use another program to disable drivers from loading (but it's a lot more work!).

 

[PaulKay]

It seems to be getting worse. Today it cashed with a MACHINE_CHECK_EXCEPTION 0x9C.

This is the first time I've seen this one and according to the BSOD index, it doesn't mention anything about possible driver problems.

Attached is the memory dump. I never got the chance to try the clean boot option yet.

 

[usasma]

The MACHINE_CHECK_EXCEPTION (STOP 0x9C) is an error that pertains to XP, it's been replaced in Vista and Win7 by STOP 0x124.

In general this is a strictly hardware/compatibility issue. If the clean boot doesn't remedy things, then we're going to have to start looking for a hardware failure.

Summary of the BSOD:

Built by: 7600.16539.amd64fre.win7_gdr.100226-1909
Debug session time: Tue Jun  8 18:34:58.498 2010 (GMT-4)
System Uptime: 0 days 0:50:58.495
*** WARNING: Unable to verify timestamp for Unknown_Module_00000000`00000000
BugCheck 9C, {0, fffff88003097c70, 0, 0}
Probably caused by : ntkrnlmp.exe ( nt!KxMcheckAbort+6c )
BUGCHECK_STR:  0x9C_GenuineIntel