Jump to content
RESET Forums (homeservershow.com)

DPC_WATCHDOG_VIOLATION coredump on Windows 8.1


msawyer91

Recommended Posts

My wife let me "borrow" her HP Envy desktop that I bought for her earlier this year. Having an MSDN subscription I wanted to try out the Windows 8.1 bits so I bought her a new iPad, and she let me take the desktop. It's been running Windows 8 since the day we got it.

 

I installed Windows 8.1 on a Kingston HyperX 128GB SSD, then reinstalled the original HDD. Windows OOB came with most drivers, while a few others were pulled down from Windows Update. The only one that needed some additional help was the AMD AHCI controller. Going out to HP's website for the h8-1534 model, I grabbed the latest AMD driver for the storage controller, which was released in February.

 

Everything ran great for several days, until this past Friday, when the PC was sitting at the Startup Repair screen. I rebooted it, and it ran fine for about a day, but then it blue screened again. And again yesterday, and once more this morning.

 

Each time I ran WinDbg x64, and each time the error is identical. The BSOD code is DPC_WATCHDOG_VIOLATION (0x133) and the four parameters are always the same (0x0, 0x500, 0x501, 0x0). The offending driver is storport.sys, in the storport!RaidAdapterAcquireInterruptLock+125e2 function. The problem is very consistent -- it always faults in the same function in the same spot.

 

Microsoft's explanation of the dump code is this: "The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL or above. A single DPC or ISR exceeded its time allotment. The offending component can usually be identified with a stack trace"

 

Normally I'm pretty good at troubleshooting, and resolving, coredumps. But this one I cannot seem to pin down.

 

I haven't yet installed antivirus software, so I can't point the finger there.

 

I loaded WindowSMART 2013, and the health of both the SSD and HDD is flawless. The UEFI diagnostics run against both the SSD and HDD also said the disks are in perfect health. Nevertheless I replaced the SATA cables for good measure, and yet the coredumps persist.

 

For those who salivate at the thought of coredumps, here's the contents from WinDbg.

 

Hopefully someone here has some insight.

Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Only kernel address space is available

