Windows 10: Bugcheck 0x144 caused by USBXHCI.sys according to WinDBG

Hello, Ten Forums! *Smile

So, here's a quick problem. I just noticed this bug check when I logged in to my z97 system and saw this error on the security and maitenance panel.

Problem is that this is kinda not a bsod problem, but it has a similiar behavior to gpu driver crashing and recovering but somehow I've never encountered this bugcheck before. Now, problem is if this is a hardware problem or a third party driver problem. If you guys have any suggestions to bring down the problem, then I'm all ears. *Smile

Here's the bugcheck on the dump:

Code: Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Windows\LiveKernelReports\USBXHCI\USBXHCI-20150916-0059.dmp] Mini Kernel Dump File: Only registers and stack trace are available Symbol search path is: *** Invalid *** **************************************************************************** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * **************************************************************************** Executable search path is: ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* Unable to load image ntoskrnl.exe, Win32 error 0n2 *** WARNING: Unable to verify timestamp for ntoskrnl.exe *** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe Windows 8 Kernel Version 10240 MP (8 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Personal Machine Name: Kernel base = 0xfffff802`d8e7d000 PsLoadedModuleList = 0xfffff802`d91a2030 Debug session time: Wed Sep 16 00:59:54.378 2015 (UTC - 4:00) System Uptime: 0 days 0:02:07.027 ********************************************************************* * Symbols can not be loaded because symbol path is not initialized. * * * * The Symbol Path can be set by: * * using the _NT_SYMBOL_PATH environment variable. * * using the -y <symbol_path> argument when starting the debugger. * * using .sympath and .sympath+ * ********************************************************************* Unable to load image ntoskrnl.exe, Win32 error 0n2 *** WARNING: Unable to verify timestamp for ntoskrnl.exe *** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe Loading Kernel Symbols ............................................................... ................................................................ .................................... Loading User Symbols Mini Kernel Dump does not contain unloaded driver list ************* Symbol Loading Error Summary ************** Module name Error ntoskrnl The system cannot find the file specified You can troubleshoot most symbol related issues by turning on symbol loading diagnostics (!sym noisy) and repeating the command that caused symbols to be loaded. You should also verify that your symbol search path (.sympath) is correct. *** WARNING: Unable to verify timestamp for USBXHCI.SYS *** ERROR: Module load completed but symbols could not be loaded for USBXHCI.SYS ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 144, {100d, ffffd00021079960, 0, 0} *** WARNING: Unable to verify timestamp for mssmbios.sys *** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys ***** Kernel symbols are WRONG. Please fix symbols to do analysis. ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: usbxhci!_XHCI_LIVEDUMP_CONTEXT *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: USBXHCI!CONTROLLER_DATA *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* ************************************************************************* *** *** *** *** *** Either you specified an unqualified symbol, or your debugger *** *** doesn't have full symbol information. Unqualified symbol *** *** resolution is turned off by default. Please either specify a *** *** fully qualified symbol module!symbolname, or enable resolution *** *** of unqualified symbols by typing ".symopt- 100". Note that *** *** enabling unqualified symbol resolution with network symbol *** *** server shares in the symbol path may cause the debugger to *** *** appear to hang for long periods of time when an incorrect *** *** symbol name is typed or the network symbol server is down. *** *** *** *** For some commands to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: nt!_KPRCB *** *** *** ************************************************************************* Probably caused by : USBXHCI.SYS ( USBXHCI+39dac ) Followup: MachineOwner[/quote] If the dump is unclear, I do have the dump files if I can upload it if you want. Oh yeah, I almost forgot, I honestly never had that problem before upgrading to windows 10. D:

EDIT: I did use the dm log collector to compress the dumps but when I look at the zip file, I don't see any dumps. I'll upload those if needed.

:)

 

Constant Blue Screens - Event ID 10016, Distributed COM Error

The error again references the USBXHCI.SYS:

BugCheck 139, {3, fffff801afc5b2c0, fffff801afc5b218, 0}

Probably caused by : USBXHCI.SYS ( USBXHCI!Isoch_Transfer_CompleteCancelable+6f )

Can you ensure KB4022716 is installed to update the Windows 10 Build and update the USBXHCI.SYS:

https://support.microsoft.com/en-us/help/4022716

If the error persists can you provide the C:\Windows\MEMORY.DMP file.

 

Windows 10 driver_irql_not_less_or_equal usbxhci.sys when playing a video

