Question Countless BSOD, unsure of cause

[Unnamed568]

I bought a new pc recently and I've gotten BSOD basically right from the beginning. I've gotten various Stop Codes such as KERNEL_SECURITY_CHECK_FAILURE, SYSTEM_SERVICE_EXCEPTION, APC_INDEX_MISMATCH, REFERENCE_BY_POINTER and very often IRQL_NOT_LESS_OR_EQUAL.

I feel like I've tried everything so far and its really eating away at me now. I've updated all drivers, even let 3rd party software check it. I've done a clean windows install, ran a memtest and a memorytest86. All with 0 errors. I've ran a sfc /scannow all to on avail. I've tried looking at the mini dumps that windows creates after the crashes but they don't seem to point at a single cause. I've updated BIOS as well.

The system I have is:

Motherboard: ASUS PRIME B450M-A
GPU: Gigabyte GeForce GTX 1660 SUPER OC 6144MB
CPU: AMD Ryzen 5 3600
RAM: Team Group Vulcan Z T-Force 16GB (2x8GB) DDR4 PC4-24000C16
Storage: Samsung 250GB 860 EVO SSD, Seagate BarraCuda 1TB 7200RPM
Power Supply: Kolink Core Series 500W 80 Plus

Here are some examples of the mini dumps I've received:

REFERENCE_BY_POINTER (18)
Arguments:
Arg1: ffffac8c6e2af7a0, Object type of the object whose reference count is being lowered
Arg2: ffffac8c81c9e3e0, Object whose reference count is being lowered
Arg3: 0000000000000001, Reserved
Arg4: 0000000000000031, 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.mSec
Value: 2858

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

Key : Analysis.DebugData
Value: CreateObject

Key : Analysis.DebugModel
Value: CreateObject

Key : Analysis.Elapsed.mSec
Value: 5183

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

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: 18

BUGCHECK_P1: ffffac8c6e2af7a0

BUGCHECK_P2: ffffac8c81c9e3e0

BUGCHECK_P3: 1

BUGCHECK_P4: 31

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: nvcontainer.exe

