# BSOD "a clock interrupt was not received on a secondary processor"



## Kedama (Dec 22, 2011)

Hello, recently, for about a month or so, Ive been having random crashes quite often (Once or twice a day). The error message has always been the one in the title and ive kinda delayed getting around to fixing it. I've researched it, and a few people said that AVG could be to blame, but its still occurring after an uninstall. I have made quite a few changes to the system but im not quite sure which ones caused this and it would take an eternity to go through them (Id much rather do a clean install) My specs are as follows:

Windows 7 SP1 Ultimate 64-bit
AMD Phenom II X2 560 4.0GHZ (Overclocked, its 3.0ghz standard)
2 X 2GB OCZ Platinum @ 800mhz
Satellite SL-8600EPS 600W PSU
Nvidia Geforce GTX 260 Black Edition by XFX
2 X 320gb WD Blue in RAID0
Gigabyte MA770-UD3

Im pretty sure the overclocking is not to blame, I overclocked it long ago and it survived 48 hours of prime 95 with no errors. I even ran it at standard clock for a few days and the BSODs still continued. I downloaded a program to look at my crash dumps and it gave me the following info:


```
On Thu 12/22/2011 5:39:54 PM GMT your computer crashed
crash dump file: C:\Windows\Minidump\122211-38672-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x7CC40) 
Bugcheck code: 0x101 (0x61, 0x0, 0xFFFFF880009E6180, 0x1)
Error: CLOCK_WATCHDOG_TIMEOUT
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval. 
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. This problem might be caused by a thermal issue. 
The crash took place in the Windows kernel. Possibly this problem is caused by another driver which cannot be identified at this time. 


On Thu 12/22/2011 5:39:54 PM GMT your computer crashed
crash dump file: C:\Windows\memory.dmp
This was probably caused by the following module: hal.dll (hal!HalReturnToFirmware+0xB2D) 
Bugcheck code: 0x101 (0x61, 0x0, 0xFFFFF880009E6180, 0x1)
Error: CLOCK_WATCHDOG_TIMEOUT
file path: C:\Windows\system32\hal.dll
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: Hardware Abstraction Layer DLL
Bug check description: This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval. 
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. This problem might be caused by a thermal issue. 
The crash took place in a standard Microsoft module. Your system configuration may be incorrect. Possibly this problem is caused by another driver on your system which cannot be identified at this time. 


On Wed 12/21/2011 7:01:24 PM GMT your computer crashed
crash dump file: C:\Windows\Minidump\122111-37377-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x7CC40) 
Bugcheck code: 0x101 (0x61, 0x0, 0xFFFFF880009E6180, 0x1)
Error: CLOCK_WATCHDOG_TIMEOUT
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval. 
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. This problem might be caused by a thermal issue. 
The crash took place in the Windows kernel. Possibly this problem is caused by another driver which cannot be identified at this time. 


On Tue 12/20/2011 3:16:24 AM GMT your computer crashed
crash dump file: C:\Windows\Minidump\122011-39218-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x7CC40) 
Bugcheck code: 0x101 (0x61, 0x0, 0xFFFFF880009E6180, 0x1)
Error: CLOCK_WATCHDOG_TIMEOUT
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval. 
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. This problem might be caused by a thermal issue. 
The crash took place in the Windows kernel. Possibly this problem is caused by another driver which cannot be identified at this time. 


On Sun 12/18/2011 6:21:54 AM GMT your computer crashed
crash dump file: C:\Windows\Minidump\121811-34835-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x7CC40) 
Bugcheck code: 0x101 (0x61, 0x0, 0xFFFFF880009E6180, 0x1)
Error: CLOCK_WATCHDOG_TIMEOUT
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval. 
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. This problem might be caused by a thermal issue. 
The crash took place in the Windows kernel. Possibly this problem is caused by another driver which cannot be identified at this time. 


On Sun 12/18/2011 12:41:43 AM GMT your computer crashed
crash dump file: C:\Windows\Minidump\121711-35459-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x7CC40) 
Bugcheck code: 0x101 (0x61, 0x0, 0xFFFFF880009E6180, 0x1)
Error: CLOCK_WATCHDOG_TIMEOUT
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval. 
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. This problem might be caused by a thermal issue. 
The crash took place in the Windows kernel. Possibly this problem is caused by another driver which cannot be identified at this time. 


On Tue 12/13/2011 11:20:19 PM GMT your computer crashed
crash dump file: C:\Windows\Minidump\121311-41667-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x7CC40) 
Bugcheck code: 0x101 (0x61, 0x0, 0xFFFFF880009E6180, 0x1)
Error: CLOCK_WATCHDOG_TIMEOUT
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval. 
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem. This problem might be caused by a thermal issue. 
The crash took place in the Windows kernel. Possibly this problem is caused by another driver which cannot be identified at this time.
```
Ive also attached the 7 minidumps to this post. Help me out please 
Thanks in advance