The minidump files showed DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) and BAD_POOL_CALLER (c2) stop errors seemingly caused by the USBXHCI.SYS
- Microsoft USB 3.0 driver :

BugCheck D1, {20, 2, 0, fffff801daf5c7a5}

Probably caused by : USBXHCI.SYS ( USBXHCI!Isoch_Stage_CompleteTD+45 )

BugCheck C2, {7, 126c, 410000c, ffffe0009c4787b0}

fffff80239d9b520: Unable to get MiVisibleState

Probably caused by : USBXHCI.SYS ( USBXHCI!Isoch_Stage_FreeScatterGatherList+5e )

There is a good chance the driver that is actually causing the crash is a third party driver related to USB.

What devices are attached to USB ports?

What devices are attached to USB 3.0 ports?

Did the start of the problem coincide with adding a particular USB device?

There appears to be a Logitech camera and USB wireless adapter installed. What USB ports are these device plugged into - USB 2.0 or USB 3.0 ?

Also, can you also provide the following file which has more information on the crash:

C:\Windows\MEMORY.DMP

The memory.dmp file will be quite large, you could zip and compress the memory.dmp file with a third party application such as 7-Zip.

 

Hi RyougaLolakie,

Welcome to the 10forums.

The problem is that the dump couldn't download the necessary files, because your symbol path is Invalid.

Please read the tutorial for setting up windbg properly How to setup windbg properly

 

My apologies for not downloading symbols. Problem is that when I added the symbol path, I get this: "WARNING: Whitespace at end of path elementError: Empty Path."

Anyway, here's the dump with symbols attactched:

Code: Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Windows\LiveKernelReports\USBXHCI\USBXHCI-20150916-0059.dmp] Mini Kernel Dump File: Only registers and stack trace are available WARNING: Whitespace at end of path element Error: Empty Path. Symbol search path is: SRV*C:\SymCache*Symbol information Executable search path is: Windows 8 Kernel Version 10240 MP (8 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 10240.16463.amd64fre.th1.150819-1946 Machine Name: Kernel base = 0xfffff802`d8e7d000 PsLoadedModuleList = 0xfffff802`d91a2030 Debug session time: Wed Sep 16 00:59:54.378 2015 (UTC - 4:00) System Uptime: 0 days 0:02:07.027 Loading Kernel Symbols .. Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols. ............................................................. ................................................................ .................................... Loading User Symbols Mini Kernel Dump does not contain unloaded driver list ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 144, {100d, ffffd00021079960, 0, 0} Probably caused by : USBXHCI.SYS ( USBXHCI!TelemetryData_CreateReport+c0 ) Followup: MachineOwner --------- 2: kd> !thread GetPointerFromAddress: unable to read from fffff802d92421c0 THREAD ffffe0007b440840 Cid 0004.13fc Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 2 Not impersonating GetUlongFromAddress: unable to read from fffff802d9190fe8 Owning Process ffffe00072a5a840 Image: System Attached Process N/A Image: N/A fffff78000000000: Unable to get shared data Wait Start TickCount 8129 Context Switch Count 978 IdealProcessor: 2 ReadMemory error: Cannot get nt!KeMaximumIncrement value. UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address nt!ExpWorkerThread (0xfffff802d8ef55c0) Stack Init ffffd00021079c90 Current ffffd00021079690 Base ffffd0002107a000 Limit ffffd00021074000 Call 0 Priority 13 BasePriority 12 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5 Child-SP RetAddr : Args to Child : Call Site ffffd000`210793e0 fffff800`7b0c5ca7 : 00000000`00000005 ffffe000`7a27b2d0 fffff800`7b0b8860 00001401`24101004 : USBXHCI!TelemetryData_CreateReport+0xc0 ffffd000`21079910 fffff800`7b0c60ef : ffffe000`77fa37e0 ffffd000`21079a40 ffffe000`7a27b2d0 00000000`00000000 : USBXHCI!Controller_TelemetryReport+0x137 ffffd000`21079a00 fffff800`77c6f599 : ffffe000`77fa36e0 00000000`00000002 00000000`00000002 00000000`00000000 : USBXHCI!Controller_TelemetryReportWorker+0x21f ffffd000`21079a80 fffff800`77c7f5f9 : ffffd001`36524a00 ffffe000`77fa36e0 ffffe000`77dfc860 ffffe000`7b440980 : Wdf01000!FxWorkItem::WorkItemHandler+0xb5 [d:\th\minkernel\wdf\framework\shared\core\fxworkitem.cpp @ 374] ffffd000`21079ac0 fffff802`d8ef5f94 : ffffe000`77fa3660 fffff802`d8ef5a98 fffff802`d9256301 00000000`00000000 : Wdf01000!FxWorkItem::WorkItemThunk+0x29 [d:\th\minkernel\wdf\framework\shared\core\fxworkitem.cpp @ 439] ffffd000`21079b00 fffff802`d8ef56a9 : fffff802`d9256340 ffffe000`7b440840 fffff802`d8ef5ea0 fffff802`d9256301 : nt!IopProcessWorkItem+0xf4 ffffd000`21079b70 fffff802`d8f63e88 : ffffe000`72a5a840 00000000`00000080 fffff802`d9256340 ffffe000`7b440840 : nt!ExpWorkerThread+0xe9 ffffd000`21079c00 fffff802`d8fd0326 : ffffd001`35d09180 ffffe000`7b440840 ffffd001`35d15cc0 00000000`00000000 : nt!PspSystemThreadStartup+0x58 ffffd000`21079c60 00000000`00000000 : ffffd000`2107a000 ffffd000`21074000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16 2: kd> !analyze ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 144, {100d, ffffd00021079960, 0, 0} Probably caused by : USBXHCI.SYS ( USBXHCI!TelemetryData_CreateReport+c0 ) Followup: MachineOwner ---------[/quote]

 

[/quote] This dump doesn't give enough information. The driver is a driver from windows and windows drivers are rarely the real cause.

Please follow the tutorial, if you get an error you haven't done something correct.

After windbg is properly configured click on !analyze -v for more information.

 

Oh okay, in case I got stuck on something because I know that I'm trying to set up prior to what the tutorial tells me to do. The 2 minidumps are included in the zip file on the first post.

EDIT: Alright, I got it set up correctly this time. Here's the updated dump analysis:

Code: Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Windows\LiveKernelReports\USBXHCI\USBXHCI-20150916-0059.dmp] Mini Kernel Dump File: Only registers and stack trace are available ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred SRV*C:\SymCache*Symbol information Symbol search path is: SRV*C:\SymCache*Symbol information Executable search path is: Windows 8 Kernel Version 10240 MP (8 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 10240.16463.amd64fre.th1.150819-1946 Machine Name: Kernel base = 0xfffff802`d8e7d000 PsLoadedModuleList = 0xfffff802`d91a2030 Debug session time: Wed Sep 16 00:59:54.378 2015 (UTC - 4:00) System Uptime: 0 days 0:02:07.027 Loading Kernel Symbols .. Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols. ............................................................. ................................................................ .................................... Loading User Symbols Mini Kernel Dump does not contain unloaded driver list ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 144, {100d, ffffd00021079960, 0, 0} Probably caused by : USBXHCI.SYS ( USBXHCI!TelemetryData_CreateReport+c0 ) Followup: MachineOwner --------- 2: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* BUGCODE_USB3_DRIVER (144) This bugcheck usually happens when the USB3 core stack detects an invalid operation being performed by a USB client. This bugcheck may also occur due to hardware failure on a USB Boot Device. Arguments: Arg1: 000000000000100d, USB3_WER_BUGCODE_USBXHCI_CONTROLLER_GONE The controller was detected to be physically removed. Arg2: ffffd00021079960, XHCI_LIVEDUMP_CONTEXT Arg3: 0000000000000000, 0 Arg4: 0000000000000000, 0 Debugging Details: ------------------ HARDWARE_VENDOR_ID: VEN_1B21 HARDWARE_DEVICE_ID: DEV_1142 HARDWARE_REV_ID: REV_0000 HARDWARE_ID: VEN_1B21&DEV_1142&REV_0000 DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: 0x144 PROCESS_NAME: System CURRENT_IRQL: 0 ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre LAST_CONTROL_TRANSFER: from fffff8007b0c5ca7 to fffff8007b0e9dac STACK_TEXT: ffffd000`210793e0 fffff800`7b0c5ca7 : 00000000`00000005 ffffe000`7a27b2d0 fffff800`7b0b8860 00001401`24101004 : USBXHCI!TelemetryData_CreateReport+0xc0 ffffd000`21079910 fffff800`7b0c60ef : ffffe000`77fa37e0 ffffd000`21079a40 ffffe000`7a27b2d0 00000000`00000000 : USBXHCI!Controller_TelemetryReport+0x137 ffffd000`21079a00 fffff800`77c6f599 : ffffe000`77fa36e0 00000000`00000002 00000000`00000002 00000000`00000000 : USBXHCI!Controller_TelemetryReportWorker+0x21f ffffd000`21079a80 fffff800`77c7f5f9 : ffffd001`36524a00 ffffe000`77fa36e0 ffffe000`77dfc860 ffffe000`7b440980 : Wdf01000!FxWorkItem::WorkItemHandler+0xb5 [d:\th\minkernel\wdf\framework\shared\core\fxworkitem.cpp @ 374] ffffd000`21079ac0 fffff802`d8ef5f94 : ffffe000`77fa3660 fffff802`d8ef5a98 fffff802`d9256301 00000000`00000000 : Wdf01000!FxWorkItem::WorkItemThunk+0x29 [d:\th\minkernel\wdf\framework\shared\core\fxworkitem.cpp @ 439] ffffd000`21079b00 fffff802`d8ef56a9 : fffff802`d9256340 ffffe000`7b440840 fffff802`d8ef5ea0 fffff802`d9256301 : nt!IopProcessWorkItem+0xf4 ffffd000`21079b70 fffff802`d8f63e88 : ffffe000`72a5a840 00000000`00000080 fffff802`d9256340 ffffe000`7b440840 : nt!ExpWorkerThread+0xe9 ffffd000`21079c00 fffff802`d8fd0326 : ffffd001`35d09180 ffffe000`7b440840 ffffd001`35d15cc0 00000000`00000000 : nt!PspSystemThreadStartup+0x58 ffffd000`21079c60 00000000`00000000 : ffffd000`2107a000 ffffd000`21074000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16 STACK_COMMAND: kb FOLLOWUP_IP: USBXHCI!TelemetryData_CreateReport+c0 fffff800`7b0e9dac 488b03 mov rax,qword ptr [rbx] SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: USBXHCI!TelemetryData_CreateReport+c0 FOLLOWUP_NAME: MachineOwner MODULE_NAME: USBXHCI IMAGE_NAME: USBXHCI.SYS DEBUG_FLR_IMAGE_TIMESTAMP: 55d2d74f IMAGE_VERSION: 10.0.10240.16461 FAILURE_BUCKET_ID: 0x144_CONTROLLER_GONE BUCKET_ID: 0x144_CONTROLLER_GONE ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:0x144_controller_gone FAILURE_ID_HASH: {2ad03f65-afb1-1506-b19a-46ca5d0bb05d} Followup: MachineOwner ---------[/quote]

 

Do you have other dump files?
I can't read them either, this could be due to hardware problems.

 

I do have the other dump file which is related to this:

Code: ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred SRV*C:\SymCache*Symbol information Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Windows\LiveKernelReports\USBXHCI\USBXHCI-20150916-0058.dmp] Mini Kernel Dump File: Only registers and stack trace are available ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred SRV*C:\SymCache*Symbol information Symbol search path is: SRV*C:\SymCache*Symbol information Executable search path is: Windows 8 Kernel Version 10240 MP (8 procs) Free x64 Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 10240.16463.amd64fre.th1.150819-1946 Machine Name: Kernel base = 0xfffff802`d8e7d000 PsLoadedModuleList = 0xfffff802`d91a2030 Debug session time: Wed Sep 16 00:58:00.212 2015 (UTC - 4:00) System Uptime: 0 days 0:00:12.861 Loading Kernel Symbols .. Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols. ............................................................. ................................................................ ..................................... Loading User Symbols Mini Kernel Dump does not contain unloaded driver list ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 144, {1013, ffffd00135ee9960, 0, 0} Probably caused by : USBXHCI.SYS ( USBXHCI!TelemetryData_CreateReport+c0 ) Followup: MachineOwner --------- 7: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* BUGCODE_USB3_DRIVER (144) This bugcheck usually happens when the USB3 core stack detects an invalid operation being performed by a USB client. This bugcheck may also occur due to hardware failure on a USB Boot Device. Arguments: Arg1: 0000000000001013, USB3_WER_BUGCODE_USBXHCI_DEQUEUEPOINTER_MISMATCH_AFTER_COMMAND_ABORT After command abort completion, the command ring dequeue pointer reported by the controller is incorrect. Arg2: ffffd00135ee9960, XHCI_LIVEDUMP_CONTEXT Arg3: 0000000000000000, 0 Arg4: 0000000000000000, 0 Debugging Details: ------------------ HARDWARE_VENDOR_ID: VEN_1B21 HARDWARE_DEVICE_ID: DEV_1142 HARDWARE_REV_ID: REV_0000 HARDWARE_ID: VEN_1B21&DEV_1142&REV_0000 DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT BUGCHECK_STR: 0x144 PROCESS_NAME: System CURRENT_IRQL: 0 ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre LAST_CONTROL_TRANSFER: from fffff8007b0c5ca7 to fffff8007b0e9dac STACK_TEXT: ffffd001`35ee93e0 fffff800`7b0c5ca7 : 00000000`00000005 ffffe000`79d9ce00 fffff800`7b0b8860 00001401`24101004 : USBXHCI!TelemetryData_CreateReport+0xc0 ffffd001`35ee9910 fffff800`7b0c60ef : ffffe000`77fa37e0 ffffd001`35ee9a40 ffffe000`79d9ce00 00000000`00000000 : USBXHCI!Controller_TelemetryReport+0x137 ffffd001`35ee9a00 fffff800`77c6f599 : ffffe000`77fa36e0 fffff802`00000002 00000000`00000002 ffffe000`7b1f3a20 : USBXHCI!Controller_TelemetryReportWorker+0x21f ffffd001`35ee9a80 fffff800`77c7f5f9 : fffff802`d9256200 ffffe000`77fa36e0 ffffe000`77dfc860 ffffe000`72a69880 : Wdf01000!FxWorkItem::WorkItemHandler+0xb5 [d:\th\minkernel\wdf\framework\shared\core\fxworkitem.cpp @ 374] ffffd001`35ee9ac0 fffff802`d8ef5f94 : ffffe000`77fa3660 fffff802`d8ef5a98 00000000`00000000 00000000`00000000 : Wdf01000!FxWorkItem::WorkItemThunk+0x29 [d:\th\minkernel\wdf\framework\shared\core\fxworkitem.cpp @ 439] ffffd001`35ee9b00 fffff802`d8ef56a9 : fffff802`d9256340 ffffe000`72a69740 fffff802`d8ef5ea0 00000000`00000000 : nt!IopProcessWorkItem+0xf4 ffffd001`35ee9b70 fffff802`d8f63e88 : 00000000`00000000 00000000`00000080 fffff802`d9256340 ffffe000`72a69740 : nt!ExpWorkerThread+0xe9 ffffd001`35ee9c00 fffff802`d8fd0326 : ffffd001`35b87180 ffffe000`72a69740 ffffd001`35b93cc0 00000000`00000000 : nt!PspSystemThreadStartup+0x58 ffffd001`35ee9c60 00000000`00000000 : ffffd001`35eea000 ffffd001`35ee4000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16 STACK_COMMAND: kb FOLLOWUP_IP: USBXHCI!TelemetryData_CreateReport+c0 fffff800`7b0e9dac 488b03 mov rax,qword ptr [rbx] SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: USBXHCI!TelemetryData_CreateReport+c0 FOLLOWUP_NAME: MachineOwner MODULE_NAME: USBXHCI IMAGE_NAME: USBXHCI.SYS DEBUG_FLR_IMAGE_TIMESTAMP: 55d2d74f IMAGE_VERSION: 10.0.10240.16461 FAILURE_BUCKET_ID: 0x144_DEQUEUEPOINTER_MISMATCH_AFTER_COMMAND_ABORT BUCKET_ID: 0x144_DEQUEUEPOINTER_MISMATCH_AFTER_COMMAND_ABORT ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:0x144_dequeuepointer_mismatch_after_command_abort FAILURE_ID_HASH: {e83ea7b5-331f-6cff-d5f0-7400b6caa267} Followup: MachineOwner[/quote]

 

Just to make it clear, you say it is not from a BSOD.
From where comes this dump file then?

 

Correct. These dumps originated from the USBXHCI folder under C:\Windows\LiveKernelReports. I was wondering if there's something I can do to solve this?

 

Please read Windbg the basics for debugging crash dumps ​to find out more.

 

Got it. Although, I'm kinda new to debugging and somehow I couldn't find any clues regards to this bugcheck other than 0x144_DEQUEUEPOINTER_MISMATCH_AFTER_COMMAND_ABORT and 0x144_CONTROLLER_GONE in either both dumps. Plus, I even google it for that error and it somehow lead to less results. *Sad

 

Please post the results in code tags

 

The crash is either caused by the windows driver (which I highly doubt), or a 3rd party is 'hiding' so the windows driver is blamed.
Because this is not a BSOD, I wouldn't be worried about it too much.