STACK_TEXT:
ffffcf83a0829908 fffff80471821564 : 0000000000000018 ffffac8c6e2af7a0 ffffac8c81c9e3e0 0000000000000001 : nt!KeBugCheckEx
ffffcf83a0829910 fffff80471c09037 : 00000000ffff8001 ffffac8c81c9e3b0 ffffac8c81c9e3b0 ffffd186430f1840 : nt!ObfDereferenceObjectWithTag+0x17eeb4
ffffcf83a0829950 fffff80471c0e32e : 0000000000000d38 000000efcfeff300 ffffcf8300000002 ffffcf83a0829a00 : nt!ObCloseHandleTableEntry+0x2c7
ffffcf83a0829a90 fffff804717d4258 : ffffac8c77588080 000000efcfeff408 ffffcf83a0829b80 ffffffffffb38db0 : nt!NtClose+0xde
ffffcf83a0829b00 00007ff90e9bc254 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x28
000000efcfeff508 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007ff90e9bc254 SYMBOL_NAME: nt!ObfDereferenceObjectWithTag+17eeb4 MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe IMAGE_VERSION: 10.0.18362.1082 STACK_COMMAND: .thread ; .cxr ; kb BUCKET_ID_FUNC_OFFSET: 17eeb4 FAILURE_BUCKET_ID: 0x18_CORRUPT_REF_COUNT_nt!ObfDereferenceObjectWithTag OS_VERSION: 10.0.18362.1 BUILDLAB_STR: 19h1_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {fa6b3516-71cb-1e92-b987-b8bebd3458ac} Followup: MachineOwner [/QUOTE] [QUOTE] IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 0000000000005dc8, memory referenced Arg2: 00000000000000ff, IRQL Arg3: 000000000000004b, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: fffff80747a4b31b, address which referenced memory Debugging Details: ------------------ KEY_VALUES_STRING: 1 Key : Analysis.CPU.mSec Value: 3405 Key : Analysis.DebugAnalysisProvider.CPP Value: Create: 8007007e on DESKTOP-20U48SK Key : Analysis.DebugData Value: CreateObject Key : Analysis.DebugModel Value: CreateObject Key : Analysis.Elapsed.mSec Value: 7590 Key : Analysis.Memory.CommitPeak.Mb Value: 108 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: a BUGCHECK_P1: 5dc8 BUGCHECK_P2: ff BUGCHECK_P3: 4b BUGCHECK_P4: fffff80747a4b31b WRITE_ADDRESS: 0000000000005dc8 BLACKBOXBSD: 1 (!blackboxbsd) BLACKBOXNTFS: 1 (!blackboxntfs) BLACKBOXPNP: 1 (!blackboxpnp) BLACKBOXWINLOGON: 1 PROCESS_NAME: System TRAP_FRAME: ffff9d86bbe7d780 -- (.trap 0xffff9d86bbe7d780) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=000000012e2819e8 rbx=0000000000000000 rcx=0000000000000001 rdx=000000000000028e rsi=0000000000000000 rdi=0000000000000000 rip=fffff80747a4b31b rsp=ffff9d86bbe7d910 rbp=ffff9d86bbe7da10 r8=8000000000000000 r9=ffff9d86bbe7db60 r10=000000012e4eacd9 r11=ffff90f8e9200000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up di pl zr na po nc nt!PpmIdlePrepare+0x16b: fffff80747a4b31b 488b86c85d0000 mov rax,qword ptr [rsi+5DC8h] ds:0000000000005dc8=???????????????? Resetting default scope STACK_TEXT: ffff9d86bbe7d638 fffff80747bd4829 : 000000000000000a 0000000000005dc8 00000000000000ff 000000000000004b : nt!KeBugCheckEx ffff9d86bbe7d640 fffff80747bd0b69 : 0000000000000000 0000000000000000 0000000000007ebb 0000000000000000 : nt!KiBugCheckDispatch+0x69 ffff9d86bbe7d780 fffff80747a4b31b : 0000000000108f32 0000000000989680 ffff800429bd0010 000000012e4eaa4a : nt!KiPageFault+0x469 ffff9d86bbe7d910 fffff80747a4a206 : 0000000000000003 0000000000000002 ffff800429bd0100 0000000000000008 : nt!PpmIdlePrepare+0x16b ffff9d86bbe7db00 fffff80747bc6484 : ffffffff00000000 ffffa100f0479180 ffff80042e2f8080 0000000000000948 : nt!PoIdle+0x1e6 ffff9d86bbe7dc60 0000000000000000 : ffff9d86bbe7e000 ffff9d86bbe78000 0000000000000000 0000000000000000 : nt!KiIdleLoop+0x44 SYMBOL_NAME: nt!PpmIdlePrepare+16b MODULE_NAME: nt IMAGE_NAME: ntkrnlmp.exe STACK_COMMAND: .thread ; .cxr ; kb BUCKET_ID_FUNC_OFFSET: 16b FAILURE_BUCKET_ID: AV_CODE_AV_nt!PpmIdlePrepare OS_VERSION: 10.0.18362.1 BUILDLAB_STR: 19h1_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {0722116b-c23b-c6c2-0c96-05693152d11a} Followup: MachineOwner --------- [/QUOTE] [QUOTE] SYSTEM_SERVICE_EXCEPTION (3b) An exception happened while executing a system service routine. Arguments: Arg1: 00000000c0000005, Exception code that caused the bugcheck Arg2: fffff803771e392c, Address of the instruction which caused the bugcheck Arg3: ffff9401481ed910, Address of the context record for the exception that caused the bugcheck Arg4: 0000000000000000, zero. Debugging Details: ------------------ *** WARNING: Unable to verify checksum for win32k.sys KEY_VALUES_STRING: 1 Key : Analysis.CPU.mSec Value: 5499 Key : Analysis.DebugAnalysisProvider.CPP Value: Create: 8007007e on DESKTOP-20U48SK Key : Analysis.DebugData Value: CreateObject Key : Analysis.DebugModel Value: CreateObject Key : Analysis.Elapsed.mSec Value: 13883 Key : Analysis.Memory.CommitPeak.Mb Value: 78 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: 3b BUGCHECK_P1: c0000005 BUGCHECK_P2: fffff803771e392c BUGCHECK_P3: ffff9401481ed910 BUGCHECK_P4: 0 CONTEXT: ffff9401481ed910 -- (.cxr 0xffff9401481ed910) rax=00000000000000cc rbx=ffffd40c853caa60 rcx=000000000000005d rdx=00000000001f0003 rsi=0000000000000005 rdi=ffffd40c853caa90 rip=fffff803771e392c rsp=ffff9401481ee300 rbp=ffff9401481ee340 r8=d40c853caa642459 r9=0000000000000000 r10=0000000000000001 r11=ffff9401481ee280 r12=000000000000000a r13=0000000000000004 r14=fffff80376c00000 r15=0000000000000001 iopl=0 nv up ei pl nz na pe nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00050202 nt!ObWaitForMultipleObjects+0x1fc: fffff803771e392c 4d8b4120 mov r8,qword ptr [r9+20h] ds:002b:0000000000000020=???????????????? Resetting default scope BLACKBOXBSD: 1 (!blackboxbsd) BLACKBOXNTFS: 1 (!blackboxntfs) BLACKBOXPNP: 1 (!blackboxpnp) BLACKBOXWINLOGON: 1 CUSTOMER_CRASH_COUNT: 1 PROCESS_NAME: nvsphelper64.exe STACK_TEXT: ffff9401481ee300 fffff803771e36f5 : 0000000000000000 0000000000000000 ffff9401481ee848 ffff9c8151879180 : nt!ObWaitForMultipleObjects+0x1fc ffff9401481ee800 fffff80376dd4258 : 00000084b29ff478 ffffd40c85620080 ffffd40c85620080 00000084b29ff108 : nt!NtWaitForMultipleObjects+0x105 ffff9401481eea90 00007ffc099bcbc4 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x28 00000084b29ff0e8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007ffc099bcbc4


