Phenom 9500 + Vista x64 = Many BSOD's HELP!!!

Many, many moons ago I was in IT, but haven't been there for a long time.

Just finished building a new system consisting of:

Processor: AMD Phemon 9500
Motherboard: ASUS M3N78-EM BIOS Revision: 0520
Video: Integrated GeForce 8300 on motherboard
Memory: 2 x Corsair XMS2 2GB PC6400 800MHz DDR2
Hard Drive: Seagate ST3160 160GB SATA
DVD Drive: Lite-On DVD-RW SOHW-1633S
Power Supply: Coolmax CX-400 400W

Installed a clean Vista Ultimate x64 OS and immediately started getting periodic BSOD's. Always the same BSOD message:

"A CLOCK INTERRUPT WAS NOT RECEIVED ON A SECONDARY PROCESSOR WITHIN THE ALLOCATED TIME INTERVAL"

I have tried running with the TLB fix both enabled and disabled in the BIOS, but it doesn't seem to make any difference.

I have tried to get the SP1 installed to see if that makes a difference, but I can't get the service pack installed without a BSOD interrupting part way through.

I'm not particularly concerned about having a performance drop to ensure stability, but I am very eager to get a stable Vista x64 installation, and don't want to go back to XP x32.

Please take pity on a Vista newbie. I tried searching the forum to see if anyone else has had the same problem, but didn' find a similar posting.

Terry

I installed WinDBG per instructions in another thread, but when I try to Open the Memory Dump, I am denied permission despite being logged on in an administrator account. Would love to see and/or post the contents of the minimdump. Any suggestions?

Terry

Don't know what I did, but I was able to get the memory dump open.

Kernel Summary Dump File: Only kernel address space is available
Symbol search path is: SRV*c:\windows\symbols*Symbol information
Executable search path is:
Windows Vista Kernel Version 6000 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6000.16830.amd64fre.vista_gdr.090302-1506
Machine Name:
Kernel base = 0xfffff800`01c00000 PsLoadedModuleList = 0xfffff800`01d9af70
Debug session time: Sun Apr 26 19:19:36.946 2009 (GMT-7)
System Uptime: 0 days 0:20:39.756
Loading Kernel Symbols
...............................................................
................................................................
.............
Loading User Symbols
Loading unloaded module list
.........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 101, {31, 0, fffff98000d51180, 3}
Page cdfb5 not present in the dump file. Type ".hh dbgerr004" for details
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
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: 0000000000000031, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: fffff98000d51180, The PRCB address of the hung processor.
Arg4: 0000000000000003, 0.
Debugging Details:
------------------
Page cdfb5 not present in the dump file. Type ".hh dbgerr004" for details
BUGCHECK_STR: CLOCK_WATCHDOG_TIMEOUT_4_PROC
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: d
STACK_TEXT:
fffff980`00c1a708 fffff800`01c36769 : 00000000`00000101 00000000`00000031 00000000`00000000 fffff980`00d51180 : nt!KeBugCheckEx
fffff980`00c1a710 fffff800`01c50cba : 00000000`00000fff fffff800`021083c0 fffff980`00c1a890 fffff980`00c1a840 : nt! ?? ::FNODOBFM::`string'+0x41d4
fffff980`00c1a760 fffff800`020e5914 : 00000000`00000000 00000007`37bdb237 00000000`00000000 00000007`37be13c5 : nt!KeUpdateSystemTime+0xea
fffff980`00c1a790 fffff800`01c4f4dd : fffff800`01d45b88 00000000`00000000 fffff800`01c00000 00000000`00000000 : hal!HalpHpetClockInterrupt+0x8c
fffff980`00c1a7c0 fffff800`01c8e3f8 : 00000000`00000006 fffff800`01d45b48 00000000`00000000 fffff800`01d45b88 : nt!KiInterruptDispatchNoLock+0x14d
fffff980`00c1a950 fffff800`01ce9d80 : fffff900`00812488 00000000`00000000 fffff800`01d45b40 00000000`00000001 : nt!KeFlushMultipleRangeTb+0xc8
fffff980`00c1a980 fffff800`01d07d77 : fffff980`014c3c00 00000000`00000001 fffff980`00c1abb0 fffff980`00c1abe0 : nt!MiAgeWorkingSet+0x4bd
fffff980`00c1ab40 fffff800`01c67ab7 : fffffa80`0000000e 00000000`00000002 fffff800`01d86508 00000000`00000000 : nt!MiProcessWorkingSets+0x217
fffff980`00c1abb0 fffff800`01c67882 : fffffa80`036bc000 00000000`00000001 00000000`00000006 00000000`00000008 : nt!MmWorkingSetManager+0x1d7
fffff980`00c1ac10 fffff800`01ee1d5b : fffffa80`036bc040 00000000`00000080 00000000`00000000 00000000`00000001 : nt!KeBalanceSetManager+0x11f
fffff980`00c1ad50 fffff800`01c34686 : fffff980`00a05180 fffffa80`036bc040 fffff980`00a0ec40 00000000`00000001 : nt!PspSystemThreadStartup+0x5b
fffff980`00c1ad80 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: X64_CLOCK_WATCHDOG_TIMEOUT_4_PROC_ANALYSIS_INCONCLUSIVE
BUCKET_ID: X64_CLOCK_WATCHDOG_TIMEOUT_4_PROC_ANALYSIS_INCONCLUSIVE
Followup: MachineOwner

