Question BSOD usbhub.sys ?

Jan 21, 2024
23
0
10
I've been trying to resolve this BSOD, I've updated BIOS, updated Windows 10, checked drivers, rolled one back, turned off power control to USB, turned on maximum performance in all settings etc. Still getting BSOD with this same error a few times per day, no specific time, sometimes it's while using others when it first turns on. Here's the windmp file

******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************



DRIVER_POWER_STATE_FAILURE (9f)

A driver has failed to complete a power IRP within a specific time.

Arguments:

Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time

Arg2: ffffd78fb35ae060, Physical Device Object of the stack

Arg3: ffffba053be37ba0, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack

Arg4: ffffd78fb85f4a20, The blocked IRP



Debugging Details:

------------------





KEY_VALUES_STRING: 1



Key : Analysis.CPU.mSec

Value: 5046



Key : Analysis.Elapsed.mSec

Value: 5259



Key : Analysis.IO.Other.Mb

Value: 0



Key : Analysis.IO.Read.Mb

Value: 0



Key : Analysis.IO.Write.Mb

Value: 2



Key : Analysis.Init.CPU.mSec

Value: 1843



Key : Analysis.Init.Elapsed.mSec

Value: 31828



Key : Analysis.Memory.CommitPeak.Mb

Value: 162



Key : Bugcheck.Code.KiBugCheckData

Value: 0x9f



Key : Bugcheck.Code.LegacyAPI

Value: 0x9f



Key : Failure.Bucket

Value: 0x9F_3_IMAGE_usbhub.sys



Key : Failure.Hash

Value: {6e67f518-0887-9d66-a512-212f24e07d60}



Key : Hypervisor.Enlightenments.Value

Value: 0



Key : Hypervisor.Enlightenments.ValueHex

Value: 0



Key : Hypervisor.Flags.AnyHypervisorPresent

Value: 0



Key : Hypervisor.Flags.ApicEnlightened

Value: 0



Key : Hypervisor.Flags.ApicVirtualizationAvailable

Value: 0



Key : Hypervisor.Flags.AsyncMemoryHint

Value: 0



Key : Hypervisor.Flags.CoreSchedulerRequested

Value: 0



Key : Hypervisor.Flags.CpuManager

Value: 0



Key : Hypervisor.Flags.DeprecateAutoEoi

Value: 0



Key : Hypervisor.Flags.DynamicCpuDisabled

Value: 0



Key : Hypervisor.Flags.Epf

Value: 0



Key : Hypervisor.Flags.ExtendedProcessorMasks

Value: 0



Key : Hypervisor.Flags.HardwareMbecAvailable

Value: 0



Key : Hypervisor.Flags.MaxBankNumber

Value: 0



Key : Hypervisor.Flags.MemoryZeroingControl

Value: 0



Key : Hypervisor.Flags.NoExtendedRangeFlush

Value: 0



Key : Hypervisor.Flags.NoNonArchCoreSharing

Value: 0



Key : Hypervisor.Flags.Phase0InitDone

Value: 0



Key : Hypervisor.Flags.PowerSchedulerQos

Value: 0



Key : Hypervisor.Flags.RootScheduler

Value: 0



Key : Hypervisor.Flags.SynicAvailable

Value: 0



Key : Hypervisor.Flags.UseQpcBias

Value: 0



Key : Hypervisor.Flags.Value

Value: 0



Key : Hypervisor.Flags.ValueHex

Value: 0



Key : Hypervisor.Flags.VpAssistPage

Value: 0



Key : Hypervisor.Flags.VsmAvailable

Value: 0



Key : Hypervisor.RootFlags.AccessStats

Value: 0



Key : Hypervisor.RootFlags.CrashdumpEnlightened

Value: 0



Key : Hypervisor.RootFlags.CreateVirtualProcessor

Value: 0



Key : Hypervisor.RootFlags.DisableHyperthreading

Value: 0



Key : Hypervisor.RootFlags.HostTimelineSync

Value: 0



Key : Hypervisor.RootFlags.HypervisorDebuggingEnabled

Value: 0



Key : Hypervisor.RootFlags.IsHyperV

Value: 0



Key : Hypervisor.RootFlags.LivedumpEnlightened

Value: 0