SYMBOL_NAME: nt!ObWaitForMultipleObjects+1fc

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

IMAGE_VERSION: 10.0.18362.1082

STACK_COMMAND: .cxr 0xffff9401481ed910 ; kb

BUCKET_ID_FUNC_OFFSET: 1fc

FAILURE_BUCKET_ID: 0x3B_c0000005_nt!ObWaitForMultipleObjects

OS_VERSION: 10.0.18362.1

BUILDLAB_STR: 19h1_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {b1f995c7-68df-344c-8a4a-f9e68abe4d74}

Followup: MachineOwner
---------

 

[PC Tailor]

Welcome to the forums!

Can you please post all of the dump files onto a file sharing site and sending us the link to download them?
I would also undo any third party driver updates, they tend to get them wrong and cause more trouble.

 

[Unnamed568]

Here are some of the mini dumps I received today.

https://bit.ly/3jjVzgY

Thank you for your reply!

 

[PC Tailor]

I have run the dump file(s) and you can see the full report(s) in the link below.
If you are prompted to "Run only if trusted" simply click play/run and the html will be viewed. This warning is always present.

Report: https://jsfiddle.net/oxguasmt/show/

Summary of findings:

SYSTEM_SERVICE_EXCEPTION
Probably caused by : ntkrnlmp.exe ( nt!ObWaitForMultipleObjects+1fc )
--------------------
IRQL_NOT_LESS_OR_EQUAL
Probably caused by : win32kbase.sys ( win32kbase!EnterCrit+8c )
--------------------
IRQL_NOT_LESS_OR_EQUAL
Probably caused by : ntkrnlmp.exe ( nt!PpmIdlePrepare+16b )
--------------------
DRIVER_IRQL_NOT_LESS_OR_EQUAL
Probably caused by : ntkrnlmp.exe ( nt!KiPageFault+469 )
--------------------
KERNEL_SECURITY_CHECK_FAILURE
Probably caused by : ntkrnlmp.exe ( nt!KiCancelTimer+17d07f )

