msawyer91
New Member
- Messages
- 12
- Location
- United States
I'm normally pretty good at resolving BSODs but I've got one I can't quite solve. It occurs at least once a day, and it's the same BSOD with the same error code every time.
Having an MSDN subscription, I was eager to try out the Windows 8.1 RTM bits, so I asked my wife if I could borrow her HP Envy desktop for a few weeks--I bribed her with a brand new iPad so she let me take the desktop. The desktop shipped with Windows 8; in fact when you pull up the product page on HP the only OS listed as supported by HP is Windows 8 x64.
I installed a brand new Kingston HyperX 128GB SSD, installed Windows 8.1, and then reattached the original HDD. Windows detected most of the hardware, and for the items it didn't, it grabbed the drivers from Windows Update. The only one that needed manual intervention was the storage controller, so I grabbed the latest driver from the HP Support and Drivers page.
The machine ran fine for several days, until late last week it was sitting at the Startup Repair screen. I rebooted it, and it rebooted fine...but less than a day later, it was back at Startup Repair.
After each of these episodes, I fired up WinDbg x64 and analyzed the MEMORY.DMP file and each time, it's a DPC_WATCHDOG_VIOLATION on storport.sys. The parameters are the same every time -- 0x0, 0x501, 0x500, 0x0. It crashes in the storport!RaidAdapterAcquireInterruptLock+125e2 function.
I haven't yet installed antivirus software on the machine, so I can't point the finger at that.
Naturally I've checked the usual suspects -- the SSD and the hard drive. I installed WindowSMART 2013, and it gave both disks a clean bill of health. Crystal Disk Info said the disks were healthy too. The UEFI disk diagnostics also said the disks are healthy.
I looked in the event logs to see if I could see disk or storage controller errors, and there are none to be found. The only errors I found were a bunch of VSS errors which I very quickly traced back to CrashPlan (a cloud backup tool). Apparently CP and VSS don't get along when the cache is stored on an SSD. Moving the cache to the HDD got rid of the VSS errors yet the BSODs persist.
Like I said, I'm usually pretty good at troubleshooting BSODs with WinDbg, but I'm striking out on this one.
Having an MSDN subscription, I was eager to try out the Windows 8.1 RTM bits, so I asked my wife if I could borrow her HP Envy desktop for a few weeks--I bribed her with a brand new iPad so she let me take the desktop. The desktop shipped with Windows 8; in fact when you pull up the product page on HP the only OS listed as supported by HP is Windows 8 x64.
I installed a brand new Kingston HyperX 128GB SSD, installed Windows 8.1, and then reattached the original HDD. Windows detected most of the hardware, and for the items it didn't, it grabbed the drivers from Windows Update. The only one that needed manual intervention was the storage controller, so I grabbed the latest driver from the HP Support and Drivers page.
The machine ran fine for several days, until late last week it was sitting at the Startup Repair screen. I rebooted it, and it rebooted fine...but less than a day later, it was back at Startup Repair.
After each of these episodes, I fired up WinDbg x64 and analyzed the MEMORY.DMP file and each time, it's a DPC_WATCHDOG_VIOLATION on storport.sys. The parameters are the same every time -- 0x0, 0x501, 0x500, 0x0. It crashes in the storport!RaidAdapterAcquireInterruptLock+125e2 function.
I haven't yet installed antivirus software on the machine, so I can't point the finger at that.
Naturally I've checked the usual suspects -- the SSD and the hard drive. I installed WindowSMART 2013, and it gave both disks a clean bill of health. Crystal Disk Info said the disks were healthy too. The UEFI disk diagnostics also said the disks are healthy.
I looked in the event logs to see if I could see disk or storage controller errors, and there are none to be found. The only errors I found were a bunch of VSS errors which I very quickly traced back to CrashPlan (a cloud backup tool). Apparently CP and VSS don't get along when the cache is stored on an SSD. Moving the cache to the HDD got rid of the VSS errors yet the BSODs persist.
Like I said, I'm usually pretty good at troubleshooting BSODs with WinDbg, but I'm striking out on this one.
Code:
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
---------
Last edited:
My Computer
System One
-
- OS
- Windows 8.1
- Computer type
- PC/Desktop
- System Manufacturer/Model
- HP Envy h8-1534
- Memory
- 10GB
- Screen Resolution
- 1920x1080
- Hard Drives
- Kingston HyperX 128GB SSD
Seagate 1.5TB HDD
Seagate 750GB HDD
- Internet Speed
- Comcast XFINITY Blast 50