----------



## loda117 (Aug 6, 2010)

Vista - Press Win+Pause, click advanced system settings, under the startup and recovery box, click settings, under the write debugger information box, change the selection from small memory dump to kernel memory dump.

When you BSOD again 
get the latest dump file and post here


----------



## Kedama (Dec 22, 2011)

loda117 said:


> Vista - Press Win+Pause, click advanced system settings, under the startup and recovery box, click settings, under the write debugger information box, change the selection from small memory dump to kernel memory dump.
> 
> When you BSOD again
> get the latest dump file and post here


Its already set to kernal memory dump and has always been. I posted the minidumps because the normal dump is 400MB


----------



## loda117 (Aug 6, 2010)

Lets run driver verifier to see what information we get 

http://www.techsupportforum.com/for...-windows-7-and-vista-bsod-related-473665.html


----------



## Kedama (Dec 22, 2011)

loda117 said:


> Lets run driver verifier to see what information we get
> 
> http://www.techsupportforum.com/for...-windows-7-and-vista-bsod-related-473665.html


Is this what you wanted me to obtain?
Computer didnt BSOD on restart

```
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Kevin Martinez>verifier /query
12/22/2011, 5:07:48 PM
Level: 0000092B
RaiseIrqls: 0
AcquireSpinLocks: 0
SynchronizeExecutions: 67
AllocationsAttempted: 5485
AllocationsSucceeded: 5485
AllocationsSucceededSpecialPool: 5485
AllocationsWithNoTag: 0
AllocationsFailed: 0
AllocationsFailedDeliberately: 0
Trims: 18367
UnTrackedPool: 0

Verified drivers:

Name: amdsbs.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 0
PeakPagedPoolAllocations: 0
PeakNonPagedPoolAllocations: 0
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 0
PeakPagedPoolUsageInBytes: 0
PeakNonPagedPoolUsageInBytes: 0

Name: amdxata.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 0
PeakPagedPoolAllocations: 0
PeakNonPagedPoolAllocations: 0
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 0
PeakPagedPoolUsageInBytes: 0
PeakNonPagedPoolUsageInBytes: 0

Name: avgrkx64.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 179
PeakPagedPoolAllocations: 1
PeakNonPagedPoolAllocations: 179
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 28980
PeakPagedPoolUsageInBytes: 14528
PeakNonPagedPoolUsageInBytes: 28980

Name: avgidseh.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 4
PeakPagedPoolAllocations: 0
PeakNonPagedPoolAllocations: 5
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 320
PeakPagedPoolUsageInBytes: 0
PeakNonPagedPoolUsageInBytes: 6384

Name: avgmfx64.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 5
CurrentNonPagedPoolAllocations: 8
PeakPagedPoolAllocations: 7
PeakNonPagedPoolAllocations: 12
PagedPoolUsageInBytes: 8892
NonPagedPoolUsageInBytes: 800
PeakPagedPoolUsageInBytes: 16060
PeakNonPagedPoolUsageInBytes: 1728

Name: serial.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 5
CurrentNonPagedPoolAllocations: 1
PeakPagedPoolAllocations: 7
PeakNonPagedPoolAllocations: 2
PagedPoolUsageInBytes: 256
NonPagedPoolUsageInBytes: 32
PeakPagedPoolUsageInBytes: 1088
PeakNonPagedPoolUsageInBytes: 4144

Name: avgldx64.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 165
CurrentNonPagedPoolAllocations: 18
PeakPagedPoolAllocations: 190
PeakNonPagedPoolAllocations: 21
PagedPoolUsageInBytes: 26420
NonPagedPoolUsageInBytes: 2216
PeakPagedPoolUsageInBytes: 82040
PeakNonPagedPoolUsageInBytes: 6392

Name: gearaspiwdm.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 0
PeakPagedPoolAllocations: 2
PeakNonPagedPoolAllocations: 1
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 0
PeakPagedPoolUsageInBytes: 248
PeakNonPagedPoolUsageInBytes: 136

Name: lvuvc64.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 179
PeakPagedPoolAllocations: 2
PeakNonPagedPoolAllocations: 233
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 356608
PeakPagedPoolUsageInBytes: 128
PeakNonPagedPoolUsageInBytes: 375544

Name: lvrs64.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 92
PeakPagedPoolAllocations: 2
PeakNonPagedPoolAllocations: 94
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 234836
PeakPagedPoolUsageInBytes: 64
PeakNonPagedPoolUsageInBytes: 235216

Name: dump_diskdump.sys, loads: 0, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 0
PeakPagedPoolAllocations: 0
PeakNonPagedPoolAllocations: 0
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 0
PeakPagedPoolUsageInBytes: 0
PeakNonPagedPoolUsageInBytes: 0

Name: dump_amdsbs.sys, loads: 2, unloads: 1
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 0
PeakPagedPoolAllocations: 0
PeakNonPagedPoolAllocations: 0
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 0
PeakPagedPoolUsageInBytes: 0
PeakNonPagedPoolUsageInBytes: 0

Name: dump_dumpfve.sys, loads: 2, unloads: 1
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 1
PeakPagedPoolAllocations: 0
PeakNonPagedPoolAllocations: 1
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 16400
PeakPagedPoolUsageInBytes: 0
PeakNonPagedPoolUsageInBytes: 16400

Name: aoddriver2.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 0
CurrentNonPagedPoolAllocations: 17
PeakPagedPoolAllocations: 2
PeakNonPagedPoolAllocations: 18
PagedPoolUsageInBytes: 0
NonPagedPoolUsageInBytes: 25672
PeakPagedPoolUsageInBytes: 108
PeakNonPagedPoolUsageInBytes: 25848

Name: secdrv.sys, loads: 1, unloads: 0
CurrentPagedPoolAllocations: 1
CurrentNonPagedPoolAllocations: 0
PeakPagedPoolAllocations: 3
PeakNonPagedPoolAllocations: 0
PagedPoolUsageInBytes: 72
NonPagedPoolUsageInBytes: 0
PeakPagedPoolUsageInBytes: 316
PeakNonPagedPoolUsageInBytes: 0

C:\Users\Kevin Martinez>
```


