BSOD secondary processor clock interrupt - Windows 7 x64
- Thread starter DotFooz
- Start date
Sorry, I should probably learn to read.
Would you mind please uploading that kernel-dump to Onedrive, and all future kernels (if need be) there? Dropbox is very strange for me. Either I download at FiOS speeds, or it takes (as it says right now).... 7 hours to download a 1GB file. Strange.
Regards,
Patrick
Would you mind please uploading that kernel-dump to Onedrive, and all future kernels (if need be) there? Dropbox is very strange for me. Either I download at FiOS speeds, or it takes (as it says right now).... 7 hours to download a 1GB file. Strange.
Regards,
Patrick
OneDrive Link: http://1drv.ms/1jUl6Xq
Thanks a lot.
It appears at the time of the bug check, the thread was executing a pause (a CPU delay), while waiting for a response from the other processors for nt!KeFlushProcessWriteBuffers. This routine flushes the write queue of each processor that is running a thread of the current process.
If we look at processor #1:
So it looks like processor #1 is just doing its job at the time of the crash, nothing fishy.
If we look at processor #2:
Processor #2 looks like it was in the process of flushing a Translation lookaside buffer (TLB) cache.
If we look at processor #3:
Sleeping.
#4 also sleeping.
Processor #6 sleeping as well.
Right, so #7 is doing the same as #6, which is (at the time of the crash) flushing the write queue of each processor that is running a thread of the current process.
Honestly, this seems like hardware, but I am not yet convinced just yet. I want to be sure we don't have a low-level driver causing this problem.
With that said, before I call faulty hardware (processor if anything), please enable Driver Verifier:
Driver Verifier:
What is Driver Verifier?
Driver Verifier is included in Windows 8/8.1, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.
Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.
Before enabling Driver Verifier, it is recommended to create a System Restore Point:
Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8/8.1 - Restore Point - Create in Windows 8
How to enable Driver Verifier:
Start > type "verifier" without the quotes > Select the following options -
1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.
Important information regarding Driver Verifier:
- If Driver Verifier finds a violation, the system will BSOD. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls, causing memory leaks, etc. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled, it is monitoring all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur.
- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will detect it in violation almost straight away, and as stated above, that will cause / force a BSOD.
If this happens, do not panic, do the following:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > Search > type "cmd" without the quotes.
- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・ Restart and boot into normal Windows.
If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > type "system restore" without the quotes.
- Choose the restore point you created earlier.
-- Note that Safe Mode for Windows 8/8.1 is a bit different, and you may need to try different methods: 5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1
How long should I keep Driver Verifier enabled for?
I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer.
My system BSOD'd with Driver Verifier enabled, where can I find the crash dumps?
They will be located in %systemroot%\Minidump
Any other questions can most likely be answered by this article:
Using Driver Verifier to identify issues with Windows drivers for advanced users
Regards,
Patrick
Code:
0: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`04648328 fffff800`0531aa4a : 00000000`00000101 00000000`00000019 00000000`00000000 fffff880`009ea180 : nt!KeBugCheckEx
fffff880`04648330 fffff800`052cd6f7 : 00000000`00000000 fffff800`00000001 00000000`00002711 fffff880`04648450 : nt! ?? ::FNODOBFM::`string'+0x4e3e
fffff880`046483c0 fffff800`0520f895 : fffff800`05235460 fffff880`04648570 fffff800`05235460 00000000`00000000 : nt!KeUpdateSystemTime+0x377
fffff880`046484c0 fffff800`052c0113 : fffff800`0543ee80 00000000`00000001 00000000`00000001 fffff800`0524e000 : hal!HalpHpetClockInterrupt+0x8d
fffff880`046484f0 fffff800`05298939 : fffffa80`12b38b30 00000000`00000000 fffff800`052cdaa5 00000000`000406f8 : nt!KiInterruptDispatchNoLock+0x163 (TrapFrame @ [COLOR=#ff0000]fffff880`046484f0[/COLOR])
fffff880`04648680 fffff800`055ced4f : 00000000`00000000 fffff880`04648b60 00000000`00000000 00001f80`00000200 : nt!KeFlushProcessWriteBuffers+0x65
fffff880`046486f0 fffff800`055cf3ad : 00000000`00346a20 fffff800`055b9cce 00000000`00000000 fffff800`052c2e62 : nt!ExpQuerySystemInformation+0x13af
fffff880`04648aa0 fffff800`052c2e53 : 00000000`00000000 fffff880`04648b60 ffffffff`fffe7960 000007fe`fbde0b48 : nt!NtQuerySystemInformation+0x4d
fffff880`04648ae0 00000000`7716161a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`04648ae0)
00000000`0051f268 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7716161a
Code:
0: kd> .trap fffff880`046484f0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=0000000000000206
rdx=00000000000c00e1 rsi=0000000000000000 rdi=0000000000000000
[COLOR=#ff0000]rip=fffff80005298939[/COLOR] rsp=fffff88004648680 rbp=0000000000000000
r8=00000000000000e1 r9=0000000000000001 r10=0000000000000000
r11=fffff88003789180 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
[COLOR=#4b0082]nt!KeFlushProcessWriteBuffers+0x65:[/COLOR]
[COLOR=#ff0000]fffff800`05298939[/COLOR] 8b8380200000 mov eax,dword ptr [rbx+2080h] ds:00000000`00002080=????????
Code:
0: kd> u @rip
nt!KeFlushProcessWriteBuffers+0x65:
fffff800`05298939 8b8380200000 mov eax,dword ptr [rbx+2080h]
fffff800`0529893f 3bc5 cmp eax,ebp
fffff800`05298941 75f4 [COLOR=#ff0000]jne[/COLOR] [COLOR=#ff0000]nt!KeFlushProcessWriteBuffers+0x63 (fffff800`05298937)[/COLOR] [COLOR=#4b0082]<--- Jump if not zero.[/COLOR]
[COLOR=#ff0000]fffff800`05298943[/COLOR] 400fb6c6 movzx eax,sil
fffff800`05298947 440f22c0 mov cr8,rax
fffff800`0529894b 4c8d5c2460 lea r11,[rsp+60h]
fffff800`05298950 498b5b10 mov rbx,qword ptr [r11+10h]
fffff800`05298954 498b6b18 mov rbp,qword ptr [r11+18h]
Code:
0: kd> u fffff800`05298937 fffff800`05298943
nt!KeFlushProcessWriteBuffers+0x63:
fffff800`05298937 f390 [COLOR=#006400]pause[/COLOR]
fffff800`05298939 8b8380200000 mov eax,dword ptr [rbx+2080h]
fffff800`0529893f 3bc5 cmp eax,ebp
fffff800`05298941 75f4 [COLOR=#ff0000]jne[/COLOR] [COLOR=#ff0000]nt!KeFlushProcessWriteBuffers+0x63 (fffff800`05298937)[/COLOR]
fffff800`05298943 400fb6c6 movzx eax,silIt appears at the time of the bug check, the thread was executing a pause (a CPU delay), while waiting for a response from the other processors for nt!KeFlushProcessWriteBuffers. This routine flushes the write queue of each processor that is running a thread of the current process.
If we look at processor #1:
Code:
1: kd> k
Child-SP RetAddr Call Site
fffff880`02d71418 fffff800`0520cae7 hal!HalpLegacyApicReadGenericReg+0xd [COLOR=#4b0082]<--- ???[/COLOR]
fffff880`02d71420 fffff800`052b57f3 hal!HalRequestSoftwareInterrupt+0x58 [COLOR=#4b0082]<--- Hardware Abstraction Layer requests a software interrupt.[/COLOR]
fffff880`02d71450 fffff800`052a46a4 nt!KiInsertQueueApc+0x243 [COLOR=#4b0082]<--- Still waiting in queue.[/COLOR]
fffff880`02d71480 fffff800`052d8afc nt!KeInsertQueueApc+0x80 [COLOR=#4b0082]<--- Inserting the APC to a queue.[/COLOR]
fffff880`02d714e0 fffff800`052b65f7 nt!IopCompleteRequest+0xb8c [COLOR=#4b0082]<--- Indicating that the caller has completed all processing for a given I/O request and is returning the given IRP to the I/O manager.[/COLOR]
fffff880`02d715b0 fffff800`052b97fd nt!KiDeliverApc+0x1c7 [COLOR=#4b0082]<--- Calling [B]nt!KiDeliverApc[/B] to deliver APC(s) to the thread.[/COLOR]
fffff880`02d71630 fffff800`052c60ea nt!KiCommitThreadWait+0x3dd [COLOR=#4b0082]<--- Comitting a thread wait.[/COLOR]
fffff880`02d716c0 fffff960`0012a6a0 nt!KeWaitForMultipleObjects+0x272 [COLOR=#4b0082]<--- Waiting.[/COLOR]
fffff880`02d71980 fffff960`0012b663 win32k!xxxMsgWaitForMultipleObjects+0x108 [COLOR=#4b0082]<--- Call to note waiting for multiple objects.[/COLOR]
fffff880`02d71a00 fffff960`000e5084 win32k!xxxDesktopThread+0x253 [COLOR=#4b0082]<--- Specifically we're creating a Desktop thread.[/COLOR]
fffff880`02d71a80 fffff960`0016619a win32k!xxxCreateSystemThreads+0x64 [COLOR=#4b0082]<--- Evidently it's a call to create a system thread.[/COLOR]
fffff880`02d71ab0 fffff800`052c2e53 win32k!NtUserCallNoParam+0x36 [COLOR=#4b0082]<--- We have a user call.[/COLOR]
fffff880`02d71ae0 000007fe`fcee1eea nt!KiSystemServiceCopyEnd+0x13
00000000`03f1f938 00000000`00000000 0x000007fe`fcee1eeaSo it looks like processor #1 is just doing its job at the time of the crash, nothing fishy.
If we look at processor #2:
Code:
2: kd> k
Child-SP RetAddr Call Site
fffff880`009a9980 fffff800`052c8a1c [COLOR=#ff0000]nt!KxFlushEntireTb+0x7f[/COLOR]
fffff880`009a99c0 fffff800`052866e9 [COLOR=#ff0000]nt!KeFlushMultipleRangeTb+0x28c[/COLOR]
fffff880`009a9a90 fffff800`05286f37 nt!MiZeroPageChain+0x14e
fffff880`009a9ad0 fffff800`055602ea nt!MmZeroPageThread+0x83a
fffff880`009a9c00 fffff800`052b48e6 nt!PspSystemThreadStartup+0x5a
fffff880`009a9c40 00000000`00000000 nt!KxStartSystemThread+0x16Processor #2 looks like it was in the process of flushing a Translation lookaside buffer (TLB) cache.
If we look at processor #3:
Code:
3: kd> k
Child-SP RetAddr Call Site
fffff880`035ffb58 fffff800`052cc709 [COLOR=#ff0000]intelppm!MWaitIdle+0x19[/COLOR]
fffff880`035ffb60 fffff800`052bb89c nt!PoIdle+0x52a
fffff880`035ffc40 00000000`00000000 nt!KiIdleLoop+0x2cSleeping.
Code:
4: kd> k
Child-SP RetAddr Call Site
fffff880`0365bb58 fffff800`052cc709 [COLOR=#ff0000]intelppm!MWaitIdle+0x19[/COLOR]
fffff880`0365bb60 fffff800`052bb89c nt!PoIdle+0x52a
fffff880`0365bc40 00000000`00000000 nt!KiIdleLoop+0x2c#4 also sleeping.
Code:
5: kd> k
Child-SP RetAddr Call Site
fffff880`0b46b3a0 fffff800`052e3251 nt!KeFlushMultipleRangeTb+0x266 [COLOR=#4b0082]<--- Flushing TLB.[/COLOR]
fffff880`0b46b470 fffff800`052e5c98 nt!MiFlushTbAsNeeded+0x1d1 [COLOR=#4b0082]<--- See above.[/COLOR]
fffff880`0b46b580 fffff800`053f4f86 nt!MiAllocatePagedPoolPages+0x4cc [COLOR=#4b0082]<--- Allocating the paged pool pages.[/COLOR]
fffff880`0b46b6a0 fffff800`052e39b0 nt!MiAllocatePoolPages+0x906 [COLOR=#4b0082]<--- Allocating the pool pages.[/COLOR]
fffff880`0b46b7e0 fffff800`053f843e nt!ExpAllocateBigPool+0xb0 [COLOR=#4b0082]<--- This function being called implies that it's allocating a pool allocation larger than 4096 bytes.[/COLOR]
fffff880`0b46b8d0 fffff800`052d6f56 nt!ExAllocatePoolWithTag+0x82e [COLOR=#4b0082]<--- Allocating pool memory of the specified type and returns a pointer to the allocated block.[/COLOR]
fffff880`0b46b9c0 fffff800`05530b36 nt!ExAllocatePoolWithQuotaTag+0x56 [COLOR=#4b0082]<--- Allocating pool memory, charging the quota against the current process.[/COLOR]
fffff880`0b46ba10 fffff800`05586c94 nt!PiControlGetInterfaceDeviceList+0x92
fffff880`0b46ba90 fffff800`052c2e53 nt!NtPlugPlayControl+0x100
fffff880`0b46bae0 00000000`7716230a nt!KiSystemServiceCopyEnd+0x13
00000000`0119eb58 00000000`00000000 0x7716230a
Code:
6: kd> k
Child-SP RetAddr Call Site
fffff880`0373fb58 fffff800`052cc709 [COLOR=#ff0000]intelppm!MWaitIdle+0x19[/COLOR]
fffff880`0373fb60 fffff800`052bb89c nt!PoIdle+0x52a
fffff880`0373fc40 00000000`00000000 nt!KiIdleLoop+0x2cProcessor #6 sleeping as well.
Code:
7: kd> k
Child-SP RetAddr Call Site
fffff880`08d25530 fffff800`0558034f [COLOR=#ff0000]nt!KeFlushProcessWriteBuffers+0x6b[/COLOR]
fffff880`08d255a0 fffff800`055ce956 nt!ExpGetProcessInformation+0x7f
fffff880`08d256f0 fffff800`055cf3ad nt!ExpQuerySystemInformation+0xfb4
fffff880`08d25aa0 fffff800`052c2e53 nt!NtQuerySystemInformation+0x4d
fffff880`08d25ae0 00000000`7716161a nt!KiSystemServiceCopyEnd+0x13
00000000`0213e708 00000000`00000000 0x7716161aRight, so #7 is doing the same as #6, which is (at the time of the crash) flushing the write queue of each processor that is running a thread of the current process.
Honestly, this seems like hardware, but I am not yet convinced just yet. I want to be sure we don't have a low-level driver causing this problem.
With that said, before I call faulty hardware (processor if anything), please enable Driver Verifier:
Driver Verifier:
What is Driver Verifier?
Driver Verifier is included in Windows 8/8.1, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.
Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.
Before enabling Driver Verifier, it is recommended to create a System Restore Point:
Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8/8.1 - Restore Point - Create in Windows 8
How to enable Driver Verifier:
Start > type "verifier" without the quotes > Select the following options -
1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.
Important information regarding Driver Verifier:
- If Driver Verifier finds a violation, the system will BSOD. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls, causing memory leaks, etc. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled, it is monitoring all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur.
- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will detect it in violation almost straight away, and as stated above, that will cause / force a BSOD.
If this happens, do not panic, do the following:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > Search > type "cmd" without the quotes.
- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・ Restart and boot into normal Windows.
If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > type "system restore" without the quotes.
- Choose the restore point you created earlier.
-- Note that Safe Mode for Windows 8/8.1 is a bit different, and you may need to try different methods: 5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1
How long should I keep Driver Verifier enabled for?
I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer.
My system BSOD'd with Driver Verifier enabled, where can I find the crash dumps?
They will be located in %systemroot%\Minidump
Any other questions can most likely be answered by this article:
Using Driver Verifier to identify issues with Windows drivers for advanced users
Regards,
Patrick
Looks like you're on to something here
Here's a minidump that was created from it: http://1drv.ms/1fH4ama
Read More:
Here's a minidump that was created from it: http://1drv.ms/1fH4ama
Very interesting, this specific dump is a kernel triage dump. Essentially, this dump is a 'snapshot' of a given process and its active user mode threads. We cannot switch processors or anything, since it's technically not a full kernel dump.
Your screenshot was extremely helpful, because it shows the 0xC000000E status code. 0xC000000E, or STATUS_NO_SUCH_DEVICE, indicates a hardware failure (usually HDD) or an incorrect drive configuration. Can you please go ahead and double check all SATA connections from the board/to the drive itself? If connections check out, please run Chkdsk (paste log afterwards) and then Seatools:
Chkdsk:
There are various ways to run Chkdsk~
Method 1:
Start > Search bar > Type cmd (right click run as admin to execute Elevated CMD)
Elevated CMD should now be opened, type the following:
chkdsk x: /r
x implies your drive letter, so if your hard drive in question is letter c, it would be:
chkdsk c: /r
Restart system and let chkdsk run.
Method 2:
Open the "Computer" window
Right-click on the drive in question
Select the "Tools" tab
In the Error-checking area, click <Check Now>.
If you'd like to get a log file that contains the chkdsk results, do the following:
Press Windows Key + R and type powershell.exe in the run box
Paste the following command and press enter afterwards:
get-winevent -FilterHashTable @{logname="Application"; id="1001"}| ?{$_.providername –match "wininit"} | fl timecreated, message | out-file Desktop\CHKDSKResults.txt
This will output a .txt file on your Desktop containing the results of the chkdsk.
If chkdsk turns out okay, run Seatools -
SeaTools | Seagate
You can run it via Windows or DOS. Do note that the only difference is simply the environment you're running it in. In Windows, if you are having what you believe to be device driver related issues that may cause conflicts or false positive, it may be a wise decision to choose the most minimal testing environment (DOS).
Run all tests EXCEPT: Fix All and anything Advanced.
Regards,
Patrick
Your screenshot was extremely helpful, because it shows the 0xC000000E status code. 0xC000000E, or STATUS_NO_SUCH_DEVICE, indicates a hardware failure (usually HDD) or an incorrect drive configuration. Can you please go ahead and double check all SATA connections from the board/to the drive itself? If connections check out, please run Chkdsk (paste log afterwards) and then Seatools:
Chkdsk:
There are various ways to run Chkdsk~
Method 1:
Start > Search bar > Type cmd (right click run as admin to execute Elevated CMD)
Elevated CMD should now be opened, type the following:
chkdsk x: /r
x implies your drive letter, so if your hard drive in question is letter c, it would be:
chkdsk c: /r
Restart system and let chkdsk run.
Method 2:
Open the "Computer" window
Right-click on the drive in question
Select the "Tools" tab
In the Error-checking area, click <Check Now>.
If you'd like to get a log file that contains the chkdsk results, do the following:
Press Windows Key + R and type powershell.exe in the run box
Paste the following command and press enter afterwards:
get-winevent -FilterHashTable @{logname="Application"; id="1001"}| ?{$_.providername –match "wininit"} | fl timecreated, message | out-file Desktop\CHKDSKResults.txt
This will output a .txt file on your Desktop containing the results of the chkdsk.
If chkdsk turns out okay, run Seatools -
SeaTools | Seagate
You can run it via Windows or DOS. Do note that the only difference is simply the environment you're running it in. In Windows, if you are having what you believe to be device driver related issues that may cause conflicts or false positive, it may be a wise decision to choose the most minimal testing environment (DOS).
Run all tests EXCEPT: Fix All and anything Advanced.
Regards,
Patrick
Not sure entirely what happened to it. But yeah there was definitely something wrong with the C drive.
Here's a link: http://1drv.ms/1k5BBjt
Here's a link: http://1drv.ms/1k5BBjt
Has Sysnative Forums helped you? Please consider donating to help us support the site!