run Windbg with "run as admin" in Windbg.exe properties. Alternatively you can copy the dump to a non-os folder.


EDIT: I see you sorted windbg

Much thanks for the advice!

no worries, as for the error, I would periodically get that while my over clock was unstable. I solved it by upping volts to the CPU.

But since your at stock speeds, the situation is different. Perhaps upgrade to the latest BIOS and check that your voltages (vcore) are set correctly in the BIOS.

Good advice ... except that I updated the BIOS to the latest (0520) this afternoon, and the core voltage is exactly at spec.

Now that I have access to the dumps, I am finding ther are some variations in the dump each time. For example:

Loading Dump File [C:\Windows\Minidump\Mini042609-05.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\windows\symbols*Symbol information
Executable search path is:
Windows Vista Kernel Version 6000 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 6000.16830.amd64fre.vista_gdr.090302-1506
Machine Name:
Kernel base = 0xfffff800`01c00000 PsLoadedModuleList = 0xfffff800`01d9af70
Debug session time: Sun Apr 26 18:02:16.419 2009 (GMT-7)
System Uptime: 0 days 0:00:43.587
Loading Kernel Symbols
...............................................................
................................................................
....
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 101, {31, 0, fffff98000d51180, 3}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
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: 0000000000000031, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: fffff98000d51180, The PRCB address of the hung processor.
Arg4: 0000000000000003, 0.
Debugging Details:
------------------

BUGCHECK_STR: CLOCK_WATCHDOG_TIMEOUT_4_PROC
CUSTOMER_CRASH_COUNT: 5
DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
PROCESS_NAME: svchost.exe
CURRENT_IRQL: d
STACK_TEXT:
fffff980`11ca56b8 fffff800`01c36769 : 00000000`00000101 00000000`00000031 00000000`00000000 fffff980`00d51180 : nt!KeBugCheckEx
fffff980`11ca56c0 fffff800`01c50cba : 00000000`00000000 fffff800`021083c0 00000000`00000001 fffff980`11ca57f0 : nt! ?? ::FNODOBFM::`string'+0x41d4
fffff980`11ca5710 fffff800`020e5914 : 000007fe`fbfcf328 00000000`00000020 00000000`00000000 fffff800`01d4a980 : nt!KeUpdateSystemTime+0xea
fffff980`11ca5740 fffff800`01c4f4dd : 00000000`0000000e fffff800`01d4a980 00000000`00000000 00001f80`00000c00 : hal!HalpHpetClockInterrupt+0x8c
fffff980`11ca5770 fffff800`01c109ea : fffff980`00000000 00000000`0000000e fffff980`11ca5ca0 00000000`00000000 : nt!KiInterruptDispatchNoLock+0x14d
fffff980`11ca5900 fffff800`01f0a0fc : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeFlushProcessWriteBuffers+0x9a
fffff980`11ca5950 fffff800`01c4d833 : fffffa80`07d30060 00000000`00013880 ffffffff`fffe7960 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x369ba
fffff980`11ca5c20 00000000`770305da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`011fef78 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x770305da

STACK_COMMAND: kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: X64_CLOCK_WATCHDOG_TIMEOUT_4_PROC_ANALYSIS_INCONCLUSIVE
BUCKET_ID: X64_CLOCK_WATCHDOG_TIMEOUT_4_PROC_ANALYSIS_INCONCLUSIVE
Followup: MachineOwner

Have you installed the motherboard chipset drivers yet?

Yup! Plus the updated version supplied through Windows Update. Still getting the BSOD.

Click me ===> Stop error message on a Windows Vista or Windows Server 2008-based computer that has multiple processors installed: "STOP: 0x00000101 CLOCK_WATCHDOG_TIMEOUT"

First, let me say that you have an amazing ability to identify true cuases of mysterious problems. I am greatly appreciative.

I have one minor hurdle in the way of moving forward to the solution. The hotfix in the link you posted required SP1 as a prerequisite. I have not been able to get SP1 installed without a BSOD interrupting. Any thoughts on how I can prevent a BSOD long enough to get SP1 loaded? Safe Mode? Manually configure the Audit Policy to force Audit Privilege use?

metalman said:

First, let me say that you have an amazing ability to identify true cuases of mysterious problems. I am greatly appreciative.

Click to expand...

Let that be aimed at the entire team of regulars here. On their behalf, thanks, and no probs at all

metalman said:

I have one minor hurdle in the way of moving forward to the solution. The hotfix in the link you posted required SP1 as a prerequisite. I have not been able to get SP1 installed without a BSOD interrupting. Any thoughts on how I can prevent a BSOD long enough to get SP1 loaded? Safe Mode? Manually configure the Audit Policy to force Audit Privilege use?

Click to expand...

Is the BSOD you experience during SP1 installation also a 0x101 (clock interrupt timer thingy timeout)? Always?

H2SO4 said:

Is the BSOD you experience during SP1 installation also a 0x101 (clock interrupt timer thingy timeout)? Always?

Click to expand...

Yes, it is always the same 0x101 thingy, during the configuration of the update after reboot.

It could be a faulty CPU. Open Task Manager and select the Performance tab. Under View ensure that in the option CPU History you have selected One Graph Per CPU. Also ensure that Show Kernal Times is enabled.

Whilst viewing the graphs, do any of them show noticeably less activity compared to the others? Does this change if you execute other applications?

metalman said:

H2SO4 said:

Is the BSOD you experience during SP1 installation also a 0x101 (clock interrupt timer thingy timeout)? Always?

Click to expand...

Yes, it is always the same 0x101 thingy, during the configuration of the update after reboot.

Click to expand...

This error is specific to Vista and Win2K8 in the sense that previous versions of Windows didn't have that "watchdog" code at all - a processor could be unresponsive to inter-processor interrupts (IPIs) and there would be no immediate bugcheck (BSoD) because there was no detection mechanism.

KB995076 describes a problem that results in "false positive" bugcheck 0x101's. The new kernel from the KB967170 is apparently the first one which contains the fix. (The 0x101 bugchecks have nothing to do with auditing per se - that's just the first build of the kernel which contains the 0x101 "false positives" fix.)

Otherwise, it really may be a hardware problem like Dwarf said. The fact that this happens to you so readily is a tad worrying. I'd be curious to see a minidump, if you can upload one.

=======================

One way to get around your SP1 application issue might be to boot with the KB967170 kernel and then apply SP1. To do that:

- Expand the KB967170 hotfix without installing it (use the '-x' command-line switch). Give the new kernel a different name (testkrnl.exe for example) and leave it in \windows\system32.

- Create a NEW entry in the boot data store using BCDEDIT.EXE from an elevated CMD prompt. Note its ID. For example: {d2b69192-8f14-11da-a31f-ea816ab185e9}.

- Use BCDEDIT with the ID of the new entry and the 'kernel' switch to specify the use of your testkrnl.exe:
DO NOT do that to the default boot entry otherwise you may find yourself locked out and unable to get into the OS if something should go wrong (which is entirely possible ). Make a new, non-default boot entry and experiment with that one instead.

metalman said:

First, let me say that you have an amazing ability to identify true cuases of mysterious problems. I am greatly appreciative.

I have one minor hurdle in the way of moving forward to the solution. The hotfix in the link you posted required SP1 as a prerequisite. I have not been able to get SP1 installed without a BSOD interrupting. Any thoughts on how I can prevent a BSOD long enough to get SP1 loaded? Safe Mode? Manually configure the Audit Policy to force Audit Privilege use?

Click to expand...

Just a tip.....

Even I have the same issue (Get the same error message) but my hardware specs is different. I was able to isolate the issue as when I disable "Core Mutli-processing" option from the BIOS, I was able to install SP1 and SP2 (beta) for Vista.

My system works great without Core Mutli-processing, but when ever I enable it I get the same error message what u have posted above.

All the best

Raghuv said:

metalman said:

First, let me say that you have an amazing ability to identify true cuases of mysterious problems. I am greatly appreciative.

I have one minor hurdle in the way of moving forward to the solution. The hotfix in the link you posted required SP1 as a prerequisite. I have not been able to get SP1 installed without a BSOD interrupting. Any thoughts on how I can prevent a BSOD long enough to get SP1 loaded? Safe Mode? Manually configure the Audit Policy to force Audit Privilege use?

Click to expand...

Just a tip.....

Even I have the same issue (Get the same error message) but my hardware specs is different. I was able to isolate the issue as when I disable "Core Mutli-processing" option from the BIOS, I was able to install SP1 and SP2 (beta) for Vista.

My system works great without Core Mutli-processing, but when ever I enable it I get the same error message what u have posted above.

All the best

Click to expand...

That's actually an excellent way for the OP to temporarily get around their SP1 application issues so they can apply the KB967170 hotfix - much better than my suggestion. Single proc means no inter-proc interrupts and hence no likelihood of 0x101 bugchecks.

However, don't assume the cause of your 0x101 bugcheck is exactly the same as the OPs. If you haven't already applied KB967170, that would be the first thing to try. From now on, it might be best to discuss your issue in the other thread you've created, so this one's not hijacked.

Some excellent advice and suggestions, which I am sure would have helped my situation. I'll keep them in my back pocket should I need them in the future.

I am happy to report that once I was able to apply the KB967170 kernel patch, all instability issues were INSTANTANEOUSLY eliminated. My short term fix was to shut down every extraneous process (such as firewall, security, etc.) that was running, and make multiple attempts at installing SP1 until one was able to complete. Interestingly, after SP1 was installed, the stability went from bad to worse, with the BSOD sometimes appearing before the boot was complete. Luckily KB967170 does not take long to install, and since it was installed there hasn't been a single instance of BSOD despite my aggressive attempts to force one.:D

Now, to be on the safe side I have a backup of my stable install in progress. I still have a minor niggling problem in that the .NET 3.5 service pack steadfastly fails to install, but as that is not causing me any direct problems, I'm not particularly bothered.

For H2SO4 I'll try to extract the last minidump and post it for informational purposes.

Thanks again to the great forum team helping out. Without you I'd be installing XP right now instead of exploring Vista!

Thanks, Terry

Awesome, glad to hear it. Nothing better than the realisation that what looked like a hardware problem will in fact cost $0 to fix