[SOLVED] Recurrent BSODs (every 1-2 days) clock interrupt

rockstream

Member
Joined
Aug 20, 2013
Posts
20
I have been getting random recurrent BSODs, mostly when I am doing various tasks, but occasionally at night--it is not easily reproduced. They occur about every 24-48 hours but frequency can be shorter or longer.

I built this computer in May 2011 with Windows 7 Ult 64bit OEM (which I purchased and installed). Reinstalled OS about 2-3 months ago and then moved system to SSD. Additional external HD attached using separate SSD as cache.
ASRock Z68 Extreme4 MB
Intel 2500k CPU w Integrated Graphics only
850W Corsair PSU

I ran this computer overclocked stable for years. Since the BSOD I have removed overclocking, all BIOS entries as default now.

Thank you for your help. Please let me know what additional information you need.
 
Hi,

All of the attached DMP files are of the CLOCK_WATCHDOG_TIMEOUT (101) bugcheck.

An expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval. This can occurs when the processor is not responding or is deadlocked.


We won't be able to get too much info in regards to this bugcheck without at least a Kernel Memory Dump.

FADA64.sys - Thu Apr 24 14:03:39 2003 - Frame Access Driver from Broadcom. Either find an update for this driver or remove ASAP.

inpoutx64.sys Fri Oct 17 19:01:16 2008 - DLL and driver for direct access to hardware ports. Check for an update here - http://www.highrez.co.uk/Downloads/InpOut32/default.htm

or remove for troubleshooting purposes.

^^ Possible culprit the more I think about it now.

Regards,

Patrick
 