----------



## loda117 (Aug 6, 2010)

go to c:\windows\minidump folder and post the files from there

Also, 
Download the latest Drivers from your computer manufacturer's website 
including the chipset drivers the first thing 
Uninstall your current drivers 
Reboot
Install the latest drivers 
Reboot 

is your system by any chance over clocked?


----------



## Kedama (Dec 22, 2011)

loda117 said:


> go to c:\windows\minidump folder and post the files from there


I already have, they're all included in the .rar attached to my first post


----------



## loda117 (Aug 6, 2010)

see the issue is that they are pointing it all to "unknown_image" 
which is making it very difficult to debug the issue


----------



## VirGnarus (Jun 28, 2010)

Kedama, Driver Verifier is designed to crash the PC as it provides special checks for Windows to determine if there's a buggy driver and stop it in its tracks quickly. This will create crashdumps, which we would especially like, since they are more capable of providing us the info we need than a non-DV-activated crash.

However, I'm afraid that may not help us here. In order to diagnose 0x101 bugchecks, we'll need at least that kernel dump you got with you (the 400 MB monster). While it will dramatically shrink when archived, it still will be too big for this site, and you'll need to upload it to a 3rd-party file-sharing site for us to have access to it.


----------



## Kedama (Dec 22, 2011)

VirGnarus said:


> Kedama, Driver Verifier is designed to crash the PC as it provides special checks for Windows to determine if there's a buggy driver and stop it in its tracks quickly. This will create crashdumps, which we would especially like, since they are more capable of providing us the info we need than a non-DV-activated crash.
> 
> However, I'm afraid that may not help us here. In order to diagnose 0x101 bugchecks, we'll need at least that kernel dump you got with you (the 400 MB monster). While it will dramatically shrink when archived, it still will be too big for this site, and you'll need to upload it to a 3rd-party file-sharing site for us to have access to it.


Alright, managed to compress it down to 50mb and uploaded to Mediafire. Heres the link:
MEMORY.rar


----------



## VirGnarus (Jun 28, 2010)

I received the dump file and am analyzing it right now. Any other analysts wanna dive in feel free. Note that it will take me a bit of time given that kernel debugging can be a rather thorough and intensive task, especially dealing with a kernel dump. Plus with the whole holidays thing going on I might not have that much time to dabble in it in the next couple of days. Sure enough though, I'm getting to it.


----------



## VirGnarus (Jun 28, 2010)

Initial inspection so far displays the Nvidia drivers being involved in the thread that was running on the hanging processor core. They are dated Oct 2011 which isn't that old, but I'm not sure they're the newest either. Check for any updates. Again, this is just initial inspection, I'm still diving further into it.


----------



## Kedama (Dec 22, 2011)

VirGnarus said:


> Initial inspection so far displays the Nvidia drivers being involved in the thread that was running on the hanging processor core. They are dated Oct 2011 which isn't that old, but I'm not sure they're the newest either. Check for any updates. Again, this is just initial inspection, I'm still diving further into it.


Just checked, my drivers are the newest ones (Aside from beta drivers)

It is worth noting that my video card drivers crash quite often and have been doing so for at least a year. They don't cause a BSOD and simply cause the screen to flash for 3 seconds and then recovery.


----------



## VirGnarus (Jun 28, 2010)

That's caused by TDR failures. It means your video card or the drivers themselves failed to respond to the Windows kernel (specifically DirectX) within a designated time frame, and Windows responded by reinitializing your video drivers. This may be related to the 0x101 bugcheck, as if the video driver code involves an IPI (inter-processor interrupt, where one processor interrupts another one) then it would explain why the driver (or card itself) freezing up a bit would cause the 0x101 bugchecks. Because I'm actually seeing Nvidia drivers being responsible for the 0x101 bugcheck, this looks very well like the case.

If rolling back drivers isn't resolving the problem, and if you seem to have the latest drivers and that doesn't appear to work, we may be looking at unstable hardware. Of course first thing's first: if you have your GPU overclocked, reset to factory defaults. Once that is done, verify stability. If it's still unstable, or you never did overclock your video card, then perform the following tests (courtesy of Usasma):



> *More Video Stress Tests:*
> 1. Thanks to VirGnarus for finding this test: [email protected] - DownloadUtils
> 2. Two other video stress tests (may be more stressful than FurMark):
> NOTE: I have had reports that some ISP's will block this website
> ...


I'm personally not familiar with the 2 Russian tests, though I do believe one of them exists in the UBCD so I might end up being more familiar with them than I realize. As for the first test listed (MemtestG80/CL), note that either or both tests may not work for all GPUs, only those which support the API code it uses (OpenCL). Understand that these diagnostic tests may or may not reveal problems. If they do, you can bet this isn't a driver issue and it's hardware based. If they don't, don't use that as conclusive evidence that we aren't dealing with hardware issues.


----------



## VirGnarus (Jun 28, 2010)

To add, you may also check the article here. This gives a list of causes for TDR, as well as additional diagnostic tests you can do and any possible remedies (provided this isn't a hardware failure).


----------



## Kedama (Dec 22, 2011)

VirGnarus said:


> To add, you may also check the article here. This gives a list of causes for TDR, as well as additional diagnostic tests you can do and any possible remedies (provided this isn't a hardware failure).


Ive stressed the living hell out of my GPU before, its pretty stable. It held its own at 90c for 3 hours without crashing (Fur mark). Im fairly sure hardware isnt to blame, havent made any changes to it. 

I did have my case open for a long time and its summer here, i had a few occurances of bugs flying into my case and getting hit by fans, but not sure if that affected anything. Ima look through the components later to see if theres a bug messing something up, seems unlikely though. 

Ima do a full system format and reinstall after new years, if I still have these crash issues, ill post here again. I havent had any crashes the last few days strangely


Thanks for all your help


----------



## VirGnarus (Jun 28, 2010)

While GPUs can handle heat better than CPUs due to their architectural design, at 90c that's still putting some hurtin on the GPU and can easily degrade the life. It may very well be that stressing it with such temperatures has shortened its lifespan, and now it's failing to operate properly. Also, when did you stress test the GPU? 

I've been trying to scrutinize the kernel dump you gave me but it's looking like it may be beyond my current expertise. I'm having difficult reconstructing the faulting stack, and I haven't even reached the disassembly portion of my journey yet. As a result, all I can figure so far is that it involves DirectX, NVidia, and dealing with hardware rendering updates. Though I can't see how that would prevent an IPI (unless, of course, the GPU or CPU core was frozen). I'm still making an effort to figure it out, but I'm diving into some heavy stuff, and I'm not sure if it's even worth it venturing further, despite my curiosity.


----------



## Kedama (Dec 22, 2011)

VirGnarus said:


> While GPUs can handle heat better than CPUs due to their architectural design, at 90c that's still putting some hurtin on the GPU and can easily degrade the life. It may very well be that stressing it with such temperatures has shortened its lifespan, and now it's failing to operate properly. Also, when did you stress test the GPU?
> 
> I've been trying to scrutinize the kernel dump you gave me but it's looking like it may be beyond my current expertise. I'm having difficult reconstructing the faulting stack, and I haven't even reached the disassembly portion of my journey yet. As a result, all I can figure so far is that it involves DirectX, NVidia, and dealing with hardware rendering updates. Though I can't see how that would prevent an IPI (unless, of course, the GPU or CPU core was frozen). I'm still making an effort to figure it out, but I'm diving into some heavy stuff, and I'm not sure if it's even worth it venturing further, despite my curiosity.


Yeah, it doesn't usually reach 90c, only with furmark. I stress tested it over a year ago.

Heh, its cool, I appreciate your work. You're welcome to keep delving out of curiosity and personal knowledge, but don't bang your head on the wall for me


----------