Symbol search path is: symsrv*symsrv.dll*h:\WebSymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 8 Kernel Version 9600 MP (6 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.16384.amd64fre.winblue_rtm.130821-1623
Machine Name:
Kernel base = 0xfffff802`1fa72000 PsLoadedModuleList = 0xfffff802`1fd399b0
Debug session time: Sun Sep 29 23:56:33.642 2013 (UTC - 4:00)
System Uptime: 0 days 4:50:36.344
Loading Kernel Symbols
...............................................................
................................................................
............................................
Loading User Symbols

Loading unloaded module list
.............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 133, {0, 501, 500, 0}

Probably caused by : storport.sys ( storport!RaidAdapterAcquireInterruptLock+125e2 )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000000, A single DPC or ISR exceeded its time allotment. The offending
                component can usually be identified with a stack trace.
Arg2: 0000000000000501, The DPC time count (in ticks).
Arg3: 0000000000000500, The DPC time allotment (in ticks).
Arg4: 0000000000000000

Debugging Details:
------------------


DPC_TIMEOUT_TYPE:  SINGLE_DPC_TIMEOUT_EXCEEDED

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x133

PROCESS_NAME:  System

CURRENT_IRQL:  d

LAST_CONTROL_TRANSFER:  from fffff8021fbf1c82 to fffff8021fbc20a0

STACK_TEXT:  
fffff802`21c01c98 fffff802`1fbf1c82 : 00000000`00000133 00000000`00000000 00000000`00000501 00000000`00000500 : nt!KeBugCheckEx
fffff802`21c01ca0 fffff802`1faeeaec : 00000000`00000000 00000000`00000000 fffff802`21c01d90 00000000`00000001 : nt! ?? ::FNODOBFM::`string'+0x1f6f2
fffff802`21c01d30 fffff802`1fa09e5f : 00000000`00000000 00000000`00000001 00003c23`0c9bb348 00000000`00008101 : nt!KeClockInterruptNotify+0x77c
fffff802`21c01f40 fffff802`1fb07703 : fffff802`1fa56900 00000000`00000008 fffff802`21c01f50 00000000`00000010 : hal!HalpTimerClockInterrupt+0x4f
fffff802`21c01f70 fffff802`1fbc352a : fffff802`1fa56900 ffffe000`01e41db0 00000000`00000001 ffffe000`01e4c730 : nt!KiCallInterruptServiceRoutine+0xa3
fffff802`21c01fb0 fffff802`1fbc3e9b : fffff802`1fd14100 00000000`00000000 ffffe000`00000000 00001f80`00a00b0f : nt!KiInterruptSubDispatchNoLockNoEtw+0xea
fffff802`21bf2750 fffff802`1fb072e0 : 00000000`00000000 00000000`00010008 00000000`00000000 ffffe000`02e770f0 : nt!KiInterruptDispatchNoLockNoEtw+0xfb
fffff802`21bf28e0 fffff802`1fb07656 : 00000000`00000002 fffff802`1faf0eda fffff802`1fd63180 fffff802`1fd63180 : nt!KxWaitForSpinLockAndAcquire+0x20
fffff802`21bf2910 fffff800`00bb24a2 : fffff802`21bf2b10 00000028`8cf2100d 00000001`00000100 00000000`ffffffff : nt!KeAcquireInterruptSpinLock+0x3e
fffff802`21bf2950 fffff800`00ba311a : ffffe000`01e4c1a0 ffffe000`01e4c770 fffff802`1fd68580 00000000`00000002 : storport!RaidAdapterAcquireInterruptLock+0x125e2
fffff802`21bf2980 fffff802`1faf56e2 : fffff802`21bf2b20 fffff802`21bf2ae0 ffffe000`01e4c770 fffff802`1fd63180 : storport!RaidpAdapterTimerDpcRoutine+0xa2
fffff802`21bf29e0 fffff802`1fbc5bea : fffff802`1fd63180 fffff802`1fd63180 fffff802`1fdbba80 ffffe000`0199a080 : nt!KiRetireDpcList+0x6b2
fffff802`21bf2c60 00000000`00000000 : fffff802`21bf3000 fffff802`21bec000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND:  kb

FOLLOWUP_IP: 
storport!RaidAdapterAcquireInterruptLock+125e2
fffff800`00bb24a2 8ad8            mov     bl,al

SYMBOL_STACK_INDEX:  9

SYMBOL_NAME:  storport!RaidAdapterAcquireInterruptLock+125e2

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: storport

IMAGE_NAME:  storport.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  5215f857

BUCKET_ID_FUNC_OFFSET:  125e2

FAILURE_BUCKET_ID:  0x133_DPC_storport!RaidAdapterAcquireInterruptLock

BUCKET_ID:  0x133_DPC_storport!RaidAdapterAcquireInterruptLock

Followup: MachineOwner
---------
Link to post
Share on other sites
Drashna Jaelre

have you tried using the driver verifier stuff? That may help pinpoint exactly what's going on.

http://support.microsoft.com/kb/244617

 

Also, this link may be helpful for you:

http://answers.microsoft.com/en-us/windows/forum/windows_8-system/dpcwatchdogviolation-and-sporadic-crashing/404c438d-d424-4665-9bab-0bfd672cd26b

 

Otherwise, that's the SCSI-ish adapter. You said you updated the storage drivers. Does rolling back the drivers help at all?

Link to post
Share on other sites

I ran Driver Verifier, since the Windows SDK/DDK was already installed as part of my MSDN testing. I picked all of the AMD drivers (since the controller is AMD). Since the coredumps blame storport.sys, I chose that one as well. And, for good measure, I grabbed the Virtual Clone Drive driver, since that one is technically a storage driver. I wouldn't think that would cause a dump, since it's not actually being used.

 

Every time this machine has dumped, it's always been at an idle time. Of course that could be mere coincidence.

 

I can't seem to find anything in the event logs to correlate the problem to a specific event -- i.e. a specific job running. Crash Plan and Windows Server 2012 Essentials backups have both run successfully, so I can't point the finger at those.

 

I've never used Driver Verifier before -- I picked the drivers and then rebooted as it requested. The next time it dumps, will it give me a more detailed dump? What kind of output can I expect? I'm looking forward to the next dump because I'd really like to get to the bottom of this.

Link to post
Share on other sites
Drashna Jaelre

Honestly, I'm not really sure. I've only recently started to deal with the debugging tools, because my job requires it. 

 

Though, is that Virtual Clone Drive driver the built in ISO/VHD mounting driver? Or a 3rd party app? If it's a 3rd party one, I'd recommend uninstalling it. I used to have issues with one of those types of programs that causes BSODs. It could be the issue.

Link to post
Share on other sites
msawyer91

Honestly, I'm not really sure. I've only recently started to deal with the debugging tools, because my job requires it. 

 

Though, is that Virtual Clone Drive driver the built in ISO/VHD mounting driver? Or a 3rd party app? If it's a 3rd party one, I'd recommend uninstalling it. I used to have issues with one of those types of programs that causes BSODs. It could be the issue.

It's the Elby Virtual Clone Drive. It was available off of SlySoft's website. I like VCD better than Virtual CD because it can mount Blu-ray ISOs as well.

 

Nevertheless I googled it, and saw that Elby's own website had a newer version of the driver 5.4.7, dated in July 2013 (the version I had installed was dated March 2013). Needless to say I slurped down the newer version and rebooted for good measure.

 

Right now I just have Driver Verifier monitoring the AHCI driver and storport.sys. I'll start with baby steps--just monitor those two and take it from there.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...