Power Supply: Kolink Core Series 500W 80 Plus

One thing I can say is this is a fairly poor PSU, and could well be causing potential issues.

I've done a clean windows install

Well all of the bugchecks in those dumps are typically software based issues. So the fact that you've reinstalled means either we could be looking at a hardware related problem or the offending software is being reinstalled.

KERNEL_SECURITY_CHECK_FAILURE with a parm 1 of 3 becomes more difficult to problem solve and something I will still be in training to help with, so the report above may help someone else visiting the forum.

What I would potentially look at simply from those is:

rtwlanu.sys

Realtek

Realtek Wirless USB 2.0 Adapter Driver

23/05/2018

In 5 of 5 dumps

It appears to be potentially out of date and appears as a loaded module in all 5 of the dumps files that you shared. Everything interacts with network adapters, especially USB ones. Just don't update them using an updater app. Get them directly. Asides that I would consider removing the device and driver altogether if there is no later version.

The Chipset drivers also appear to be potentially out of date and could still persist after a clean windows install being as it's core hardware.

I admit, the nature of these BSOD I am in still in training for, however they are just a couple of points I have raised above that may help - but the report could be useful for someone else visiting the forums. You could also potentially posting over at Sysnative who have some experts on the case. I only say the above as it could make sense in spite of the fact that you have reinstalled windows and the issue persisted. Other than that, I will take a step back and hopefully someone else might be able to help.

 

[PC Tailor]

Editted above comment with some info on the Realtek driver I mentioned.

 

[Unnamed568]

I tried everything you said this morning including removing the USB network adapter and uninstalling the drivers related to it. I've connected now via an ethernet cable but the problem seems to have persisted as I still continue to get similar BSOD.

I'm now in the process of reinstalling windows fresh again to see if the problem returns after uninstalling the USB network drivers.

Thank you for your help so far.

 

[Unnamed568]

Quick update. I did a fresh reset of windows and everything seemed to be fine. I started installing battle.net and World of Warcraft (Which is what I bought this PC for in the first place). And I got the following crash report:

Spoiler: Crash Report

KERNEL_AUTO_BOOST_LOCK_ACQUISITION_WITH_RAISED_IRQL (192)
A lock tracked by AutoBoost was acquired while executing at DISPATCH_LEVEL or
above.
Arguments:
Arg1: ffffd7854827d080, The address of the thread.
Arg2: ffff83aa806141f0, The lock address.
Arg3: 0000000000000000, The IRQL at which the lock was acquired.
Arg4: 0000000000000000, Reserved.

Debugging Details:
------------------

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

KEY_VALUES_STRING: 1

Key : Analysis.CPU.mSec
Value: 6015

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

Key : Analysis.DebugData
Value: CreateObject

Key : Analysis.DebugModel
Value: CreateObject

Key : Analysis.Elapsed.mSec
Value: 7337

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

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: 192

BUGCHECK_P1: ffffd7854827d080

BUGCHECK_P2: ffff83aa806141f0

BUGCHECK_P3: 0

BUGCHECK_P4: 0

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: Battle.net.exe

