R
roddy14
Hello, when I connect my TWS bluetooth headset I immediately get a BSOD. This happens only with a particular bluetooth tws set (Haylou T16). I have lots of other bluetooth headsets and speakers but none of them causing BSOD.
I couldn't figure out the cause of the problem, thanks for your help.
Here is my minidump file:
Microsoft (R) Windows Debugger Version 10.0.20153.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\Oguzhan\Desktop\103020-7703-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 18362 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 18362.1.amd64fre.19h1_release.190318-1202
Machine Name:
Kernel base = 0xfffff807`6fa00000 PsLoadedModuleList = 0xfffff807`6fe461b0
Debug session time: Fri Oct 30 14:58:19.361 2020 (UTC + 3:00)
System Uptime: 0 days 2:20:34.092
Loading Kernel Symbols
...............................................................
................................................................
................................................................
................
Loading User Symbols
Loading unloaded module list
.............
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff807`6fbc2ce0 48894c2408 mov qword ptr [rsp+8],rcx ss:fffff807`76053d10=000000000000007f
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: fffff80776053e50
Arg3: fffffc0e97b00fd0
Arg4: fffff8076fa5a492
Debugging Details:
------------------
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 5593
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-J8SNFFM
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.mSec
Value: 34418
Key : Analysis.Memory.CommitPeak.Mb
Value: 91
Key : Analysis.System
Value: CreateObject
Key : WER.OS.Branch
Value: 19h1_release
Key : WER.OS.Timestamp
Value: 2019-03-18T12:02:00Z
Key : WER.OS.Version
Value: 10.0.18362.1
ADDITIONAL_XML: 1
OS_BUILD_LAYERS: 1
BUGCHECK_CODE: 7f
BUGCHECK_P1: 8
BUGCHECK_P2: fffff80776053e50
BUGCHECK_P3: fffffc0e97b00fd0
BUGCHECK_P4: fffff8076fa5a492
TRAP_FRAME: fffff80776053e50 -- (.trap 0xfffff80776053e50)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000008 rbx=0000000000000000 rcx=ffffe70d51402340
rdx=ffffe70d5fdf8000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8076fa5a492 rsp=fffffc0e97b00fd0 rbp=000000004143324c
r8=ffffe70d5fdfab20 r9=0000000000000000 r10=ffffe70d5fdf8000
r11=0000000000000fff r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!ExFreeHeapPool+0x352:
fffff807`6fa5a492 e88987fbff call nt!RtlpHpLfhSubsegmentFreeBlock (fffff807`6fa12c20)
Resetting default scope
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_OVERFLOW: Stack Limit: fffffc0e97b01000. Use (kF) and (!stackusage) to investigate stack usage.
STACKUSAGE_FUNCTION: The function at address 0xfffff80788bf15eb was blamed for the stack overflow. It is using 11648 bytes of stack total in 52 instances (likely recursion).
STACK_COMMAND: .trap 0xfffff80776053e50 ; kb
SYMBOL_NAME: bthport!HCI_ProcessLinkLEConnectionParameterUpdate+5c7
MODULE_NAME: bthport
IMAGE_NAME: bthport.sys
IMAGE_VERSION: 10.0.18362.693
BUCKET_ID_FUNC_OFFSET: 5c7
FAILURE_BUCKET_ID: 0x7f_8_STACK_USAGE_RECURSION_bthport!HCI_ProcessLinkLEConnectionParameterUpdate
OS_VERSION: 10.0.18362.1
BUILDLAB_STR: 19h1_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {90be4568-4fb7-da63-7ffe-93dedfab39a2}
Followup: MachineOwner
---------
Continue reading...
I couldn't figure out the cause of the problem, thanks for your help.
Here is my minidump file:
Microsoft (R) Windows Debugger Version 10.0.20153.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\Oguzhan\Desktop\103020-7703-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 18362 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 18362.1.amd64fre.19h1_release.190318-1202
Machine Name:
Kernel base = 0xfffff807`6fa00000 PsLoadedModuleList = 0xfffff807`6fe461b0
Debug session time: Fri Oct 30 14:58:19.361 2020 (UTC + 3:00)
System Uptime: 0 days 2:20:34.092
Loading Kernel Symbols
...............................................................
................................................................
................................................................
................
Loading User Symbols
Loading unloaded module list
.............
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff807`6fbc2ce0 48894c2408 mov qword ptr [rsp+8],rcx ss:fffff807`76053d10=000000000000007f
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: fffff80776053e50
Arg3: fffffc0e97b00fd0
Arg4: fffff8076fa5a492
Debugging Details:
------------------
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 5593
Key : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-J8SNFFM
Key : Analysis.DebugData
Value: CreateObject
Key : Analysis.DebugModel
Value: CreateObject
Key : Analysis.Elapsed.mSec
Value: 34418
Key : Analysis.Memory.CommitPeak.Mb
Value: 91
Key : Analysis.System
Value: CreateObject
Key : WER.OS.Branch
Value: 19h1_release
Key : WER.OS.Timestamp
Value: 2019-03-18T12:02:00Z
Key : WER.OS.Version
Value: 10.0.18362.1
ADDITIONAL_XML: 1
OS_BUILD_LAYERS: 1
BUGCHECK_CODE: 7f
BUGCHECK_P1: 8
BUGCHECK_P2: fffff80776053e50
BUGCHECK_P3: fffffc0e97b00fd0
BUGCHECK_P4: fffff8076fa5a492
TRAP_FRAME: fffff80776053e50 -- (.trap 0xfffff80776053e50)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000008 rbx=0000000000000000 rcx=ffffe70d51402340
rdx=ffffe70d5fdf8000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8076fa5a492 rsp=fffffc0e97b00fd0 rbp=000000004143324c
r8=ffffe70d5fdfab20 r9=0000000000000000 r10=ffffe70d5fdf8000
r11=0000000000000fff r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!ExFreeHeapPool+0x352:
fffff807`6fa5a492 e88987fbff call nt!RtlpHpLfhSubsegmentFreeBlock (fffff807`6fa12c20)
Resetting default scope
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: System
STACK_OVERFLOW: Stack Limit: fffffc0e97b01000. Use (kF) and (!stackusage) to investigate stack usage.
STACKUSAGE_FUNCTION: The function at address 0xfffff80788bf15eb was blamed for the stack overflow. It is using 11648 bytes of stack total in 52 instances (likely recursion).
STACK_COMMAND: .trap 0xfffff80776053e50 ; kb
SYMBOL_NAME: bthport!HCI_ProcessLinkLEConnectionParameterUpdate+5c7
MODULE_NAME: bthport
IMAGE_NAME: bthport.sys
IMAGE_VERSION: 10.0.18362.693
BUCKET_ID_FUNC_OFFSET: 5c7
FAILURE_BUCKET_ID: 0x7f_8_STACK_USAGE_RECURSION_bthport!HCI_ProcessLinkLEConnectionParameterUpdate
OS_VERSION: 10.0.18362.1
BUILDLAB_STR: 19h1_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {90be4568-4fb7-da63-7ffe-93dedfab39a2}
Followup: MachineOwner
---------
Continue reading...