Key : Hypervisor.RootFlags.MapDeviceInterrupt

Value: 0



Key : Hypervisor.RootFlags.MceEnlightened

Value: 0



Key : Hypervisor.RootFlags.Nested

Value: 0



Key : Hypervisor.RootFlags.StartLogicalProcessor

Value: 0



Key : Hypervisor.RootFlags.Value

Value: 0



Key : Hypervisor.RootFlags.ValueHex

Value: 0



Key : SecureKernel.HalpHvciEnabled

Value: 0



Key : WER.OS.Branch

Value: vb_release



Key : WER.OS.Version

Value: 10.0.19041.1





BUGCHECK_CODE: 9f



BUGCHECK_P1: 3



BUGCHECK_P2: ffffd78fb35ae060



BUGCHECK_P3: ffffba053be37ba0



BUGCHECK_P4: ffffd78fb85f4a20



FILE_IN_CAB: MEMORY.DMP



DRVPOWERSTATE_SUBCODE: 3



DRIVER_OBJECT: ffffd78fb26dfe40



IMAGE_NAME: usbhub.sys



MODULE_NAME: usbhub



FAULTING_MODULE: fffff80482f70000 usbhub



BLACKBOXBSD: 1 (!blackboxbsd)





BLACKBOXNTFS: 1 (!blackboxntfs)





BLACKBOXPNP: 1 (!blackboxpnp)





BLACKBOXWINLOGON: 1



PROCESS_NAME: svchost.exe



DPC_STACK_BASE: FFFFBA053BE37FB0



STACK_TEXT:

ffffba05`3be37b68 fffff804`707657d7 : 00000000`0000009f 00000000`00000003 ffffd78f`b35ae060 ffffba05`3be37ba0 : nt!KeBugCheckEx

ffffba05`3be37b70 fffff804`707656f1 : ffffd78f`b2743c80 00000000`00000000 00000000`00000000 00000000`0005ac33 : nt!PopIrpWatchdogBugcheck+0xdf

ffffba05`3be37be0 fffff804`704c1cc2 : ffffd78f`b2743cb8 ffffe781`84e80180 ffffba05`3be37e68 ffffe781`84e80180 : nt!PopIrpWatchdog+0x31

ffffba05`3be37c30 fffff804`704c0d3d : ffffe781`84e80180 81ce7368`00000000 00000000`00000008 00000000`0005ac33 : nt!KiProcessExpiredTimerList+0x172

ffffba05`3be37d20 fffff804`70605d75 : 587aa12d`af358308 ffffe781`84e80180 ffffd78f`ac2c65a0 00000000`00000001 : nt!KiRetireDpcList+0x5dd

ffffba05`3be37fb0 fffff804`70605b60 : fffff804`705f97a0 fffff804`705251fa 0000005f`9c57e8b0 000001b0`2cbeb280 : nt!KxRetireDpcList+0x5

ffffba05`3ccdfa80 fffff804`706052d5 : 00000000`00000001 fffff804`705fff61 00000000`00000008 ffffd78f`00000001 : nt!KiDispatchInterruptContinue

ffffba05`3ccdfab0 fffff804`705fff61 : 00000000`00000008 ffffd78f`00000001 ffffba05`3ccdfb40 ffffd78f`0000104c : nt!KiDpcInterruptBypass+0x25

ffffba05`3ccdfac0 00007ffc`5b557bf8 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiInterruptDispatchNoLockNoEtw+0xb1

0000005f`9c57e210 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffc`5b557bf8





IMAGE_VERSION: 10.0.19041.3636



STACK_COMMAND: .cxr; .ecxr ; kb



FAILURE_BUCKET_ID: 0x9F_3_IMAGE_usbhub.sys



OS_VERSION: 10.0.19041.1



BUILDLAB_STR: vb_release



OSPLATFORM_TYPE: x64



OSNAME: Windows 10



FAILURE_ID_HASH: {6e67f518-0887-9d66-a512-212f24e07d60}



Followup: MachineOwner
 
Last edited by a moderator:
Hi, welcome to the forums!

If you are using a USB hub, unplug it and test again. While it says "usbhub.sys", that doesn't mean that is the actual problem. It could be a USB device that you are using. A mouse, a flash drive, etc.

There's a lot of info that you've left out.