STACK_TEXT:
fffffa01be3a2ab8 fffff8013faa1ab5 : 0000000000000192 ffffd7854827d080 ffff83aa806141f0 0000000000000000 : nt!KeBugCheckEx
fffffa01be3a2ac0 ffff839169df2ec7 : 000000000000001f fffffa0100000000 fffff8013fa842e0 ffff83aa80602a60 : nt!ExAcquirePushLockExclusiveEx+0x145
fffffa01be3a2b00 ffff839169df2d39 : fffffa01be3a2c08 0000000000000000 0000000000000000 0000000000000000 : win32kbase!GdiHandleEntryDirectory::AcquireEntryLock+0xc7
fffffa01be3a2b50 ffff839169df347c : 0000000000001a98 ffff83aa80603cf0 0000000000000000 fffffa01be3a2c90 : win32kbase!HANDLELOCK::vLockHandle+0x79
fffffa01be3a2b90 ffff839169df4837 : ffff83aa86045150 ffff83aa86045150 0000000000000000 0000000063010ba0 : win32kbase!XDCOBJ::bCleanDC+0x54c
fffffa01be3a2d10 ffff839169e3e650 : fffffa01be3a2dd9 0000000063010ba0 ffff83aa820d9590 0000000000000000 : win32kbase!ReleaseCacheDC+0x277
fffffa01be3a2da0 ffff839169c74de4 : fffffa01be3a3928 0000000000000000 fffffa01be3a39e0 0000000063010ba0 : win32kbase!UserReleaseDC+0xe0
fffffa01be3a2e40 ffff839169ed2d75 : 0000000000000000 ffffd78545b50078 fffffa01be3a3a20 fffffa01be3a3928 : win32kfull!DxgkEngReleaseDC+0x34
fffffa01be3a2e70 fffff8014ca03b67 : 0000000000000000 fffffa01be3a3010 fffffa01be3a39e0 fffffa01be3a39e0 : win32kbase!DxgkEngReleaseDCApiExt+0x35
fffffa01be3a2ea0 fffff8014c9f9e58 : ffff839169fba0e0 fffffa01be3a3380 0000000063010ba0 ffffc18db50c2660 : dxgkrnl!SubmitPresentHistoryToken+0x407
fffffa01be3a3260 fffff8014c9fdeb3 : ffffc18db50c2660 ffffc18db50c2660 ffffc18db83b7de0 ffffd78545b50000 : dxgkrnl!DXGCONTEXT:resent+0x12b8
fffffa01be3a3840 fffff8013fbd4258 : ffffd7854827d080 ffffd7854827d080 0000000012460000 ffffd78548d5cb60 : dxgkrnl!DxgkPresent+0x813
fffffa01be3a3b00 00007ffb4a954004 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x28
000000001244e238 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007ffb`4a954004


SYMBOL_NAME: win32kbase!GdiHandleEntryDirectory::AcquireEntryLock+c7

MODULE_NAME: win32kbase

IMAGE_NAME: win32kbase.sys

IMAGE_VERSION: 10.0.18362.1082

STACK_COMMAND: .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET: c7

FAILURE_BUCKET_ID: 0x192_win32kbase!GdiHandleEntryDirectory::AcquireEntryLock

OS_VERSION: 10.0.18362.1

BUILDLAB_STR: 19h1_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {2db5128c-ce77-f1b8-7b7b-9089fcfa474e}

Followup: MachineOwner
---------

It says process_name: battlenet.exe. Is this a coincidence and it was just the program that was running at the time or is it related? I am really not an expert on these things.

 

[Unnamed568]

Another update, I've removed one stick of RAM and very quickly received the following crash: ATTEMPTED_WRITE_TO_READONLY_MEMORY with the following minidump:

Spoiler: Crash report

ATTEMPTED_WRITE_TO_READONLY_MEMORY (be)
An attempt was made to write to readonly memory. The guilty driver is on the
stack trace (and is typically the current instruction pointer).
When possible, the guilty driver's name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff8035fee653d, Virtual address for the attempted write.
Arg2: 090000021f203121, PTE contents.
Arg3: ffff82808fc616a0, (reserved)
Arg4: 000000000000000a, (reserved)

Debugging Details:
------------------

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

KEY_VALUES_STRING: 1

Key : Analysis.CPU.mSec
Value: 5421

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

Key : Analysis.DebugData
Value: CreateObject

Key : Analysis.DebugModel
Value: CreateObject

Key : Analysis.Elapsed.mSec
Value: 10132

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

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: be

BUGCHECK_P1: fffff8035fee653d

BUGCHECK_P2: 90000021f203121

BUGCHECK_P3: ffff82808fc616a0

BUGCHECK_P4: a

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System

TRAP_FRAME: ffff82808fc616a0 -- (.trap 0xffff82808fc616a0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=ffff8500240c8180
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8035b6b2ca0 rsp=ffff82808fc61830 rbp=ffff8500240c8180
r8=0000000000000102 r9=0000000000000000 r10=fffff8035a188800
r11=0000000000000004 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!KiTryUnwaitThread+0x50:
fffff8035b6b2ca0 f0480fba6b4000 lock bts qword ptr [rbx+40h],0 ds:0000000000000040=????????????????
Resetting default scope

STACK_TEXT:
ffff82808fc614b8 fffff8035b8495ef : 00000000000000be fffff8035fee653d 090000021f203121 ffff82808fc616a0 : nt!KeBugCheckEx
ffff82808fc614c0 fffff8035b6589da : 090000021f203121 0000000000000003 ffff82808fc61600 0000000000000000 : nt!MiRaisedIrqlFault+0x1355ff
ffff82808fc61500 fffff8035b7d0a5e : 0000000000000000 fffff8036ad5a246 0000000000000001 0000000000000002 : nt!MmAccessFault+0x48a
ffff82808fc616a0 fffff8035b6b2ca0 : 00000001ffffffff ffffffff00000000 0000000700000000 0000000000000003 : nt!KiPageFault+0x35e
ffff82808fc61830 fffff8035b651686 : ffffa883d65b61c8 0000000200000000 ffffa883d65b6290 ffffa883d65b61c0 : nt!KiTryUnwaitThread+0x50
ffff82808fc61890 fffff8035b651262 : ffffa883d65b61c0 000000024d8d56dc 0000000100000002 ffffa883da133010 : nt!KiTimerWaitTest+0x1b6
ffff82808fc61940 fffff8035b650059 : 0000000000000014 0000000000989680 0000000000009363 000000000000007b : nt!KiProcessExpiredTimerList+0xd2
ffff82808fc61a30 fffff8035b7c64be : ffffffff00000000 ffff8500240c8180 0000000000000000 ffff8500240d9340 : nt!KiRetireDpcList+0x4e9
ffff82808fc61c60 0000000000000000 : ffff82808fc62000 ffff82808fc5c000 0000000000000000 0000000000000000 : nt!KiIdleLoop+0x7e


SYMBOL_NAME: nt!MiRaisedIrqlFault+1355ff

MODULE_NAME: nt

IMAGE_VERSION: 10.0.18362.1082

STACK_COMMAND: .thread ; .cxr ; kb

IMAGE_NAME: ntkrnlmp.exe

BUCKET_ID_FUNC_OFFSET: 1355ff

FAILURE_BUCKET_ID: 0xBE_nt!MiRaisedIrqlFault

OS_VERSION: 10.0.18362.1

BUILDLAB_STR: 19h1_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {1c5b4d11-09e0-def3-d2d0-70a11d69b92d}

Followup: MachineOwner
---------

With the other RAM stick plugged in I have yet to receive an error after 2 hours of use. Does this basically confirm that the one RAM stick is faulty?

 

[PC Tailor]

With the other RAM stick plugged in I have yet to receive an error after 2 hours of use. Does this basically confirm that the one RAM stick is faulty?

Maybe.

You'll want to leave it for much longer to confirm. Memory comes in physical and virtual, and some of these can also be referring to virtual memory, which is not your RAM.

Just keep at it if it seems to have helped so far and wait. Take as long as you need as these threads don't have to to close quickly

 

[Zoltan Kandi]

Maybe I'm merely stoopid, but the first question that comes into mind: if this is a new system, why not let the vendor you bought it from handle your warranty issues?