I was replying to the thread when another crash happened (I am assuming it did since I was remotely accessing the computer and now it's gone...). Thus, I will have to wait until I get home later today to be able to upload.

There was a C:\Windows\memory.dmp file about 700MB in size -- I think that is a full kernel dump -- I had opened it in WinDbg and the message stated something to that effect. Of course, it is probably now replaced with a new one based on the last crash. I was running Driver Verifier this time, fortunately.

Regarding the inpoutx64.sys driver, this refreshed my memory with the following potentially relevant info:

I purchased and installed a parallel port PCI card, probably around the time the crashes started, but I am not 100% sure. I removed it since, thinking it might be the culprit, but I still got BSOD after it was removed, so I ruled it out. Perhaps the drivers left behind during that installation could still be causing the problem even though the physical card is gone. More specifically, the reason I installed the card was to connect a special kind of adaptor called a JP1 cable used to program TV remotes. It turns out the JP1 software was not working correctly with a parallel port in Windows 7, so someone in the JP1 forum uploaded a new InpOut32.dll driver that fixed the problem. I downloaded and installed the driver, and it fixed it for me -- perhaps this is what started the BSODs. If it helps, the forum page where he describes the changes is:

JP1 Remotes :: View topic - Parallel Port JP1 on Win7-64bit?

What is the frame access driver for? Broadcom is probably the manufacturer of the NIC card so of course I wouldn't want to lose network connectivity.
 
For temporary troubleshooting purposes, I would recommend ruling out the parralel port driver entirely by removing the software and the device. Check %systemroot%\System32\Drivers afterwards to ensure the driver itself is not there.

In regards to the frame access, I honestly couldn't tell you if it's necessary to the functionality of the NIC. The driver is dated from 2003 though which is ancient, so I very much doubt it is. On AsRock's website, do you have the latest network drivers? If so, remove the frame access software for troubleshooting purposes as well.

I would also make a sys restore point before all of this, just in case - Windows 7 - START | type create | select "Create a Restore Point"

Is the SSD firmware up to date?

Regards,

Patrick
 
Ok it turns out that the last "crash" was actually a "freeze" and no BSOD, and thus no dump file was created. I have c:\Windows\memory.dmp file from earlier today, which based on its size I believe is a kernel dump. However, after compressing with zip, it is still 200MB+ in size. How do I upload such large files?

There is an SSD firmware update, but I will hold off on updating until I can rule out the other drivers as culprit.
 
Hi,

There is an SSD firmware update, but I will hold off on updating until I can rule out the other drivers as culprit.

I would recommend not holding off on an SSD updating and doing it ASAP. It will rule out many variables.

Especially because of -
Ok it turns out that the last "crash" was actually a "freeze" and no BSOD, and thus no dump file was created.

Regards,

Patrick
 
Ok, I'll update SSD firmware now. What about the kernel dump -- do you still need it, and if so how do I upload it?
 
No, let's hold off on the Kernel Memory Dump until after the SSD firmware is updated. If you crash again, you can upload the latest Kernel dump to a 3rd party hosting site such as - Mediafire, Skydrive, etc.

Regards,

Patrick
 
Ok, the SSD firmware is now up to date.

I am having trouble removing the 2 drivers that you mentioned earlier. Here is what I did:

1. At the command line, SET DEVMGR_SHOW_NONPRESENT_DEVICES=1

2. In Device Manager, set View->Show hidden device

3. Found both drivers, and right click->Uninstall

4. Device manager told me I needed to reboot, so I did, and afterwards the devices where still in Device Manager list and active

5. So then I selected each device again, then Right click->Properties->Driver tab. Then under current status I hit "Stop" and under startup I selected "Disabled"

Is this enough? Should I delete (or rename) the actual files in their locations? (one is in C:\windows\System32\drivers the other is in c:\Program Files\BACS)
 
Great work.

Yes, as the devices and software itself are disabled or uninstalled, renaming the actual .sys files to .old will not cause any issues as essentially they are not loading into anything for their functionality.

Regards,

Patrick
 
Done. Now I am running the system with Driver Verifier on and trying to do as much work as possible over the next few days to see if another crash occurs.
 
Hi,

As suspected, with verifier enabled we are now beginning to see iaStor.sys culprits. I wanted to make sure until it was listed as possible culprit until recommending anything. I also see iaStorV.sys listed and loaded in the modules list which is the Intel Matrix Storage Manager driver (base) (now is the Rapid Storage Technology (RST) driver).

Visit Asrock's website and ensure all of your storage related drivers are up to date. If they are, unless you are running a RAID config, you can actually go ahead and for troubleshooting purposes remove the Intel storage related software as it's not entirely necessary to the functionality of your system. Before doing so though, I'd recommend making a restore point -

Windows 7 - START | type create | select "Create a Restore Point"

Regards,

Patrick
 
I am using the RST in order to have the 60G Patriot SSD act as a cache for the external HDD. Originally when I built the computer I was using this combination as the primary boot drive, but now I have a separate 250G Samsung SSD as the boot drive, so from a performance perspective the 60G cache is much less critical. So for troubleshooting purposes I could remove the Patriot SSD from its "RAID" (cache) configuration (and leave it disconnected) and leave the external drive alone and then remove RST.

This also reminds me -- when I updated the SSD firmware earlier, I was only thinking about the Samsung SSD I am using as ther primary Windows drive and forgot about the Patriot cache SSD which might not be in its latest firmware. In any case, it is not possible to upgrade (or even detect) that SSD's firmware versoin as long as it is used as RST cache, so I will just remove it out the equation altogether and see whether I still get the crashes. FYI -- I got two crashes this morning close together while Driver Verifier was running, so I stopped it after I sent you the kernel dump to maintain some stability. I will restart it after I make the changes.
 
Thanks for the detailed reply!

Keep me updated after removing the Patriot SSD.

Regards,

Patrick
 
Here's what I did:

1. Went into RST settings and disabled the Patriot SSD cache acceleration
2. In BIOS, changed SATA controller setting from "RAID" to "AHCI"
3. Rebooted and uninstalled RST software
4. Rebooted successfully and, in Device Manager, disabled iastor and iastorv (after determining that the active AHCI driver was now the MS version, msahci.sys)
5. Renamed iastor.sys and iastorV.sys to .old
6. Restarted Driver Verifier settings
7. Physically disconnected the Patriot SSD from the system
8. Rebooted again

So now, RST is gone, iastor and iastorV are gone and the Patriot SSD is gone, so we will test again with driver verifier on.
 
Broadcom network driver k57nd60a.sys and Comodo firewall driver inspect.sys appear on the raw stack of the hung processor.

0: kd> lmvm k57nd60a
start end module name
fffff880`04d91000 fffff880`04df8000 k57nd60a (no symbols)
Loaded symbol image file: k57nd60a.sys
Image path: \SystemRoot\system32\DRIVERS\k57nd60a.sys
Image name: k57nd60a.sys
Timestamp: Tue Feb 15 06:19:05 2011 (4D59FEB9)
CheckSum: 00071F18
ImageSize: 00067000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4



0: kd> lmvm inspect
start end module name
fffff880`03ede000 fffff880`03ef8000 inspect (no symbols)
Loaded symbol image file: inspect.sys
Image path: \SystemRoot\system32\DRIVERS\inspect.sys
Image name: inspect.sys
Timestamp: Thu Nov 08 00:07:02 2012 (509ADB86)
CheckSum: 0001B900
ImageSize: 0001A000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top