Daily Bugcheck 133 (DPC_WATCHDOG_VIOLATION) BSODs/Freezes

S

slavkosky

Member
Joined
Jul 23, 2024
Posts
17
I've been experiencing Bugcheck 133 (DPC_WATCHDOG_VIOLATION) BSODs for several months now, ~once a day on average. BSOD almost always happens while the computer is idle. Sleep/hibernate are disabled system-wide, and screens only timeout if there's a brown-out and my UPC kicks in.

I will follow up this initial post with several minidump files, in them you'll see that:
- The offending IMAGE_NAME is always ntkrnlmp.exe
- The DEFAULT_BUCKET_ID is always WIN8_DRIVER_FAULT
- The PROCESS_NAME changes depending on the applications open at the time of the bugcheck (if Steam.exe is running, then it is usually listed. If not, then Discord.exe will be listed. If I have both of those closed, it's some other random process name listed in the minidump. The bugcheck occurs regardless.)


  • System Manufacturer?
DIY Build
  • Laptop or Desktop?
Desktop
  • Exact model number (if laptop, check label on bottom)
N/A
  • OS ? (Windows 11, 10, 8.1, 8, 7, Vista)
Windows 11 Pro (Version 10.0.22631 Build 22631)
  • x86 (32bit) or x64 (64bit)?
64bit
  • (Only for Vista, Windows 7) Service pack?
N/A
  • What was original installed OS on system?
Windows 8.1 (free upgrade to 10, then free upgrade to 11)
  • Is the OS an OEM version (came pre-installed on system) or full retail version (YOU purchased it from retailer)?
Retail
  • Age of system? (hardware)
Motherboard/PSU/Case = ~5 years
CPU = 2 years
GPU = 1 year
RAM = 1.5 years
PCIe 2.5Gbps NIC AIC = 2 years
  • Age of OS installation?
Upgraded to Windows 11 ~8 months ago
  • Have you re-installed the OS?
No. I am a developer and have a rather complex system environment setup, re-installing windows is my last resort
  • CPU
AMD Ryzen 5950x
  • RAM (brand, EXACT model, what slots are you using?)
G.Skill TridentZ Neo DDR4-3600 32GBx4 kit (model F4-3600C18Q-128GTZN); using all 4 slots (note: the bugcheck occurs regardless of running RAM at stock JEDEC clocks or XMP mode)
  • Video Card
Nvidia RTX 4090 (Asus TUF-RTX4090-O24G-GAMING)
  • MotherBoard - (if NOT a laptop)
ASRock X570 Taichi (running BIOS P5.61, though upgrading to this latest version didn't stop the bugcheck)
  • Power Supply - brand & wattage (if laptop, skip this one)
Corsair RM1000i (1000w) Intelligent PSU (USB connection to motherboard for measuring power metrics)
  • Is driver verifier enabled or disabled?
Enabled (as of this morning, using the steps outlined @ Driver Verifier Instructions - BSOD - Windows 11, 10, 8(.1), 7 and Vista)
  • What security software are you using? (Firewall, antivirus, antimalware, antispyware, and so forth)
Windows Defender/Firewall. Ran Malwarebytes Scanner Free about 2 weeks ago, no issues found.
  • Are you using proxy, vpn, ipfilters or similar software?
I've used Mullvad VPN, OpenVPN and Ultra VPN, however I've uninstalled all but Mullvad since. The BSODs were happening before installing Mullvad
  • Are you using Disk Image tools? (like daemon tools, alcohol 52% or 120%, virtual CloneDrive, roxio software)
Acronis True Image for cloning NVMe drives (the NVMe running as my C:\ drive is a clone of the original NVMe drive I replaced it with). Only used when needed, disabled all Acronis tasks/background services.
  • Are you currently under/overclocking? Are there overclocking software installed on your system?
I have fiddled with AMD PBO and slight CPU/GPU undervolting in the past, but I prefer stability over performance and usually (and currently) are not running any undervolts/overclocks (except for XMP to 3600Mhz for my RAM). GPUTweakIII is installed, but doesn't run on startup and I don't use it.


SPECCY*: http://speccy.piriform.com/results/piSswpjpWCYjZlnUc1jPGAU

*I noticed my GPU is listed by Speccy as having 4GB VRAM, when in fact it has 24GB. Is this a quirk of Speccy? I ran x64 portable (v1.32.740). Also, the Bus Interface = PCIe x4, which is odd as well. The GPU is installed in my 3rd PCIe slot (Slot[2]; x16 Physical/x8 Electrical) as I have bifurcated the first slot (Slot[0]) to x4/x4/x4/x4 for running a 4x NVMe AIC. Based on the motherboard's manual and other forums, this PCIe config is supposed to result in 16-lanes for Slot[0] and 8-lanes for Slot[2]. So what's with the x4 bus width in Speccy?
 

Attachments

Last edited:
Hello and welcome to the forum!

Many thanks for following the BSOD posting instructions, that helps a lot. You're correct that all the BSODs are 0x133 bugchecks, however they all have argument 1 set to the value 1 and we need the kernel dump to analyse that specific bugcheck. There is only one kernel dump (for the most recent BSOD) and it's the file C:\Windows\Memory.dmp, so could you upload that please (it will be large, which is why we don't routinely ask for it).

However, checking your System log I can see all the BSODs and their associated error 41 records (indicating that Windows didn't shut down properly). However, I can also see several error 41 entries that do not have a corresponding BSOD. These indicate that on these occasions the system simply crashed (or was powered off) and didn't BSOD - were these the freezes you mention in your title? Did you power down to recover?

The lack of a BSOD means that something occurred that Windows didn't detect (and BSOD) and that's very rarely a software problem, it's far more commonly a hardware cause. In addition, in your Application log I can see a fair number of application error messages (many more than I would normally expect) all with error codes indicating a memory cause (most commonly 0xC000005 - invalid memory access, and 0xC0000409 - stack buffer overrun) and for a variety of different executables. These, and the error 41 messages with no associated BSOD, do tend to suggest tha flaky RAM might well be the cause here.

It will take an age to run Memtets86 on 128GB of RAM, and no memory tester can ever find 100% of problems in any case, so I'm going to suggest that you remove one RAM stick for a week or so (or until you get another BSOD). Check with your manual that the remaining 3 sticks are in the correct slots for a three-stick configuration. If it still BSODs then put that stick back and remove one of the other sticks for a week (or until it BSODs). If it BSODs with each RAM stick removed then it's not your RAM and we'll look elsewhere.

In addition, I notice that your RAM, G.Skill F4-3600C18-32GTZN, is not on the QVL for your motherboard and that CPU. I know very well of course, that these QVL lists are not necessarily exclusive, but when we're getting repeated BSODs and freezes where there are indications that RAM could be the cause, running non-QVL RAM always raises a big red flag. I see that this is a home build, how long ago did you install that particular RAM?

BTW I was unable to extract any of the dumps you uploaded separately, but the minidumps were in the Sysnative file collection output.

Please remember to upload the kernel dump.
 
Hi @ubuysa, thanks for the reply!

ubuysa said:
There is only one kernel dump (for the most recent BSOD) and it's the file C:\Windows\Memory.dmp, so could you upload that please (it will be large, which is why we don't routinely ask for it).
Click to expand...
Windows doesn't seem to be generating Memory.dmp files, as there isn't one present in C:\Windows\
It's possible full memory dumps are disabled for some reason, I'll look into it.

ubuysa said:
It will take an age to run Memtets86 on 128GB of RAM, and no memory tester can ever find 100% of problems in any case, so I'm going to suggest that you remove one RAM stick for a week or so (or until you get another BSOD). Check with your manual that the remaining 3 sticks are in the correct slots for a three-stick configuration. If it still BSODs then put that stick back and remove one of the other sticks for a week (or until it BSODs). If it BSODs with each RAM stick removed then it's not your RAM and we'll look elsewhere.
Click to expand...
I'll try this, thanks for the tip. And yes, Memtest was taking >24hrs and I need this computer nearly everyday so finding the time to do 8+ passes to get a decent result has been untenable.

ubuysa said:
In addition, I notice that your RAM, G.Skill F4-3600C18-32GTZN, is not on the QVL for your motherboard and that CPU. I know very well of course, that these QVL lists are not necessarily exclusive, but when we're getting repeated BSODs and freezes where there are indications that RAM could be the cause, running non-QVL RAM always raises a big red flag. I see that this is a home build, how long ago did you install that particular RAM?
Click to expand...
Almost exactly 2 years ago, Aug 2022. It was bought new.
 
OK, try removing RAM sticks then. Be sure to run with each stick out for long enough to have normally had a BSOD.

The dump file should be set to 'automatic memory dump'. Also make sure that the 'overwrite exiting file' box IS checked.
 
UPDATE:
My motherboard only supports ram configurations of either 1, 2 or 4 sticks, so I took out two of them. No crashes for ~3 days.
However I came to my PC this morning and found my displays were sleeping (odd since my sleep, hibernate, screensaver, and display time-out are all disabled. The displays only go to sleep if the PC is running on battery (UPC) for over 20 minutes. This has happened before, though. Sometimes the screens wake up, but usually it's a sign the PC crashed and I have to reboot.

Upon rebooting, I walked away for a minute to finish making my coffee. By the time I came back, the windows 11 login screen was displayed but was frozen and I had to reboot again (this happened twice in a row, no minidumps generated for those two). It seems that if I leave the computer at the login screen for longer than a couple minutes the computer freezes (no bsod, unless I didn't wait long enough for it to trigger).

Also, I'm still not getting a MEMORY.DMP file generated when crashes occur, despite my settings having already been set correctly (these were the settings even before your recommendation). It can't be a disk space issue, as I have over 500GB free on my C: drive

SJtDseN.png


I will try and swap out the RAM sticks with the two I took out earlier this week and report back if/when I crash again. Thanks so much for all the help so far!

Also, here's the minidump output from the crash this morning:

Code: 
kd> !analyze -vv
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
    DISPATCH_LEVEL or above.
Arg2: 0000000000001e00, The watchdog period (in ticks).
Arg3: fffff8024b11c340, cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, which contains
    additional information regarding the cumulative timeout
Arg4: 0000000000000000

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

*************************************************************************
***                                                                   ***
***                                                                   ***
***    Either you specified an unqualified symbol, or your debugger   ***
***    doesn't have full symbol information.  Unqualified symbol      ***
***    resolution is turned off by default. Please either specify a   ***
***    fully qualified symbol module!symbolname, or enable resolution ***
***    of unqualified symbols by typing ".symopt- 100". Note that     ***
***    enabling unqualified symbol resolution with network symbol     ***
***    server shares in the symbol path may cause the debugger to     ***
***    appear to hang for long periods of time when an incorrect      ***
***    symbol name is typed or the network symbol server is down.     ***
***                                                                   ***
***    For some commands to work properly, your symbol path           ***
***    must point to .pdb files that have full type information.      ***
***                                                                   ***
***    Certain .pdb files (such as the public OS symbols) do not      ***
***    contain the required information.  Contact the group that      ***
***    provided you with these symbols if you need this command to    ***
***    work.                                                          ***
***                                                                   ***
***    Type referenced: TickPeriods                                   ***
***                                                                   ***
*************************************************************************

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 2531

    Key  : Analysis.Elapsed.mSec
    Value: 3085

    Key  : Analysis.IO.Other.Mb
    Value: 0

    Key  : Analysis.IO.Read.Mb
    Value: 1

    Key  : Analysis.IO.Write.Mb
    Value: 2

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

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

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

    Key  : Bugcheck.Code.LegacyAPI
    Value: 0x133

    Key  : Bugcheck.Code.TargetModel
    Value: 0x133

    Key  : Dump.Attributes.AsUlong
    Value: 180c

    Key  : Dump.Attributes.DiagDataWrittenToHeader
    Value: 1

    Key  : Dump.Attributes.ErrorCode
    Value: 0

    Key  : Dump.Attributes.InsufficientDumpfileSize
    Value: 1

    Key  : Dump.Attributes.KernelGeneratedTriageDump
    Value: 1

    Key  : Dump.Attributes.LastLine
    Value: Dump completed successfully.

    Key  : Dump.Attributes.ProgressPercentage
    Value: 0

    Key  : Dump.Attributes.RequiredDumpfileSize
    Value: 0x1f2fab3d9

    Key  : Failure.Bucket
    Value: 0x133_ISR_nt!KeAccumulateTicks

    Key  : Failure.Hash
    Value: {65350307-c3b9-f4b5-8829-4d27e9ff9b06}

    Key  : Hypervisor.Enlightenments.ValueHex
    Value: 1497cf94

    Key  : Hypervisor.Flags.AnyHypervisorPresent
    Value: 1

    Key  : Hypervisor.Flags.ApicEnlightened
    Value: 1

    Key  : Hypervisor.Flags.ApicVirtualizationAvailable
    Value: 0

    Key  : Hypervisor.Flags.AsyncMemoryHint
    Value: 0

    Key  : Hypervisor.Flags.CoreSchedulerRequested
    Value: 0

    Key  : Hypervisor.Flags.CpuManager
    Value: 1

    Key  : Hypervisor.Flags.DeprecateAutoEoi
    Value: 0

    Key  : Hypervisor.Flags.DynamicCpuDisabled
    Value: 1

    Key  : Hypervisor.Flags.Epf
    Value: 0

    Key  : Hypervisor.Flags.ExtendedProcessorMasks
    Value: 1

    Key  : Hypervisor.Flags.HardwareMbecAvailable
    Value: 1

    Key  : Hypervisor.Flags.MaxBankNumber
    Value: 0

    Key  : Hypervisor.Flags.MemoryZeroingControl
    Value: 0

    Key  : Hypervisor.Flags.NoExtendedRangeFlush
    Value: 0

    Key  : Hypervisor.Flags.NoNonArchCoreSharing
    Value: 1

    Key  : Hypervisor.Flags.Phase0InitDone
    Value: 1

    Key  : Hypervisor.Flags.PowerSchedulerQos
    Value: 0

    Key  : Hypervisor.Flags.RootScheduler
    Value: 0

    Key  : Hypervisor.Flags.SynicAvailable
    Value: 1

    Key  : Hypervisor.Flags.UseQpcBias
    Value: 0

    Key  : Hypervisor.Flags.Value
    Value: 4853999

    Key  : Hypervisor.Flags.ValueHex
    Value: 4a10ef

    Key  : Hypervisor.Flags.VpAssistPage
    Value: 1

    Key  : Hypervisor.Flags.VsmAvailable
    Value: 1

    Key  : Hypervisor.RootFlags.AccessStats
    Value: 1

    Key  : Hypervisor.RootFlags.CrashdumpEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.CreateVirtualProcessor
    Value: 1

    Key  : Hypervisor.RootFlags.DisableHyperthreading
    Value: 0

    Key  : Hypervisor.RootFlags.HostTimelineSync
    Value: 1

    Key  : Hypervisor.RootFlags.HypervisorDebuggingEnabled
    Value: 0

    Key  : Hypervisor.RootFlags.IsHyperV
    Value: 1

    Key  : Hypervisor.RootFlags.LivedumpEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.MapDeviceInterrupt
    Value: 1

    Key  : Hypervisor.RootFlags.MceEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.Nested
    Value: 0

    Key  : Hypervisor.RootFlags.StartLogicalProcessor
    Value: 1

    Key  : Hypervisor.RootFlags.Value
    Value: 1015

    Key  : Hypervisor.RootFlags.ValueHex
    Value: 3f7


PROCESSES_ANALYSIS: 1


SERVICE_ANALYSIS: 1


STACKHASH_ANALYSIS: 1


ADDITIONAL_XML: 1

OS_BUILD_LAYERS: 1

TIMELINE_ANALYSIS: 1


BUGCHECK_CODE:  133

BUGCHECK_P1: 1

BUGCHECK_P2: 1e00

BUGCHECK_P3: fffff8024b11c340

BUGCHECK_P4: 0

DUMP_CLASS: 1

DUMP_QUALIFIER: 400

FILE_IN_CAB:  080624-26875-01.dmp

BUILD_VERSION_STRING:  10.0.22621.3880 (WinBuild.160101.0800)

SYSTEM_PRODUCT_NAME:  X570 Taichi

SYSTEM_SKU:  To Be Filled By O.E.M.

SYSTEM_VERSION:  To Be Filled By O.E.M.

BIOS_VENDOR:  American Megatrends Inc.

BIOS_VERSION:  P5.61

BIOS_DATE:  02/23/2024

BASEBOARD_MANUFACTURER:  ASRock

BASEBOARD_PRODUCT:  X570 Taichi

BASEBOARD_VERSION:                       

DUMP_FILE_ATTRIBUTES: 0x180c
  Insufficient Dumpfile Size
  Kernel Generated Triage Dump

DUMP_TYPE:  2

DPC_TIMEOUT_TYPE:  DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

CPU_COUNT: 20

CPU_MHZ:  3400

CPU_VENDOR:  AuthenticAMD

CPU_FAMILY: 19

CPU_MODEL: 21

CPU_STEPPING: 2

CPU_MICROCODE: 19,21,2,0 (F,M,S,R)  SIG: 0'00000000 (cache) 0'0A20120E (init)

BLACKBOXBSD: 1 (!blackboxbsd)

Version: 0xc0
Product type: 1

Auto advanced boot: FALSE
Advanced boot menu timeout: 30
Last boot succeeded: TRUE
Last boot shutdown: FALSE
Sleep in progress: FALSE

Power button timestamp: 0x0
System running: TRUE
Connected standby in progress: FALSE
User shutdown in progress: FALSE
System shutdown in progress: FALSE
Sleep in progress: 0
Connected standby scenario instance id: 0
Connected standby entry reason: 12
Connected standby exit reason: 5
System sleep transitions to on: 0
Last reference time: 0x1dae827541ba737
    2024-08-06T17:37:37.331Z
Last reference time checksum: 0x5a60f822
Last update boot id: 267

Boot attempt count: 2
Last boot checkpoint: TRUE
Checksum: 0x1a
Last boot id: 267
Last successful shutdown boot id: 265
Last reported abnormal shutdown boot id: 158

Error info boot id: 0
Error info repeat count: 0
Error info other error count: 0
Error info code: 0
Error info status: 0x0

Power button last press time: 0x0
Power button cumulative press count: 0
Power button last press boot id: 0
Power button last power watchdog stage: 0
Power button watchdog armed: FALSE
Power button shutdown in progress: FALSE
Power button last release time: 0x0
Power button cumulative release count: 0
Power button last release boot id: 0
Power button error count: 0
Power button current connected standby phase: 0
Power button transition latest checkpoint id: 0
Power button transition latest checkpoint type: 0
Power button transition latest checkpoint sequence number: 0

Power transition Shutdown Device Type: 0
Power transition Setup In Progress: FALSE
Power transition OOBE In Progress: FALSE
Power transition Sleep Checkpoint Source: 0
Power transition Sleep Checkpoint: 0
Power transition Connected Standby Entry Reason Category: 0
Power transition Connected Standby Exit Reason Category: 0
Power transition Connected Standby Entry Scenario Instance Id: 0x1

Feature Configuration State : Boot Pending


BLACKBOXNTFS: 1 (!blackboxntfs)


NTFS Blackbox Data

0 Slow I/O Timeout Records Found
0 Oplock Break Timeout Records Found

BLACKBOXPNP: 1 (!blackboxpnp)

    PnpActivityId      : {00000000-0000-0000-0000-000000000000}
    PnpActivityTime    : 133674394530300066
    PnpEventInformation: 5
    PnpEventInProgress : 0
    PnpProblemCode     : 43
    PnpVetoType        : 0
    DeviceId           : USB\VID_0000&PID_0002\9&17026168&0&2
    VetoString         :


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  Discord.exe

CURRENT_IRQL:  d

ANALYSIS_SESSION_HOST:  K7

ANALYSIS_SESSION_TIME:  08-06-2024 14:57:51.0393

ANALYSIS_VERSION: 10.2402.02.01 amd64fre

LAST_CONTROL_TRANSFER:  from fffff8024a72bf29 to fffff8024a815df0

STACK_TEXT: 
ffffd780`a18ebc78 fffff802`4a72bf29     : 00000000`00000133 00000000`00000001 00000000`00001e00 fffff802`4b11c340 : nt!KeBugCheckEx
ffffd780`a18ebc80 fffff802`4a72b074     : 0004f7a5`c1f567fe 000003bd`63c98db5 00000000`01918ef0 00000000`00000000 : nt!KeAccumulateTicks+0x239
ffffd780`a18ebce0 fffff802`4a728f81     : 00000000`00000000 ffffb00a`57153700 ffffd780`a18d1180 00000000`00000000 : nt!KiUpdateRunTime+0xf4
ffffd780`a18ebea0 fffff802`4a728a7a     : fffff802`4b05fe88 ffffb00a`571537d0 ffffb00a`571537d0 00000000`0000000c : nt!KeClockInterruptNotify+0xc1
ffffd780`a18ebf40 fffff802`4a644b7c     : 000003bd`63c9a609 ffffb00a`57153720 ffffb00a`571537d0 00000000`00000000 : nt!HalpTimerClockInterrupt+0x10a
ffffd780`a18ebf70 fffff802`4a817ffa     : fffff405`6e442100 ffffb00a`57153720 ffffd780`a18d1180 00000000`00000000 : nt!KiCallInterruptServiceRoutine+0x9c
ffffd780`a18ebfb0 fffff802`4a8188c7     : 00000000`7669c6b5 00007ffb`b5541b00 0000001f`667fe770 fffff802`4a72e28b : nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
fffff405`6e442080 fffff802`4a7078e0     : 00000000`00000000 00000000`00000000 00000000`00000000 fffff802`4a68d220 : nt!KiInterruptDispatchNoLockNoEtw+0x37
fffff405`6e442210 fffff802`4a7076f5     : fffff405`6e442400 fffff802`716c10ed 00000000`00000000 00000000`00000001 : nt!KiIpiStallOnPacketTargetsPrcb+0x10
fffff405`6e442240 fffff802`4aaf4ada     : fffff405`6e442400 ffffb00a`904d2080 0000001f`667fc7e0 ffffb00a`8c35a0c0 : nt!KeFlushProcessWriteBuffers+0xd9
fffff405`6e442290 fffff802`4aad0e47     : ffffb00a`8c35a0c0 00000000`00000000 fffff405`6e442b20 0000001f`667fc7e0 : nt!PsQueryTotalCycleTimeProcess+0x2a
fffff405`6e4422c0 fffff802`4a82b408     : ffffb00a`904d2000 ffffc782`6e4e6b28 00000000`00000000 80000000`00000001 : nt!NtQueryInformationProcess+0x1b57
fffff405`6e442a30 00007ffc`54d502c4     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
0000001f`667fc7a8 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffc`54d502c4


THREAD_SHA1_HASH_MOD_FUNC:  16dc24076efe72c959a21d26dc903e204867fe17

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  254244442223b459bfc4641d8cf9612dbba55033

THREAD_SHA1_HASH_MOD:  fe34192f63d13620a8987d294372ee74d699cfee

FOLLOWUP_IP:
nt!KeAccumulateTicks+239
fffff802`4a72bf29 cc              int     3

FAULT_INSTR_CODE:  f68545cc

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!KeAccumulateTicks+239

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  6b71a188

IMAGE_VERSION:  10.0.22621.3880

STACK_COMMAND:  .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET:  239

FAILURE_BUCKET_ID:  0x133_ISR_nt!KeAccumulateTicks

BUCKET_ID:  0x133_ISR_nt!KeAccumulateTicks

PRIMARY_PROBLEM_CLASS:  0x133_ISR_nt!KeAccumulateTicks

OS_BUILD:  0

OS_REVISION:  0

TARGET_TIME:  2024-08-06T17:41:43.000Z

OSSERVICEPACK:  0

SUITE_MASK:  272

PRODUCT_TYPE:  1

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

OSEDITION:  Windows 10 WinNt TerminalServer SingleUserTS

OSBUILD_TIMESTAMP:  2027-02-14T12:43:52Z

ANALYSIS_SESSION_ELAPSED_TIME:  c0d

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x133_isr_nt!keaccumulateticks

FAILURE_ID_HASH:  {65350307-c3b9-f4b5-8829-4d27e9ff9b06}
 
Check that ALL of the following are true...
  • The page file must be on the same drive as your operating system
  • Set page file to "system managed"
  • Set system crash/recovery options to "Automatic memory dump"
  • Overwrite any existing file box must be checked
  • The dump file location must be %SystemRoot%\MEMORY.DMP
  • Windows Error Reporting (WER) system service should be set to MANUAL
  • User account control must be running
In addition, the following can also prevent you seeing dumps...
  • SSD drives with older firmware do not create dumps (update the drive firmware)
  • Cleaner applications like Ccleaner delete dump files, so don't run them until you are fixed
  • Bad RAM may prevent the data from being saved and written to a file on reboot...

Don't post the output of analyze -v, please re-run the Sysnative file collection app and upload a new output file.

Have you checked with each RAM stick removed at some point? Does it misbehave with every stick out at some point? I'm pretty sure this is RAM related...
 
Hello again, I'm back in town, and have been experiencing more of the same crashes. I followed your bullet points (I'd manually set my paging file sizes because I use this computer for Unreal Engine Development and setting explicit values helps avoid Out of Memory crashes while rendering), and managed to get windows to generate the MEMORY.DMP file.

MEMORY.ZIP
 
Now this is interesting. We need the kernel dump with this specific BSOD (and one or two others) because with cumulative DPC overruns we need to see all processors. Basically we extract the WMI trace records and format them into a form that the Windows Performance Analyser (WPA) can read. Then we use WPA to look at all the running DPCs to see which ones contributed to the long running BSOD....
y53f3Ys.jpg

You can see two drivers running much longer than the 100 μs that Microsoft recommend; tcpip.sys (the high-level network driver) and winhvr.sys (the Windows hypervisor root interface driver). Note that ntoskrnl.exe is the Windows kernel, not a DPC.

Both are Windows drivers and so the drivers themselves are not at fault. The tcpip.sys driver will be calling your network adapter driver rt25cx21x64.sys, and that looks to be current (it's dated 12th March 2024). I'm more interested in the winhvr hypervisor driver however, because I've never seen that one before. I can see that you seem to have Hyper-V enabled, I can see the Hyper-V Virtual Switch Extension Adapter in your network adapter list.

Are you using Hyper-V? Is it fully installed? are all the appropriate BIOS options for Hyper-V enabled? If you're not using Hyper-V then it might be wise to uninstall the Hyper-V components from Windows and disable the relevant BIOS settings. Here's how to enable/disable Hyper-V in Windows: Enable Hyper-V on Windows. Youy'll need to check your BIOS manual for details one enabling/disabling virtualisation.

I confess that I have no idea of the significance of seeing winhvr.sys in that DPC list but it does make me think that Hyper-V may not be setup properly.
 
Hi, thanks for the insight. I, to my knowledge, do not have hyper-v installed. I do run WSL2 (with Ubuntu installed), and I installed Docker Desktop (in windows) that runs a couple of docker VMs, but I can't remember ever explicitly enabling Hyper-V. I wonder if Docker Desktop or WSL require Hyper-V? Pretty sure Hyper-V is disabled in Windows Features. I'll look into this.

As for the network driver, any idea why that'd be running so slowly? The NIC is a PCIe 2.5gb AIC I added a little over a year ago, so it's third party and not built into my motherboard. I recently updated it's driver directly from the Realtek website in hopes that was causing the BSODs, so that's why the driver is so recent
 
I've checked Windows Features, and Hyper-V is indeed disabled:

Windows_Features_20240823-1414.png

I'll look around in my BIOS to make sure nothing Hyper-V-related is enabled
 
I do have these features enabled (Windows Subsystem for Linux is for Docker as I chose that config option over the Hyper-V backend):
1724455043467.png
From this support article (Is Hyper-V necessary or not for WSL2? Can it be activated on Windows 10 Home? · Issue #899 · MicrosoftDocs/WSL) it's stated that Virtual Machine Platform feature is a 'subset of Hyper-V' and is required to be enabled to setup WSL2. So maybe I just need to fully enable Hyper-V? I'd love to retain the ability to run Docker containers via WSL2 backend on this machine.

For now, I'm going to try your suggestion and disable Hyper-V by:
1. Run the following commands to disable Hyper-V
Code: 
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
2. Reboot
3. Verify Hyper-V removal
Code: 
dism /online /disable-feature /featurename:Microsoft-hyper-v-all
4. Report back with another MEMORY.DMP if the BSOD occurs again
 
Last edited:
After disabling Hyper-V above and rebooting again, I ran ipconfig /all and noticed that my WSL vEthernet adapter shows the following:

Code: 
Ethernet adapter vEthernet (WSL (Hyper-V firewall)):

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   NetBIOS over Tcpip. . . . . . . . : Enabled
What's interesting to me is the (WSL (Hyper-V firewall)) and the fact that the Description is Hyper-V Virtual Ethernet Adapter.
 
Having checked, you're right that WSL requires the Virtual Machine Platform to be enabled. I'm wondering is that's why we see winhvr.sys there?

I went back to your original Sysnative upload and that network adapter is active...
Code: 
Ethernet adapter vEthernet (WSL (Hyper-V firewall)):

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   Physical Address. . . . . . . . . : 00-15-5D-D5-8C-6C
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::6514:4c56:c175:b5c8%36(Preferred) 
   IPv4 Address. . . . . . . . . . . : 172.30.80.1(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . : 
   DHCPv6 IAID . . . . . . . . . . . : 603985245
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-25-07-BD-E8-A8-A1-59-02-0A-21
   NetBIOS over Tcpip. . . . . . . . : Enabled
That must be the WSL adapter then. I'm wondering whether WSL is the root cause of this recent BSOD?
 
Ok, so ~4 full days have gone by without another BSOD after running those Hyper-V disable commands. I'll report back in a few more days with an update (as 4 days really isn't enough time to consider a computer stable hehe), but so far so good!

Thanks so much @ubuysa for all your attention on this, words on an internet forum cannot properly convey my appreciation and excitement at the possibility of finally putting this issue behind me!

Side question: In the future, I'd like to be able to better handle diagnosing crashes using WPA, but I'm unfamiliar with it. I'll go and find out how to get it running on my machine, but could you outline the steps you took to convert my memory dump data into a ETL for WPA?
 
That technique is more complex than I indicated and it's useful in only one specific type of BSOD. TBH you need to be able to use WInDbg to analyse simple BSODs first.
 
Well, I'm sad to report that I've had multiple crashes in the last 72 hours or so. Here is a link to two memory dumps, the 2nd of which happened last night/early this morning.
https://drive.google.com/drive/folders/12amb_aPaN4MKqm1fysWiQm-zUTbrdeli?usp=sharing

I've been digging into XPerf, and had a trace running when the dump in MEMORY2.zip was generated. I understand now that one must manually stop/merge the traces to get proper symbol resolution in WPA, but if it's useful to you the data is likely buried in that memory dump.

The trace was encapsulated in a PowerShell script:
Code: 
# Start-XPerfTrace.ps1
param (
    [string]$outputPath = "$env:USERPROFILE\Desktop\xperf\trace_stackwalk_Base+INTERRUPT+DPC+NETWORKTRACE+HV_CALLOUTS+DRIVERS.etl",
    [int]$maxFileSizeMB = 128
)

xperf -on Base+INTERRUPT+DPC+NETWORKTRACE+HV_CALLOUTS+DRIVERS `
       -stackwalk "Profile+CSwitch+ReadyThread+HardFault+ProcessCreate+ThreadCreate" `
       -buffersize 2048 -minbuffers 512 -maxbuffers 2048 `
       -filemode Circular -MaxFile $maxFileSizeMB `
       -f $outputPath

Is there a better way to use xperf in this way (where it runs circular until crashes happen) that will resolve symbols and capture process/driver names?

I'm also seeing errors and warnings in the Event Viewer before the crash (in reverse chronological order):
Code: 
Log Name:      Microsoft-Windows-GroupPolicy/Operational
Source:        Microsoft-Windows-GroupPolicy
Date:          8/31/24 5:38:29
Event ID:      7320
Task Category: None
Level:         Error
Keywords:     
User:          SYSTEM
Computer:      K7
Description:
Error: Access check based on security descriptor failed. Error code 0x5.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-GroupPolicy" Guid="{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}" />
    <EventID>7320</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000000</Keywords>
    <TimeCreated SystemTime="2024-08-31T12:38:29.7452162Z" />
    <EventRecordID>557782</EventRecordID>
    <Correlation />
    <Execution ProcessID="2644" ThreadID="4580" />
    <Channel>Microsoft-Windows-GroupPolicy/Operational</Channel>
    <Computer>K7</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <EventData>
    <Data Name="ErrorDescription">%%4105</Data>
    <Data Name="ErrorCode">5</Data>
  </EventData>
</Event>

Code: 
Log Name:      Microsoft-Windows-Hyper-V-VmSwitch-Operational
Source:        Microsoft-Windows-Hyper-V-VmSwitch
Date:          8/31/24 5:38:05
Event ID:      285
Task Category: None
Level:         Warning
Keywords:      (128)
User:          N/A
Computer:      K7
Description:
V-Switch operation OID_GEN_STATISTICS (131334) took too long to complete. Operation Type: OID HOST VNIC. Execution time 0 ms. Queued time 0 ms. Expected execution time less than 0 ms. NicName: 790E58B4-7939-4434-9358-89AE7DDBE87F. NicFriendlyName: WSL (Hyper-V firewall).   
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Hyper-V-VmSwitch" Guid="{67dc0d66-3695-47c0-9642-33f76f7bd7ad}" />
    <EventID>285</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000080</Keywords>
    <TimeCreated SystemTime="2024-08-31T12:38:05.3841596Z" />
    <EventRecordID>222122</EventRecordID>
    <Correlation />
    <Execution ProcessID="5196" ThreadID="21512" />
    <Channel>Microsoft-Windows-Hyper-V-VmSwitch-Operational</Channel>
    <Computer>K7</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="OperationName">OID_GEN_STATISTICS</Data>
    <Data Name="OperationType">3</Data>
    <Data Name="OperationId">131334</Data>
    <Data Name="ExecutionTimeMS">0</Data>
    <Data Name="QueuedTimeMS">0</Data>
    <Data Name="SLAThresholdMS">0</Data>
    <Data Name="ContextType1">1</Data>
    <Data Name="ContextInfo1">790E58B4-7939-4434-9358-89AE7DDBE87F</Data>
    <Data Name="ContextType2">2</Data>
    <Data Name="ContextInfo2">WSL (Hyper-V firewall)</Data>
    <Data Name="ContextType3">0</Data>
    <Data Name="ContextInfo3">
    </Data>
  </EventData>
</Event>

Code: 
Log Name:      Microsoft-Windows-Hyper-V-VmSwitch-Operational
Source:        Microsoft-Windows-Hyper-V-VmSwitch
Date:          8/31/24 5:36:58
Event ID:      285
Task Category: None
Level:         Warning
Keywords:      (128)
User:          N/A
Computer:      K7
Description:
V-Switch operation OID_GEN_STATISTICS (131334) took too long to complete. Operation Type: OID HOST VNIC. Execution time 0 ms. Queued time 0 ms. Expected execution time less than 0 ms. NicName: 790E58B4-7939-4434-9358-89AE7DDBE87F. NicFriendlyName: WSL (Hyper-V firewall).   
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Hyper-V-VmSwitch" Guid="{67dc0d66-3695-47c0-9642-33f76f7bd7ad}" />
    <EventID>285</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000080</Keywords>
    <TimeCreated SystemTime="2024-08-31T12:36:58.0281315Z" />
    <EventRecordID>222121</EventRecordID>
    <Correlation />
    <Execution ProcessID="2384" ThreadID="8172" />
    <Channel>Microsoft-Windows-Hyper-V-VmSwitch-Operational</Channel>
    <Computer>K7</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="OperationName">OID_GEN_STATISTICS</Data>
    <Data Name="OperationType">3</Data>
    <Data Name="OperationId">131334</Data>
    <Data Name="ExecutionTimeMS">0</Data>
    <Data Name="QueuedTimeMS">0</Data>
    <Data Name="SLAThresholdMS">0</Data>
    <Data Name="ContextType1">1</Data>
    <Data Name="ContextInfo1">790E58B4-7939-4434-9358-89AE7DDBE87F</Data>
    <Data Name="ContextType2">2</Data>
    <Data Name="ContextInfo2">WSL (Hyper-V firewall)</Data>
    <Data Name="ContextType3">0</Data>
    <Data Name="ContextInfo3">
    </Data>
  </EventData>
</Event>

Code: 
Log Name:      Microsoft-Windows-Hyper-V-VmSwitch-Operational
Source:        Microsoft-Windows-Hyper-V-VmSwitch
Date:          8/31/24 5:26:06
Event ID:      285
Task Category: None
Level:         Warning
Keywords:      (128)
User:          N/A
Computer:      K7
Description:
V-Switch operation OID_GEN_STATISTICS (131334) took too long to complete. Operation Type: OID HOST VNIC. Execution time 0 ms. Queued time 0 ms. Expected execution time less than 0 ms. NicName: 790E58B4-7939-4434-9358-89AE7DDBE87F. NicFriendlyName: WSL (Hyper-V firewall).   
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Hyper-V-VmSwitch" Guid="{67dc0d66-3695-47c0-9642-33f76f7bd7ad}" />
    <EventID>285</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000080</Keywords>
    <TimeCreated SystemTime="2024-08-31T12:26:06.2246551Z" />
    <EventRecordID>222120</EventRecordID>
    <Correlation />
    <Execution ProcessID="5576" ThreadID="25368" />
    <Channel>Microsoft-Windows-Hyper-V-VmSwitch-Operational</Channel>
    <Computer>K7</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="OperationName">OID_GEN_STATISTICS</Data>
    <Data Name="OperationType">3</Data>
    <Data Name="OperationId">131334</Data>
    <Data Name="ExecutionTimeMS">0</Data>
    <Data Name="QueuedTimeMS">0</Data>
    <Data Name="SLAThresholdMS">0</Data>
    <Data Name="ContextType1">1</Data>
    <Data Name="ContextInfo1">790E58B4-7939-4434-9358-89AE7DDBE87F</Data>
    <Data Name="ContextType2">2</Data>
    <Data Name="ContextInfo2">WSL (Hyper-V firewall)</Data>
    <Data Name="ContextType3">0</Data>
    <Data Name="ContextInfo3">
    </Data>
  </EventData>
</Event>

Code: 
Log Name:      Microsoft-Windows-GroupPolicy/Operational
Source:        Microsoft-Windows-GroupPolicy
Date:          8/31/24 5:23:29
Event ID:      7320
Task Category: None
Level:         Error
Keywords:     
User:          SYSTEM
Computer:      K7
Description:
Error: Access check based on security descriptor failed. Error code 0x5.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-GroupPolicy" Guid="{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}" />
    <EventID>7320</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000000</Keywords>
    <TimeCreated SystemTime="2024-08-31T12:23:29.7026900Z" />
    <EventRecordID>557767</EventRecordID>
    <Correlation />
    <Execution ProcessID="2644" ThreadID="10328" />
    <Channel>Microsoft-Windows-GroupPolicy/Operational</Channel>
    <Computer>K7</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <EventData>
    <Data Name="ErrorDescription">%%4105</Data>
    <Data Name="ErrorCode">5</Data>
  </EventData>
</Event>

Code: 
Log Name:      Microsoft-Windows-Storage-Storport/Operational
Source:        Microsoft-Windows-StorPort
Date:          8/31/24 5:16:40
Event ID:      549
Task Category: Port
Level:         Error
Keywords:      Write request,Read request
User:          N/A
Computer:      K7
Description:
This is the first instance of the error seen during this time period                     
on Storport Device (Port = 7, Path = 0, Target = 0, Lun = 0) whose Corresponding Class Disk Device Guid is {a9b1a85c-c040-3304-e9ce-a70e8a95ba88}:                     
The request opcode was 0x88 and completed with SrbStatus 0x4 and ScsiStatus 0x2.                     
The sense code was (0x2,0x4,0x1).                     
The io latency was 1 ms.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-StorPort" Guid="{c4636a1e-7986-4646-bf10-7bc3b4a76e8e}" />
    <EventID>549</EventID>
    <Version>2</Version>
    <Level>2</Level>
    <Task>201</Task>
    <Opcode>0</Opcode>
    <Keywords>0x800000000600000</Keywords>
    <TimeCreated SystemTime="2024-08-31T12:16:40.5129517Z" />
    <EventRecordID>119628</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>Microsoft-Windows-Storage-Storport/Operational</Channel>
    <Computer>K7</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="PortNumber">7</Data>
    <Data Name="PathID">0</Data>
    <Data Name="TargetID">0</Data>
    <Data Name="LUN">0</Data>
    <Data Name="ClassDeviceGuid">{a9b1a85c-c040-3304-e9ce-a70e8a95ba88}</Data>
    <Data Name="AdapterGuid">{699c4b27-26ef-11ee-9e58-50e085beb954}</Data>
    <Data Name="BusType">7</Data>
    <Data Name="MiniportName">UASPStor</Data>
    <Data Name="VendorId">LaCie   </Data>
    <Data Name="ProductId">d2 THB USB3     </Data>
    <Data Name="SerialNumber">2202d705755300000000</Data>
    <Data Name="AdapterSerialNumber">
    </Data>
    <Data Name="BootDevice">false</Data>
    <Data Name="Version">1</Data>
    <Data Name="RequestDuration_ms">1</Data>
    <Data Name="WaitDuration_ms">0</Data>
    <Data Name="Command">136</Data>
    <Data Name="SrbStatus">4</Data>
    <Data Name="ScsiStatus">2</Data>
    <Data Name="SenseKey">2</Data>
    <Data Name="AddSense">4</Data>
    <Data Name="AddSenseQ">1</Data>
    <Data Name="IoSize">8192</Data>
    <Data Name="QueueDepth">0</Data>
    <Data Name="LBA">0x0</Data>
  </EventData>
</Event>

Code: 
Log Name:      Microsoft-Windows-WMI-Activity/Operational
Source:        Microsoft-Windows-WMI-Activity
Date:          8/31/24 4:38:23
Event ID:      5858
Task Category: None
Level:         Error
Keywords:      
User:          SYSTEM
Computer:      K7
Description:
Id = {00000000-0000-0000-0000-000000000000}; ClientMachine = K7; User = K7\KenobiVII; ClientProcessId = 10636; Component = Core; Operation = Start IWbemServices::ExecNotificationQuery - ROOT\CIMV2 : SELECT * FROM __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'Win32_Process'; ResultCode = 0x80010108; PossibleCause = Could not send status to client
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-WMI-Activity" Guid="{1418ef04-b0b4-4623-bf7e-d74ab47bbdaa}" />
    <EventID>5858</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000000</Keywords>
    <TimeCreated SystemTime="2024-08-31T11:38:23.3563944Z" />
    <EventRecordID>217350</EventRecordID>
    <Correlation />
    <Execution ProcessID="2644" ThreadID="12004" />
    <Channel>Microsoft-Windows-WMI-Activity/Operational</Channel>
    <Computer>K7</Computer>
    <Security UserID="S-1-5-18" />
  </System>
  <UserData>
    <Operation_ClientFailure xmlns="http://manifests.microsoft.com/win/2006/windows/WMI">
      <Id>{00000000-0000-0000-0000-000000000000}</Id>
      <ClientMachine>K7</ClientMachine>
      <User>K7\KenobiVII</User>
      <ClientProcessId>10636</ClientProcessId>
      <Component>Core</Component>
      <Operation>Start IWbemServices::ExecNotificationQuery - ROOT\CIMV2 : SELECT * FROM __InstanceCreationEvent WITHIN 10 WHERE TargetInstance ISA 'Win32_Process'</Operation>
      <ResultCode>0x80010108</ResultCode>
      <PossibleCause>Could not send status to client</PossibleCause>
    </Operation_ClientFailure>
  </UserData>
</Event>

There are many, many more of the GroupPolicy and Hyper-V related errors/warnings in my event log.

I was also monitoring my hardware temperatures, and none of my devices (CPU, GPU, Disks, Motherboard) were anywhere close to thermal limits.
 
Hmmm. I'm leaning towards bad RAM now, for a few reasons.
  • The zip file you uploaded was corrupted. Windows Explorer wouldn't unzip it. 7z did unzip it but some files cannot be read.
  • There are more application error messages with memory related exception code in your Application log than I would expect to see
  • Your System log is corrupt and cannot be opened.
In addition your RAM is overclocked at 3600MHz. This is the rated speed of the RAM but it's overclocked beyond the CPU warranty speed (3200MT/s) so there is no guarantee that the CPU will accept 3600MT/s (3600MHz DDR).

I would like you to remove the RAM overclock (via DOCP or XMP) and run the RAM at its native (SPD) speed of 2133 MT/s (2133 MHz DDR). Let's see whether the system is stable at that speed.

If you do still get BSODs at 2133 MT/s then please test your RAM (at 2133 MT/s)...
  1. Download Memtest86 (free), use the imageUSB.exe tool extracted from the download to make a bootable USB drive containing Memtest86 (1GB is plenty big enough). Do this on a different PC if you can, because you can't fully trust yours at the moment.
  2. Then boot that USB drive on your PC, Memtest86 will start running as soon as it boots.
  3. If no errors have been found after the four iterations of the 13 different tests that the free version does, then restart Memtest86 and do another four iterations. Even a single bit error is a failure.
Let us know how all that goes.
 
Ok, I'll give memtest a try, but unfortunately my two other desktops are old (DDR3), so I don't have another computer to try. My board must use at least two DIMMs, however if I find memory errors I can round-robin the sticks one at a time to try and isolate the bad one.

I'll be back after the weekend to try that (y)
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top