BSOD every 40 minutes Reference by Pointer

Microsoft (R) Windows Debugger Version 10.0.19041.685 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.

Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff8011c800000 PsLoadedModuleList = 0xfffff8011d42a1d0
Debug session time: Mon Aug 2 01:35:48.424 2021 (UTC - 5:00)
System Uptime: 0 days 0:34:02.129
Loading Kernel Symbols
...............................................................
................................................................
................................................................
................................
Loading User Symbols

Loading unloaded module list
................
For analysis of this file, run !analyze -v
4: kd> !analyze -v

• *
• Bugcheck Analysis *
• *

  ---

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 0000000000000000, Object type of the object whose reference count is being lowered
Arg2: ffffe78b9ffb0050, Object whose reference count is being lowered
Arg3: 0000000000000010, Reserved
Arg4: 0000000000000001, Reserved
The reference count of an object is illegal for the current state of the object.
Each time a driver uses a pointer to an object the driver calls a kernel routine
to increment the reference count of the object. When the driver is done with the
pointer the driver calls another kernel routine to decrement the reference count.
Drivers must match calls to the increment and decrement routines. This bugcheck
can occur because an object's reference count goes to zero while there are still
open handles to the object, in which case the fourth parameter indicates the number
of opened handles. It may also occur when the object's reference count drops below zero
whether or not there are open handles to the object, and in that case the fourth parameter
contains the actual value of the pointer references count.

Debugging Details:

KEY_VALUES_STRING: 1

Key  : Analysis.CPU.Sec
Value: 4

Key  : Analysis.DebugAnalysisProvider.CPP
Value: Create: 8007007e on DESKTOP-CGCGK3T

Key  : Analysis.DebugData
Value: CreateObject

Key  : Analysis.DebugModel
Value: CreateObject

Key  : Analysis.Elapsed.Sec
Value: 8

Key  : Analysis.Memory.CommitPeak.Mb
Value: 86

Key  : Analysis.System
Value: CreateObject

BUGCHECK_CODE: 18

BUGCHECK_P1: 0

BUGCHECK_P2: ffffe78b9ffb0050

BUGCHECK_P3: 10

BUGCHECK_P4: 1

BLACKBOXBSD: 1 (!blackboxbsd)

BLACKBOXNTFS: 1 (!blackboxntfs)

BLACKBOXPNP: 1 (!blackboxpnp)

BLACKBOXWINLOGON: 1

PROCESS_NAME: System

LOCK_ADDRESS: fffff8011d444a20 -- (!locks fffff8011d444a20)

Resource @ nt!PiEngineLock (0xfffff8011d444a20) Exclusively owned
Contention Count = 21
Threads: ffffe78ba601e040-01<*>
1 total locks

PNP_TRIAGE_DATA:
Lock address : 0xfffff8011d444a20
Thread Count : 1
Thread address: 0xffffe78ba601e040
Thread wait : 0x1fe88

STACK_TEXT:
fffffe0a3795f4e8 fffff8011cc14a34 : 0000000000000018 0000000000000000 ffffe78b9ffb0050 0000000000000010 : nt!KeBugCheckEx
fffffe0a3795f4f0 fffff8011ca719f6 : ffffe78b9ffb0050 0000000069706e50 0000000000001001 0000000000000fff : nt!ObfReferenceObjectWithTag+0x17de54
fffffe0a3795f530 fffff8011ce39c4b : 00000000c00000bb fffffe0a3795f600 00000000000000ff 0000000000000000 : nt!IoGetAttachedDeviceReferenceWithTag+0x36
fffffe0a3795f560 fffff8011cf507f6 : 00000000c00000bb ffffe78b86c02a60 fffffe0a3795f7a8 ffffe78b86c13de0 : nt!IopSynchronousCall+0x3f
fffffe0a3795f5d0 fffff8011cf506d4 : ffffe78b86c02a60 fffffe0a3795f7a8 ffffe78ba601e040 fffff8011cdd80ce : nt!PnpIrpQueryID+0x56
fffffe0a3795f660 fffff8011cf2452d : ffffe78b86c02a60 fffffe0a3795f7c0 0000000000000000 0000000000000000 : nt!PnpQueryID+0x34
fffffe0a3795f6c0 fffff8011cf26df0 : ffffe78b86c02a60 ffffe78b86c02a60 0000000000000001 0000000000000000 : nt!PiProcessNewDeviceNode+0x11d
fffffe0a3795f890 fffff8011cf21666 : ffffe78b86c02a00 ffffe78bacdf9601 fffffe0a3795f9b0 fffff80100000000 : nt!PipProcessDevNodeTree+0x380
fffffe0a3795f960 fffff8011cb6e25a : 0000000100000003 ffffe78b86c02a60 0000000000000000 ffffe78bacdf9610 : nt!PiRestartDevice+0xba
fffffe0a3795f9b0 fffff8011cab8515 : ffffe78ba601e040 ffffe78b86a8baa0 fffff8011d443340 ffffe78b00000000 : nt!PnpDeviceActionWorker+0x46a
fffffe0a3795fa70 fffff8011cb55875 : ffffe78ba601e040 0000000000000080 ffffe78b86b02080 000000000000018a : nt!ExpWorkerThread+0x105
fffffe0a3795fb10 fffff8011cbfe578 : ffff9981d3fe0180 ffffe78ba601e040 fffff8011cb55820 000000000000018a : nt!PspSystemThreadStartup+0x55
fffffe0a3795fb60 0000000000000000 : fffffe0a37960000 fffffe0a37959000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x28

SYMBOL_NAME: nt!ObfReferenceObjectWithTag+17de54

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

STACK_COMMAND: .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET: 17de54

FAILURE_BUCKET_ID: 0x18_nt!ObfReferenceObjectWithTag

OS_VERSION: 10.0.19041.1

BUILDLAB_STR: vb_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {b6b47bfd-ed1b-fc56-3b01-ddc037f9c59f}

Followup: MachineOwner

4: kd> lmvm nt
Browse full module list
start end module name
fffff8011c800000 fffff8011d846000 nt (pdb symbols) C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\sym\ntkrnlmp.pdb\F526DBB121425697CBBF4FB22502519F1\ntkrnlmp.pdb
Loaded symbol image file: ntkrnlmp.exe
Image path: ntkrnlmp.exe
Image name: ntkrnlmp.exe
Browse all global symbols functions data
Image was built with /Brepro flag.
Timestamp: 553DF94C (This is a reproducible build file hash, not a timestamp)
CheckSum: 00A5F158
ImageSize: 01046000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Information from resource tables: