New
#41
I'll take a look tonight when I'm back from work.
Right, I'll go into this one in a bit more depth as it's the same as last time. I think I may have reached a conclusion but I'll get to that at the end of the post.
The Bugcheck 0x9F is again which means a DRIVER_POWER_STATE_FAILURE, and that is down to one thing; a device driver. The ASMedia USB 3.0 hub is being blamed again at the first look.
Digging deeper though the VIA Labs VL810 Superspeed USB Hub Controller Filter Driver is being flagged again.Code:******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 9F, {3, fffffa8008448cd0, fffff80000b9c3d8, fffffa800e883af0} *** WARNING: Unable to verify timestamp for asmthub3.sys *** ERROR: Module load completed but symbols could not be loaded for asmthub3.sys Probably caused by : asmthub3.sysYou can see at the bottom of that code that that particular controller is attached to the ASMedia USB Host Controller. Quite how I'm still yet to find out, but the firmware update you carried out hasn't updated the driver for it as you can see below.Code:0: kd> !devobj fffffa800f12ace0 Device object (fffffa800f12ace0) is for: InfoMask field not found for _OBJECT_HEADER at fffffa800f12acb0 \Driver\asmthub3 DriverObject fffffa800f2789c0 Current Irp 00000000 RefCount 0 Type 00008600 Flags 00002040 DevExt fffffa800f12ae30 DevObjExt fffffa800f12af90 ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT Characteristics (0x00000080) FILE_AUTOGENERATED_DEVICE_NAME AttachedDevice (Upper) fffffa800f12ee00Unable to load image \SystemRoot\system32\DRIVERS\vl810filter.sys, Win32 error 0n2 *** WARNING: Unable to verify timestamp for vl810filter.sys *** ERROR: Module load completed but symbols could not be loaded for vl810filter.sys \Driver\vl810filter AttachedTo (Lower) fffffa8008448cd0 \Driver\asmthub3
Looking at the text on their site it's no real surprise, they're not endorsing this firmware for end users and state it's specifically for the USB controller manufacturers to test.Code:0: kd> lmvm vl810filter start end module name fffff880`0850a000 fffff880`08512000 vl810filter T (no symbols) Loaded symbol image file: vl810filter.sys Image path: \SystemRoot\system32\DRIVERS\vl810filter.sys Image name: vl810filter.sys Timestamp: Mon Dec 06 03:00:01 2010 (4CFC51B1) CheckSum: 0000FB98 ImageSize: 00008000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Attachment 323000
Now whether this comes down to the ASMedia controller (it's not as nobody else has had trouble with ASMedia USB 3.0 controllers, it's quite common) or the motherboard itself is open to interpretation. I've been doing some reading of customer reviews on your board while at work and it's quite surprising how many people have complained about USB 3.0 problems and BSODs, as you stated on page 1 of this thread.
At this point I'm pretty much at a loss as to how to fix this, I've trawled high and low to find any evidence of successful firmware/driver updates to solve the issue but have found nothing.
My advice would be to contact EVGA with the all the evidence you've gathered from this thread so far and see what they say. They've responded openly to negative reviews on Amazon asking customers to contact them so you may get some joy there. I've no idea whether an RMA is out of the question, or even a replacement, but seeing as you have an OEM copy of Windows a motherboard replacement could be tricky when it comes to reactivating Windows.
Given the extenuating circumstances I think Microsoft may side with and provide you with a new key to activate if it comes to that, but don't take my word for it. It has been known in the past, I'd have to ask an activation expert to give some more input on that one.
Let me know what you think, but basically I'm putting the blame on the motherboard here and I'm not sure if there's anything else I can recommend. I'll ask for some more bods to take a look in here and see if they can see anything I've missed.
I think I got the right dump. The uploads are confusing.
The latest dump is still flagging the USB-3 Hub driver. It's hung waiting a completion. I would make sure the motherboard chipset drivers were loaded. This normally contains the INF installers that tells Windows how to option the hardware.
Code:******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 9F, {3, fffffa800f1ec8e0, fffff800085fc3d8, fffffa80138b46d0} *** WARNING: Unable to verify timestamp for asmthub3.sys *** ERROR: Module load completed but symbols could not be loaded for asmthub3.sys Probably caused by : asmthub3.sys Followup: MachineOwner --------- 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_POWER_STATE_FAILURE (9f) A driver is causing an inconsistent power state. Arguments: Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time Arg2: fffffa800f1ec8e0, Physical Device Object of the stack Arg3: fffff800085fc3d8, Functional Device Object of the stack Arg4: fffffa80138b46d0, The blocked IRP Debugging Details: ------------------ DRVPOWERSTATE_SUBCODE: 3 DRIVER_OBJECT: fffffa800f2f9a30 IMAGE_NAME: asmthub3.sys DEBUG_FLR_IMAGE_TIMESTAMP: 509beda3 MODULE_NAME: asmthub3 FAULTING_MODULE: fffff880091b8000 asmthub3 CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT BUGCHECK_STR: 0x9F PROCESS_NAME: System CURRENT_IRQL: 2 STACK_TEXT: fffff800`085fc388 fffff800`03d4b8d2 : 00000000`0000009f 00000000`00000003 fffffa80`0f1ec8e0 fffff800`085fc3d8 : nt!KeBugCheckEx fffff800`085fc390 fffff800`03ce685c : fffff800`085fc4c0 fffff800`085fc4c0 00000000`00000000 00000000`00000003 : nt! ?? ::FNODOBFM::`string'+0x33af0 fffff800`085fc430 fffff800`03ce66f6 : fffffa80`13aec460 fffffa80`13aec460 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x6c fffff800`085fc4a0 fffff800`03ce65de : 00000056`01258f6b fffff800`085fcb18 00000000`00242166 fffff800`03e59f48 : nt!KiProcessExpiredTimerList+0xc6 fffff800`085fcaf0 fffff800`03ce63c7 : 0000001f`13c454c4 0000001f`00242166 0000001f`13c4546c 00000000`00000066 : nt!KiTimerExpiration+0x1be fffff800`085fcb90 fffff800`03cd38ca : fffff800`03e56e80 fffff800`03e64cc0 00000000`00000001 fffff880`00000000 : nt!KiRetireDpcList+0x277 fffff800`085fcc40 00000000`00000000 : fffff800`085fd000 fffff800`085f7000 fffff800`085fcc00 00000000`00000000 : nt!KiIdleLoop+0x5a STACK_COMMAND: kb FOLLOWUP_NAME: MachineOwner FAILURE_BUCKET_ID: X64_0x9F_3_IMAGE_asmthub3.sys BUCKET_ID: X64_0x9F_3_IMAGE_asmthub3.sys Followup: MachineOwner --------- 0: kd> !irp fffffa80138b46d0 Irp is active with 10 stacks 9 is current (= 0xfffffa80138b49e0) No Mdl: No System Buffer: Thread 00000000: Irp stack trace. cmd flg cl Device File Completion-Context [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [ 0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 >[ 16, 2] 0 e1 fffffa800f1f48c0 00000000 fffff80003cc7710-fffffa80107e3720 Success Error Cancel pending \Driver\asmthub3 nt!IopUnloadSafeCompletion Args: 00016600 00000001 00000004 00000006 [ 0, 0] 0 0 00000000 00000000 00000000-fffffa800f5b3830 Args: 00000000 00000000 00000000 00000000 0: kd> lmvm asmthub3 start end module name fffff880`091b8000 fffff880`091dd000 asmthub3 T (no symbols) Loaded symbol image file: asmthub3.sys Image path: \SystemRoot\system32\DRIVERS\asmthub3.sys Image name: asmthub3.sys Timestamp: Thu Nov 08 11:36:35 2012 (509BEDA3) CheckSum: 00027E09 ImageSize: 00025000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
ASMedia XHCI Controller PCI\VEN_1B21 DEV_1042 SUBSYS_2104174C&REV_00
Hmmmm. That's a totally different chip than what's showing for the current devices from Austeck/ASMedia. It's going to be imperative that the correct BIOS and Chipset drivers are installed BEFORE attempting to install the driver for the HUB.
The BIOS is the latest version, I checked earlier against the available versions on the EVGA site as that was going to be my next recommendation. Excellent call on the chipset driver though Ken.
OK I just replaced the chipset driver with the one on evgas site.... got 2 shutdowns no crash....
I think that may have been it.---
Update --- NOPE el crasho....
Log attached....
Last edited by NoSuRReNDeR; 24 Jun 2014 at 23:53. Reason: Update
Look am not that good at the dump stuff to be brutally honest but I saw Boozad mention Comodo earlier and then in the last batch of msinfo I saw AVG installed and not being a great fan of it was thinking maybe you could disable it or get rid of it .
Certainly looks from a the broad angle though the board maybe suspect.
I suppose you have done the usual sfc and chkdsk?? and just as a suggestion maybe a drive and RAM test would not go amiss if only to eliminate those avenues.:)
Sorry for butting in but there are no new dump files, the latest one is still being caused by your Asmedia driver.
As for what Boozad said earlier.Code:0: kd> !devobj fffffa800f1c6cd0 Device object (fffffa800f1c6cd0) is for: Cannot read info offset from nt!ObpInfoMaskToOffset \Driver\asmthub3 DriverObject fffffa800f157950 Current Irp 00000000 RefCount 0 Type 00000022 Flags 00003040 DevExt fffffa800f1c6e20 DevObjExt fffffa800f1c6f90 DevNode fffffa800f1c28a0 ExtensionFlags (0x00000800) DOE_DEFAULT_SD_PRESENT Characteristics (0000000000) AttachedDevice (Upper) fffffa800f1d6ce0 \Driver\asmthub3 Device queue is not busy.
This is because IRPs are passed down PDOs (Physical Device Objects) to the low level drivers.You can see at the bottom of that code that that particular controller is attached to the ASMedia USB Host Controller. Quite how I'm still yet to find out, but the firmware update you carried out hasn't updated the driver for it as you can see below.
For example in a PCI device the IRP will be sent to the functioning driver which is generally passed through a filter driver down to the pci.sys driver which is the low level plug and play manager for all PCI devices.
In this case the IRP can be passed through multiple device objects before it reaches the target.
It can begin at disk.sys and finish at the USB host controllers which is the Asmedia drivers, although the IRP might not finish at the USB driver but it seems to be blocking it.
Are there no later versions than this?Code:0: kd> lmvm asmthub3 start end module name fffff880`091c2000 fffff880`091e7000 asmthub3 T (no symbols) Loaded symbol image file: asmthub3.sys Image path: \SystemRoot\system32\DRIVERS\asmthub3.sys Image name: asmthub3.sys Timestamp: Mon Jun 24 18:16:39 2013 (51C87EF7) CheckSum: 00023D78 ImageSize: 00025000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
I think the OP is installing the USB3 driver but not the motherboard drivers. It appears that asmthub3.sys is newer but still being flagged. The motherboard drivers should have come on a disc with the motherboard. After those are installed, THEN apply updated motherboard drivers. THEN install the updated USB3 driver. I didn't look at the new dump, if any, but the last MSinfo I looked at showed that Windows didn't assign an address to the USB3 Hub Controller. This means Windows didn't know what to do with it. Could be why WinDbg can't verify the driver. Either the motherboard is malfunctioning or the motherboard drivers weren't installed. As long as there's any USB driver installed, it gets inserted into the IRP string/stack but there's no hardware to return the release. It may be wise to just uninstall the USB3 driver until the motherboard is deemed functional.