This is the output from the first minidump in post #3
That's definitely not what my windbg is showing, I'd say you're doing something wrong, here's the full output on my end:
Microsoft (R) Windows Debugger Version 10.0.17134.12 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\dumpcheck\061019-39593-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Path validation summary *
Response Time (ms) Location
Deferred srv*
https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*
https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.24441.amd64fre.win7sp1_ldr.190418-1735
Machine Name:
Kernel base = 0xfffff800
05a55000 PsLoadedModuleList = 0xfffff800
05c8ec90
Debug session time: Mon Jun 10 09:31:50.223 2019 (UTC + 2:00)
System Uptime: 0 days 0:13:53.035
Loading Kernel Symbols
...............................................................
................................................................
................................................................
........
Loading User Symbols
Loading unloaded module list
...........
***
***
Use !analyze -v to get detailed debugging information.
BugCheck 10D, {6, 3, 57ff24aace8, fffffa800ce4a720}
*** WARNING: Unable to verify timestamp for LEqdUsb.Sys
*** ERROR: Module load completed but symbols could not be loaded for LEqdUsb.Sys
Probably caused by : LEqdUsb.Sys ( LEqdUsb+6e0a )
Followup: MachineOwner
---------
4: kd> !analyze -v
***
***
WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000006, A fatal error was made in handling a WDF request. In this case,
Parameter 2 further specifies the type of fatal error that has
been made, as defined by the enumeration WDF_REQUEST_FATAL_ERROR.
Arg2: 0000000000000003, The driver attempted to send a framework request that has
already been sent to an I/O target.
Arg3: 0000057ff24aace8, The WDF request handle value.
Arg4: fffffa800ce4a720, Reserved.
Debugging Details:
------------------
KEY_VALUES_STRING: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 400
BUILD_VERSION_STRING: 7601.24441.amd64fre.win7sp1_ldr.190418-1735
SYSTEM_MANUFACTURER: ASUS
SYSTEM_PRODUCT_NAME: All Series
SYSTEM_SKU: All
SYSTEM_VERSION: System Version
BIOS_VENDOR: American Megatrends Inc.
BIOS_VERSION: 1204
BIOS_DATE: 06/20/2014
BASEBOARD_MANUFACTURER: ASUSTeK COMPUTER INC.
BASEBOARD_PRODUCT: Z97-A
BASEBOARD_VERSION: Rev 1.xx
DUMP_TYPE: 2
BUGCHECK_P1: 6
BUGCHECK_P2: 3
BUGCHECK_P3: 57ff24aace8
BUGCHECK_P4: fffffa800ce4a720
BUGCHECK_STR: 0x10D_6
CPU_COUNT: 8
CPU_MHZ: 1195
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3c
CPU_STEPPING: 3
CPU_MICROCODE: 6,3c,3,0 (F,M,S,R) SIG: 1C'00000000 (cache) 19'00000000 (init)
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 2
ANALYSIS_SESSION_HOST: JASON-PC
ANALYSIS_SESSION_TIME: 06-12-2019 20:14:31.0098
ANALYSIS_VERSION: 10.0.17134.12 amd64fre
LAST_CONTROL_TRANSFER: from fffff88000e133d3 to fffff80005ae8aa0
STACK_TEXT:
fffff880
035d2448 fffff880
00e133d3 : 00000000
0000010d 00000000
00000006 00000000
00000003 0000057f
f24aace8 : nt!KeBugCheckEx
fffff880
035d2450 fffff880
00e11384 : 00000000
00000000 fffffa80
0e615d30 00000000
00000000 fffffa80
0db55020 : Wdf01000!FxIoTarget::SubmitLocked+0xcb
fffff880
035d2500 fffff880
00e12082 : 0000057f
f1996a08 fffffa80
0db55310 fffff880
035d2590 fffffa80
0e6695f0 : Wdf01000!FxIoTarget::Submit+0x60
fffff880
035d2540 fffff880
06316e0a : fffffa80
0ce4a8a0 fffffa80
0db55310 fffffa80
0db55020 fffffa80
0ce4a720 : Wdf01000!imp_WdfRequestSend+0x48e
fffff880
035d25d0 fffffa80
0ce4a8a0 : fffffa80
0db55310 fffffa80
0db55020 fffffa80
0ce4a720 0000057f
f19ea328 : LEqdUsb+0x6e0a
fffff880
035d25d8 fffffa80
0db55310 : fffffa80
0db55020 fffffa80
0ce4a720 0000057f
f19ea328 00000000
00000000 : 0xfffffa80
0ce4a8a0
fffff880
035d25e0 fffffa80
0db55020 : fffffa80
0ce4a720 0000057f
f19ea328 00000000
00000000 00000000
00000000 : 0xfffffa80
0db55310
fffff880
035d25e8 fffffa80
0ce4a720 : 0000057f
f19ea328 00000000
00000000 00000000
00000000 00000000
00000000 : 0xfffffa80
0db55020
fffff880
035d25f0 0000057f
f19ea328 : 00000000
00000000 00000000
00000000 00000000
00000000 fffffa80
0ded52d0 : 0xfffffa80
0ce4a720
fffff880
035d25f8 00000000
00000000 : 00000000
00000000 00000000
00000000 fffffa80
0ded52d0 0000057f
f24aafd8 : 0x0000057f
f19ea328
THREAD_SHA1_HASH_MOD_FUNC: 2058e7c4c679671758a7ec6ccc48d4b5079596f7
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 11d18080234e6723a5beed022680b9b18dace760
THREAD_SHA1_HASH_MOD: 5b7dde6a01f5a21cc18feebd6094981fabc185cd
FOLLOWUP_IP:
LEqdUsb+6e0a
fffff880
06316e0a ?? ???
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: LEqdUsb+6e0a
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: LEqdUsb
IMAGE_NAME: LEqdUsb.Sys
DEBUG_FLR_IMAGE_TIMESTAMP: 5ac3b2fc
STACK_COMMAND: .thread ; .cxr ; kb
FAILURE_BUCKET_ID: X64_0x10D_6_LEqdUsb+6e0a
BUCKET_ID: X64_0x10D_6_LEqdUsb+6e0a
PRIMARY_PROBLEM_CLASS: X64_0x10D_6_LEqdUsb+6e0a
TARGET_TIME: 2019-06-10T07:31:50.000Z
OSBUILD: 7601
OSSERVICEPACK: 1000
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 272
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 7
OSEDITION: Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2019-04-19 04:08:54
BUILDDATESTAMP_STR: 190418-1735
BUILDLAB_STR: win7sp1_ldr
BUILDOSVER_STR: 6.1.7601.24441.amd64fre.win7sp1_ldr.190418-1735
ANALYSIS_SESSION_ELAPSED_TIME: 31d
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:x64_0x10d_6_leqdusb+6e0a
FAILURE_ID_HASH: {32175d8c-281a-17da-b948-77e6640b7865}
Followup: MachineOwner
---------
Again I say, this is 100% related to Logitech's setpoint (fact is that there's been a dramatic improvement after you've updated it!) and both minidumps (3rd & 11th post) are showing LEqdUsb.Sys as the cause.