Question BSOD error every day at 9PM ?

Sep 7, 2022
5
0
10
Microsoft (R) Windows Debugger Version 10.0.25136.1001 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [D:\Minidump\090622-10343-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


Path validation summary *
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff8001e000000 PsLoadedModuleList = 0xfffff8001ec2a230
Debug session time: Tue Sep 6 21:11:07.114 2022 (UTC + 3:00)
System Uptime: 0 days 7:16:28.450
Loading Kernel Symbols
...............................................................
................................................................
................................................................
.......................................................
Loading User Symbols
Loading unloaded module list
.......................
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff8001e3f8590 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:fffffb0dcf7ea010=0000000000000018
0: kd> !analyze -v
***
  • *
  • Bugcheck Analysis *
  • *
***

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: 0000000000000000, Object type of the object whose reference count is being lowered
Arg2: ffffe004974c3080, Object whose reference count is being lowered
Arg3: 0000000000000002, Reserved
Arg4: ffffffffffffffff, 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:
------------------

*** WARNING: Unable to verify checksum for win32k.sys

KEY_VALUES_STRING: 1

Key : Analysis.CPU.mSec
Value: 5671

Key : Analysis.DebugAnalysisManager
Value: Create

Key : Analysis.Elapsed.mSec
Value: 57540

Key : Analysis.Init.CPU.mSec
Value: 483

Key : Analysis.Init.Elapsed.mSec
Value: 18665

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

Key : Bugcheck.Code.DumpHeader
Value: 0x18

Key : Bugcheck.Code.Register
Value: 0x18

Key : WER.OS.Branch
Value: vb_release

Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z

Key : WER.OS.Version
Value: 10.0.19041.1


FILE_IN_CAB: 090622-10343-01.dmp

BUGCHECK_CODE: 18

BUGCHECK_P1: 0

BUGCHECK_P2: ffffe004974c3080

BUGCHECK_P3: 2

BUGCHECK_P4: ffffffffffffffff

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System

LOCK_ADDRESS: fffff8001ec44b00 -- (!locks fffff8001ec44b00)

Resource @ nt!PiEngineLock (0xfffff8001ec44b00) Exclusively owned
Contention Count = 39
NumberOfExclusiveWaiters = 1
Threads: ffffe004a229b080-01<*>

Threads Waiting On Exclusive Access:
ffffe004993f3040
1 total locks

PNP_TRIAGE_DATA:
Lock address : 0xfffff8001ec44b00
Thread Count : 1
Thread address: 0xffffe004a229b080
Thread wait : 0x19931c

STACK_TEXT:
fffffb0dcf7ea008 fffff8001e424913 : 0000000000000018 0000000000000000 ffffe004974c3080 0000000000000002 : nt!KeBugCheckEx
fffffb0dcf7ea010 fffff8001e23334e : ffffe00493e8f670 ffffde0b29b75c00 0000000000000000 0000000000000000 : nt!ObfDereferenceObjectWithTag+0x1f15b3
fffffb0dcf7ea050 fffff8001e36da34 : ffffe00493e8f670 ffffde0b29b75c00 0000000000000001 000000000000000a : nt!HalPutDmaAdapter+0xe
fffffb0dcf7ea080 fffff8001e7411de : ffffe00493e8f670 ffffffff00000000 0000000000000000 fffff8001ec44a60 : nt!PnpRemoveLockedDeviceNode+0x248
fffffb0dcf7ea0e0 fffff8001e740f13 : ffffe00493e8f670 fffffb0dcf7ea160 0000000000000000 0000000000000000 : nt!PnpDeleteLockedDeviceNode+0x4e
fffffb0dcf7ea120 fffff8001e743855 : ffffe004923cddd0 0000000000000002 ffffe004a1c1f010 0000000000000000 : nt!PnpDeleteLockedDeviceNodes+0xf7
fffffb0dcf7ea1a0 fffff8001e743694 : 0000000000000000 fffffb0dcf7ea220 ffffe004923cddd0 0000000000000000 : nt!PipRemoveDevicesInRelationList+0x8d
fffffb0dcf7ea1f0 fffff8001e743129 : ffffe004a1c1f010 0000000000000001 ffffe004a1c1f010 0000000000000008 : nt!PnpDelayedRemoveWorker+0x114
fffffb0dcf7ea230 fffff8001e36e504 : 0000000000000008 0000000000000001 0000000000000000 ffffe00493e90010 : nt!PnpChainDereferenceComplete+0xfd
fffffb0dcf7ea260 fffff8001e742446 : 0000000000000009 fffffb0dcf7ea359 ffffbe0fb94625a0 0000000000000001 : nt!PnpIsChainDereferenced+0xac
fffffb0dcf7ea2e0 fffff8001e73cd67 : fffffb0dcf7ea420 ffffe00493e90000 fffffb0dcf7ea400 ffffbe0f00000009 : nt!PnpProcessQueryRemoveAndEject+0x28a
fffffb0dcf7ea3c0 fffff8001e7079fe : ffffbe0fcfc44110 ffffbe0fd01a40a0 ffffe0046fcdac00 0000000000000000 : nt!PnpProcessTargetDeviceEvent+0xeb
fffffb0dcf7ea3f0 fffff8001e2e87f5 : ffffe004a229b080 ffffe004a229b080 ffffe0046fcdacd0 ffffe004a1aef0f0 : nt!PnpDeviceEventWorker+0x2ce
fffffb0dcf7ea470 fffff8001e34edc5 : ffffe004a229b080 0000000000000080 ffffe0046fcd1080 00b0005000000000 : nt!ExpWorkerThread+0x105
fffffb0dcf7ea510 fffff8001e3ffbe8 : ffff9780bd691180 ffffe004a229b080 fffff8001e34ed70 0000000000000080 : nt!PspSystemThreadStartup+0x55
fffffb0dcf7ea560 0000000000000000 : fffffb0dcf7eb000 fffffb0dcf7e4000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x28


SYMBOL_NAME: nt!ObfDereferenceObjectWithTag+1f15b3

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

IMAGE_VERSION: 10.0.19041.1826

STACK_COMMAND: .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET: 1f15b3

FAILURE_BUCKET_ID: 0x18_OVER_DEREFERENCE_nt!ObfDereferenceObjectWithTag

OS_VERSION: 10.0.19041.1

BUILDLAB_STR: vb_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {4139309c-4e9f-52f0-ac5e-4041e7a86a20}

Followup: MachineOwner
---------
 
have you looked in Task Scheduler to see if anything timed to run at that time?

  1. Open Windows File Explore
  2. Navigate to C:\Windows\Minidump
  3. Copy the mini-dump files out onto your Desktop
  4. Do not use Winzip, use the built in facility in Windows
  5. Select those files on your Desktop, right click them and choose 'Send to' - Compressed (zipped) folder
  6. Upload the zip file to the Cloud (OneDrive, DropBox . . . etc.)
  7. Then post a link here to the zip file, so we can take a look for you . . .
What are specs of the PC?
 
Not a problem. Up until recently i would get a friend to convert the dumps and he would have discovered in several hours it wasn't shared, and then had to reply here and say he couldn't access. Me doing it all speeds things up in that regard. debugging just takes time to run...

Conversion of dumps
results - click run as Fiddle to look at report
5 dumps, hope one tells us something useful

File: 090622-10343-01.dmp (Sep 7 2022 - 04:11:07)
BugCheck: [REFERENCE_BY_POINTER (18)]
Probably caused by: memory_corruption (Process: System)
Uptime: 0 Day(s), 7 Hour(s), 16 Min(s), and 28 Sec(s)

File: 090522-10781-01.dmp (Sep 6 2022 - 04:14:02)
BugCheck: [REFERENCE_BY_POINTER (18)]
Probably caused by: memory_corruption (Process: System)
Uptime: 0 Day(s), 23 Hour(s), 39 Min(s), and 18 Sec(s)

File: 090422-10328-01.dmp (Sep 5 2022 - 04:34:12)
BugCheck: [REFERENCE_BY_POINTER (18)]
Probably caused by: memory_corruption (Process: System)
Uptime: 1 Day(s), 0 Hour(s), 27 Min(s), and 15 Sec(s)

File: 090322-10468-01.dmp (Sep 4 2022 - 00:17:44)
BugCheck: [REFERENCE_BY_POINTER (18)]
Probably caused by: memory_corruption (Process: System)
Uptime: 0 Day(s), 19 Hour(s), 51 Min(s), and 27 Sec(s)

File: 090322-10156-01.dmp (Sep 4 2022 - 04:06:25)
BugCheck: [REFERENCE_BY_POINTER (18)]
Probably caused by: memory_corruption (Process: System)
Uptime: 0 Day(s), 3 Hour(s), 47 Min(s), and 23 Sec(s)

its the same action all 5 times.
it looks like maybe a WIFI dongle?

you have a stack of drivers I don't know
Dameware virtual keyboard , remote control software
Apr 12 2007dwvkbd64.sys
Mar 17 2008DamewareMini.sys
their age tells me they probably not windows 10 devices
No idea what this is, doesn't show in Google search -
know of anything called CleanerX64?
how many Antivirus have you got?
all of these are suspect, searching for names of some show Russian results
Jul 22 2021EsPsProtect64.sys
Jul 22 2021EsSiphLdr64.sys
Jul 22 2021FSRegFlt.sys
Jul 22 2021sicore.sys
Jul 22 2021SIFSDI.sys
Jul 22 2021SIFSFlt.sys
Jul 22 2021sinetfilter.sys

I would have thought Kaspersky catch a virus coming in though

Try running this and see if any new drivers - https://www.intel.com.au/content/www/au/en/support/intel-driver-support-assistant.html
 
Not a problem. Up until recently i would get a friend to convert the dumps and he would have discovered in several hours it wasn't shared, and then had to reply here and say he couldn't access. Me doing it all speeds things up in that regard. debugging just takes time to run...



Thanks for replay, strange it happen every day at 9 PM
 
have you looked in Task Scheduler to see if anything set to run at that time?

did you get any updates or new programs on Sept 4th?

another thought is do a clean boot
Try a clean boot and see if it changes anything - make sure to read instructions and make sure NOT to disable any microsoft services or windows won't load right - https://support.microsoft.com/en-au/help/929135/how-to-perform-a-clean-boot-in-windows

it doesn't delete anything, it just stops non microsoft programs loading with windows, easily reversed.

if clean boot fixes it, it shows its likely a startup program. You should, over a number of startups. restart the programs you stopped to isolate the one that is to blame.