Are you actually using a USB hub and if so, what brand/model?

Have you tried stripping it down to only using the necessary USB devices (if any). And then, trying a different mouse (and driver) if needed?

Which driver did you rollback and why?

You've checked drivers, but from where? Hopefully not a 3rd party driver application. Have you tried updating the drivers from the manufacturer's website?
 
No USB hub and I've purchased a new mouse, that is all that is currently plugged in, but I've got the same BSOD without the mouse plugged in at all while only using the touchpad. I've updated to the newest drivers on HP website for my specific machine, I let HP site determine and find and then downloaded and installed. Nothing is rolled back anymore its all on the most current. I can get specifics if needed. I haven't downloaded any third party drivers or websites. Only on the HP site directly. I did a BIOS update from there as well.
 
System model number? HP... ?

Look in C:\Windows\minidump and copy those files to a different place on the PC (desktop or documents or wherever). Zip them up and upload them to a file sharing site such as OneDrive or Google Drive. Provide a link here. Be sure the files are publicly available for anyone to download. The more dump files, the better (up to a max of 5 or so).

If you don't have any files there, you may need to turn on "small memory dumps" in system settings and I can help with that. If things are working right, a dump file should be created each time there is a crash.

Maybe @ubuysa will stop in have a look.
 
System model number? HP... ?

Look in C:\Windows\minidump and copy those files to a different place on the PC (desktop or documents or wherever). Zip them up and upload them to a file sharing site such as OneDrive or Google Drive. Provide a link here. Be sure the files are publicly available for anyone to download. The more dump files, the better (up to a max of 5 or so).

If you don't have any files there, you may need to turn on "small memory dumps" in system settings and I can help with that. If things are working right, a dump file should be created each time there is a crash.

Maybe @ubuysa will stop in have a look.
I posted the minidump file in my first post, I deleted the other ones, they are all the same. This was the most recent one from today at 4pm.
 
You posted the debugger output from the dump file. The dump file itself contains much more info which may be useful to people who know how to read them. The dump files will be located in C:\Windows\minidump and the filenames end with .dmp.
sorry about that, i thought i did it correctly. will link a zip file
 
report - mostly for me and gardenman when he comes back

I see what they show.


File: 012124-8156-01.dmp (Jan 22 2024 - 07:39:23)
BugCheck: [DRIVER_POWER_STATE_FAILURE (9F)]
Probably caused by: memory_corruption (Process: svchost.exe)
Uptime: 0 Day(s), 2 Hour(s), 42 Min(s), and 24 Sec(s)

File: 012124-7734-01.dmp (Jan 22 2024 - 04:56:38)
BugCheck: [DRIVER_POWER_STATE_FAILURE (9F)]
Probably caused by: memory_corruption (Process: System)
Uptime: 2 Day(s), 4 Hour(s), 56 Min(s), and 06 Sec(s)

File: 012124-7703-01.dmp (Jan 22 2024 - 11:37:55)
BugCheck: [DRIVER_POWER_STATE_FAILURE (9F)]
Probably caused by: memory_corruption (Process: System)
Uptime: 0 Day(s), 3 Hour(s), 58 Min(s), and 11 Sec(s)

none of those show USBHub.sys...
nor do they reveal which driver is to blame.

Have you run Hp Support Assistant? It should suggest new drivers - https://support.hp.com/au-en/help/hp-support-assistant
running this might help as well - https://www.intel.com/content/www/us/en/support/intel-driver-support-assistant.html
 
Below is the copy and paste of what I was seeing which is what I was reading which led me to believe it was the usb drivers. I have run both the HP assistant and the intel one, I will redo them both today. HP updated the BIOS and the rest said drivers were up to date. I don't recall what the Intel one did, I believe it said all up to date except the bluetooth one. That one still won't install, it says to install it, but then it says install failed incompatible. What should my next step be?

IMAGE_NAME: usbhub.sys
MODULE_NAME: usbhub
FAULTING_MODULE: fffff80482f70000 usbhub
 
Okay, I ran the Intel and HP stuff from the suggested links. I did these before too. The only thing it finds is the Intel Bluetooth adapter update, it will not install, but nothing else. I tried again today and it didn't work, I tried deleting the old one from device manager first and installing and it still gives me the same error. I'm not sure that this even matters for the issue I'm having, I don't have anything connected via bluetooth. Anything else I can try or check? I'm not sure what else is missing. I checked to see if I could just update to windows 11, its not compatible either.

Intel® Wireless Bluetooth® for Windows® 10 and Windows 11*
Installation failed
1/23/2024 4:48 PM
Description:
Installs Intel® Wireless Bluetooth® version 23.10.0 Driver version varies depending on
the wireless adapter installed.
Version:
20.100.10.11Release date:
December 5, 2023Size:
58.21 M
 
Based on your mention of the memory corruption, I ran sfc scannow and it found one corrupt file and repaired it, I don't know if that has anything to do with the crash, would it? I ran this scan before and it found nothing, it's been blue screening for awhile. I remember installing windows 10 and it worked fine for awhile then started doing this a while ago. I'm assuming a windows update broke something, is that possible?
 
Thanks. I've updated some drivers with drivereasy, not all yet, takes a long time to do one. Still BSODing, not sure what to do next or if I should keep going with the drivers they found outdated.
 
Sorry I must have missed this one...

It's NEVER wise to use tools like DriverEasy, you have no idea whether it really finds the best driver nor where the driver has come from. Drivers should be sourced only via Windows Update, the PC vendor's website, the motherboard vendor's website, or the specific hardware vendor's website.

The dumps are identical, they are all 0x9F indicating that a device (or driver) failed to complete a power transition is a reasonable time. From the dump we can obtain the address of the device object structure, which Windows uses to manage the specific device. From that we can get the address of the device node, which describes the actual device at fault.

As mentioned, all the dumps are identical and this is the device node in each of them...
Code:
1: kd> !devnode ffffd78fb312fb50
DevNode 0xffffd78fb312fb50 for PDO 0xffffd78fb35ae060
  Parent 0xffffd78fb3177820   Sibling 0000000000   Child 0000000000
  InstancePath is "USB\VID_0424&PID_2532\6&1609e155&0&7"
  ServiceName is "WinUSB"
  State = DeviceNodeStarted (0x308)
  Previous State = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[18] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[17] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[16] = DeviceNodeStarted (0x308)
  StateHistory[15] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[14] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[13] = DeviceNodeStarted (0x308)
  StateHistory[12] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[11] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[10] = DeviceNodeStarted (0x308)
  StateHistory[09] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[08] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[07] = DeviceNodeStarted (0x308)
  StateHistory[06] = DeviceNodeStartPostWork (0x307)
  StateHistory[05] = DeviceNodeStartCompletion (0x306)
  StateHistory[04] = DeviceNodeStartPending (0x305)
  StateHistory[03] = DeviceNodeResourcesAssigned (0x304)
  StateHistory[02] = DeviceNodeDriversAdded (0x303)
  StateHistory[01] = DeviceNodeInitialized (0x302)
  StateHistory[00] = DeviceNodeUninitialized (0x301)
  StateHistory[19] = Unknown State (0x0)
  Flags (0x6c000130)  DNF_ENUMERATED, DNF_IDS_QUERIED,
                      DNF_NO_RESOURCE_REQUIRED, DNF_NO_LOWER_DEVICE_FILTERS,
                      DNF_NO_LOWER_CLASS_FILTERS, DNF_NO_UPPER_DEVICE_FILTERS,
                      DNF_NO_UPPER_CLASS_FILTERS
  CapabilityFlags (0x00041c03)  DeviceD1, DeviceD2,
                                WakeFromD0, WakeFromD1,
                                WakeFromD2, ReservedCap1
You can see at the bottom there in the CapabilityFlags section, that this device is capable of waking from D1 and D2. These are lower power (power saving) states, D0 is the normal high power running state. This device should therefore have been able to complete the power transition - but it clearly wasn't.

The driver in question is also identified in the dump from the address of the IRP that's managing the power transition...
Code:
1: kd> !irp ffffd78fb85f4a20
Irp is active with 10 stacks 8 is current (= 0xffffd78fb85f4ce8)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.
     cmd  flg cl Device   File     Completion-Context
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
            0 e1 ffffd78fb35ae060 00000000 00000000-00000000    pending
           \Driver\usbhub
            Args: 00041100 00000001 00000001 00000002
 [IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
            0 e1 ffffd78facf22da0 00000000 fffff8047057ac60-ffffd78fb2743c80 Success Error Cancel pending
           \Driver\WINUSB    nt!PopRequestCompletion
            Args: 00041100 00000001 00000001 00000002
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-ffffd78fb2743c80

            Args: 00000000 00000000 00000000 00000000
The driver WINUSB.sys is the driver that's hanging during the power transition, but this is a Microsoft driver and so it's not at fault.

The device itself is identified in the device node output in the InstancePath entry...
Code:
USB\VID_0424&PID_2532\6&1609e155&0&7
The USB\VID_0424&PID_2532 identifiers show this to be the USB root hub, as we expected given the driver.

That means this is either a problem with the USB hub itself or, more likely, a problem with the chipset drivers that manage devices on the motherboard. If you've used DriverEasy to find chipset drivers then I'd bet that it's installed the wrong drivers. You need to go to the motherboard vendor's website and download the latest chipset driver package from there and install the correct chipset drivers. If there are specific USB drivers there also then download and install them as well.

TBH I'd install all the drivers you can from the motherboard vendor's website, you don't know what else may have been messed up.
 
Last edited:
Sorry I must have missed this one...

It's NEVER wise to use tools like DriverEasy, you have no idea whether it really finds the best driver nor where the driver has come from. Drivers should be sourced only via Windows Update, the PC vendor's website, the motherboard vendor's website, or the specific hardware vendor's website.

The dumps are identical, they are all 0x9F indicating that a device (or driver) failed to complete a power transition is a reasonable time. From the dump we can obtain the address of the device object structure, which Windows uses to manage the specific device. From that we can get the address of the device node, which describes the actual device at fault.

As mentioned, all the dumps are identical and this is the device node in each of them...
Code:
1: kd> !devnode ffffd78fb312fb50
DevNode 0xffffd78fb312fb50 for PDO 0xffffd78fb35ae060
  Parent 0xffffd78fb3177820   Sibling 0000000000   Child 0000000000
  InstancePath is "USB\VID_0424&PID_2532\6&1609e155&0&7"
  ServiceName is "WinUSB"
  State = DeviceNodeStarted (0x308)
  Previous State = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[18] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[17] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[16] = DeviceNodeStarted (0x308)
  StateHistory[15] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[14] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[13] = DeviceNodeStarted (0x308)
  StateHistory[12] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[11] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[10] = DeviceNodeStarted (0x308)
  StateHistory[09] = DeviceNodeEnumerateCompletion (0x30d)
  StateHistory[08] = DeviceNodeEnumeratePending (0x30c)
  StateHistory[07] = DeviceNodeStarted (0x308)
  StateHistory[06] = DeviceNodeStartPostWork (0x307)
  StateHistory[05] = DeviceNodeStartCompletion (0x306)
  StateHistory[04] = DeviceNodeStartPending (0x305)
  StateHistory[03] = DeviceNodeResourcesAssigned (0x304)
  StateHistory[02] = DeviceNodeDriversAdded (0x303)
  StateHistory[01] = DeviceNodeInitialized (0x302)
  StateHistory[00] = DeviceNodeUninitialized (0x301)
  StateHistory[19] = Unknown State (0x0)
  Flags (0x6c000130)  DNF_ENUMERATED, DNF_IDS_QUERIED,
                      DNF_NO_RESOURCE_REQUIRED, DNF_NO_LOWER_DEVICE_FILTERS,
                      DNF_NO_LOWER_CLASS_FILTERS, DNF_NO_UPPER_DEVICE_FILTERS,
                      DNF_NO_UPPER_CLASS_FILTERS
  CapabilityFlags (0x00041c03)  DeviceD1, DeviceD2,
                                WakeFromD0, WakeFromD1,
                                WakeFromD2, ReservedCap1
You can see at the bottom there in the CapabilityFlags section, that this device is capable of waking from D1 and D2. These are lower power (power saving) states, D0 is the normal high power running state. This device should therefore have been able to complete the power transition - but it clearly wasn't.

The driver in question is also identified in the dump from the address of the IRP that's managing the power transition...
Code:
1: kd> !irp ffffd78fb85f4a20
Irp is active with 10 stacks 8 is current (= 0xffffd78fb85f4ce8)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.
     cmd  flg cl Device   File     Completion-Context
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-00000000

            Args: 00000000 00000000 00000000 00000000
>[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
            0 e1 ffffd78fb35ae060 00000000 00000000-00000000    pending
           \Driver\usbhub
            Args: 00041100 00000001 00000001 00000002
 [IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]
            0 e1 ffffd78facf22da0 00000000 fffff8047057ac60-ffffd78fb2743c80 Success Error Cancel pending
           \Driver\WINUSB    nt!PopRequestCompletion
            Args: 00041100 00000001 00000001 00000002
 [N/A(0), N/A(0)]
            0  0 00000000 00000000 00000000-ffffd78fb2743c80

            Args: 00000000 00000000 00000000 00000000
The driver WINUSB.sys is the driver that's hanging during the power transition, but this is a Microsoft driver and so it's not at fault.

The device itself is identified in the device node output in the InstancePath entry...
Code:
USB\VID_0424&PID_2532\6&1609e155&0&7
The USB\VID_0424&PID_2532 identifiers show this to be the USB root hub, as we expected given the driver.

That means this is either a problem with the USB hub itself or, more likely, a problem with the chipset drivers that manage devices on the motherboard. If you've used DriverEasy to find chipset drivers then I'd bet that it's installed the wrong drivers. You need to go to the motherboard vendor's website and download the latest chipset driver package from there and install the correct chipset drivers. If there are specific USB drivers there also then download and install them as well.

TBH I'd install all the drivers you can from the motherboard vendor's website, you don't know what else may have been messed up.
Thank you, how would I install from the motherboard site, would this be intel? Intel wasn't finding any drivers, it was only finding the bluetooth which wouldn't update. Drivereasy found the new bluetooth driver and it did install, the version number matched what intel said. I am not arguing the point, just that it finally updated. I'll roll back the drivers. It found a bunch of intel driver updates which I didn't install, i belive it was something like intel then a number #1 #2 etc.
 
Bad idea. Undo what you've done so far with "Drivereasy", if you can.
Don't do any more updates with "Drivereasy".

Remember when I said this:

That would be "Drivereasy".

Yes, this is where I went, nothing comes up at all, I select windows 10 and 64 bit, nothing is found. Intel site finds just the bluetooth. If this is a driver issue and HP finds nothing, how am I supposed to resolve the issue? I keep getting directed back to the HP site for drivers, but that isn't doing anything, I have run that scan a dozen times, it says I have the most up dated drivers available which is how I got to driver easy which was finding newer versions of drivers and the bluetooth one that intel said I needed as well
 
If this is a driver issue
I usually blame hardware before drivers, usually RAM, CPU, or GPU. If it's a hardware issue, it doesn't matter what drivers you throw at it, it's still going to crash. I can't answer whether or not this is a driver issue, or hardware.

You could do some hardware testing, which may or may not determine is it's hardware or not. Hardware tests are not perfect.

Try memtest.
 
As above you need to find out whether it's a hardware or software problem. An excellent way of doing that is to start Windows in Safe Mode. Safe Mode loads a stripped down version of Windows with only essential drivers and services loaded, no third party drivers are loaded (except for networking), and so if it fails in Safe Mode the problem is almost certainly hardware.

The problem with Safe Mode is that it's not fun. Because no third party drivers are loaded, many of your devices will not work properly (or at all). You display, for example, will be very low resolution, because you'll be using only the Windows basic display driver. You won't be able to do any useful work in Safe Mode, it's a troubleshooting mode designed exactly for the purpose of checking whether a problem is hardware or software.

Start Windows in Safe Mode with networking and use it as much and as often as you are able, in order to try and make it fail. You need to keep the PC in Safe Mode for long enough to have usually had a problem, usually you want to run in Safe Mode for a couple of hours at least.

Let us know how that goes.
 
  • Like
Reactions: gardenman
Solved. It was a driver, DriverEasy had some listed that intel scanner wasn't picking up, once the 5 or so were installed and updated the computer stopped crashing. I know drivereasy isn't recommended, but intel and hp scans were not finding the updated drivers to resolve the issue. I thought it was a hardware issue, but bluescreen view found windows issues linked to the crash that the dmp view didn't show.