Hi all,
I am seeking some assistance from the tom's Hardware collective please to stop me going insane!
First I guess the info of the system:
Windows 10 Pro, build 19044 (up to date)
I9 9900K, not overclocked - bios all default settings / auto
2x8GB Corsair DDR4 2132 w/XMP @ 3596 - non XMP profile loaded
MSI Z390 Gaming Pro Carbon
Nvidia 3090Ti FE
1000w EVGA 80+ modular PSU
Crucial CT250 MX200 SSD for Operating System
Corsair MP600 Core 2TB SSD for game installs
2x WD 2TB standard HDDs
Widescreen 2560x1080 (so not many pixles!)
Quest 2 @ 1.6x SS / 90hz
I built this system around Jan 2022 (originally with my titan XP, then upgraded to 3090ti later in the year).
My issues started not long after building the PC, I purchased BF2042, and when I was playing the game, I experienced random locking up of the PC, with no mini dump, or system errors, only buttoning and rebooting would free up the PC.
I could play a game sometimes for 2 hours or so, other times maybe I couldn’t even play a single round and the PC would lockup.
At this time I had XMP profile loaded, and was running a titan XP. I have only experienced one other lockup, and that was after around 3-4 hours of Warzone, but mostly, all games run OK.
Fault finding:
Re-installed game
Tweaked XMP profile, as notice manufacturer timings differed to what bios was recommending, but still locked up
Removed XMP and set to default speed
Reset bios / CPU settings all to default and auto
Ran numerous OCCT tests, RAM and CPU tests passed
Conducted GPU stress tests with furmark - all passed
Memcheck – passed
Thermals checked – all good (CPU rarely more than mid 60’s, GPU same)
OCCT power test (crashed / locked after around 3 hours)
Checked 3.3v, 5v and 12v for any instability (only via software OCCT) – all good
Underclocked GPU RAM and core clock / reduced power target
Removed / reinstalled GPU drivers
Scanned all HDDs / checked for errors
Fresh install of Windows 10
Added Corsair NVME and fresh install of all game to a new / different HDD
Swapped PSU power connectors to GPU
Have since changed GPU to 3090ti
When the machine locks up, it is often during title screen, loading, after game, although can happen during game.
During last lockup:
CPU @ 49% utilisation
CPU package temp 57c
RAM @ 12GB usage
Disk 0, 1, 2 @ 0% (disk 0 OS volume)
Disk 3 @ 5% (game SSD)
Ethernet usage high-ish 344kbps
GPU usage 11%
GPU power 27%
VRAM 6579mb
GPU temp 53c
There is never anything in the event log I can see other than unexpected shutdowns / kernel power caused by me buttoning.
I also play VR, and I run @ 1.6SS, so that is 5408x2736, this depends on title but according to EVGA my GPU usage can vary from 60ish up to 90% or so. I play Project cars for hours, no problem, and other games such as Alyx, utilising over 16GB VRAM and with high GPU utilisation with no crashing.
The only needle I can find is that last night, on one of the crashes I sat and waited (I have before for a long time and never a BSOD or error), one of my screens went almost black and I did get a BSOD!) now this may be a coincidence, but anyway it was ‘DPC WATCHDOG VIOLATION’ and I had at least a dump file:
On Mon 19/12/2022 21:35:01 your computer crashed or a problem was reported
On Mon 19/12/2022 21:35:01 your computer crashed or a problem was reported
So I removed and cleaned AVG in safe mode – still had a lock up in BF2042.
When this BSOD was generated thermals were fine, I want to add that on custom settings in BF with everything on ultra, and all additional settings enable, my GPU rarely goes about 38%, so GPU temps in BF are normally in the 50’s or lower, and CPU never goes over mid 60’s.
Windows debugger tells a slightly different story though?
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (16 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff805
Debug session time: Mon Dec 19 21:35:01.932 2022 (UTC + 0:00)
System Uptime: 4 days 21:29:46.062
Loading Kernel Symbols
...............................................................
................................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
......................
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff805
3: kd> !analyze -v
***
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: fffff805758fb320, 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: 3749
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 4088
Key : Analysis.IO.Other.Mb
Value: 0
Key : Analysis.IO.Read.Mb
Value: 0
Key : Analysis.IO.Write.Mb
Value: 0
Key : Analysis.Init.CPU.mSec
Value: 249
Key : Analysis.Init.Elapsed.mSec
Value: 3917
Key : Analysis.Memory.CommitPeak.Mb
Value: 86
Key : Bugcheck.Code.DumpHeader
Value: 0x133
Key : Bugcheck.Code.Register
Value: 0x133
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: 121922-8828-01.dmp
BUGCHECK_CODE: 133
BUGCHECK_P1: 1
BUGCHECK_P2: 1e00
BUGCHECK_P3: fffff805758fb320
BUGCHECK_P4: 0
DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
TRAP_FRAME: ffffe403cb271ee0 -- (.trap 0xffffe403cb271ee0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=00000000003506f8
rdx=00000000000c00e1 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80574ebb970 rsp=ffffe403cb272070 rbp=0000000000000003
r8=000000000000082f r9=00000000000000e1 r10=fffff80574f376e0
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
nt!KiIpiSendRequestEx+0xb0:
fffff805
Resetting default scope
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: BF2042.exe
STACK_TEXT:
ffffbd01
ffffbd01
ffffbd01
ffffbd01
ffffbd01
ffffbd01
ffffe403
ffffe403
ffffe403
ffffe403
ffffe403
ffffe403
ffffe403
ffffe403
ffffe403
ffffe403
ffffe403
ffffe403
00000000
SYMBOL_NAME: nt!KeAccumulateTicks+186d32
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
IMAGE_VERSION: 10.0.19041.2251
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 186d32
FAILURE_BUCKET_ID: 0x133_ISR_nt!KeAccumulateTicks
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {65350307-c3b9-f4b5-8829-4d27e9ff9b06}
Followup: MachineOwner
---------
In a last ditch attempt at anything meaningful, I noticed some DPC watchdog errors related to iastora.sys, and so re-installed the driver for the OS SSD, but you guessed it, still several lockups this evening, resulting in me buttoning the PC and no dump files, nothing I can see being meaningful in event viewer.
I am now leaning towards a PSU issue, it is after all, 7 years old now! However, if BF2042 is taxing my system less overall than running 14 million pixels in VR, and drawing a hell of a lot more power, how can it be stable there and fall over when ticking over in BF2042?
The PSU is a single rail, but I am not familiar with how the CPU / mobo circuit works vs PCIE and HDD supply.
My other thoughts were HDD, but the OS HDD although also an older crucial drive from a previous build seems reliable – no vanishing files, no corrupt files or weirdness, no errors.
With power ‘appearing’ stable in VR and OCCT tests I am not sure.
Perhaps I got a dodgy stick of RAM, but memtest checks out, and OCCT memory tests always seem to work just fine using 95% of memory.
Maybe I got a dodgy CPU? But a CPU burn or stress test at 100% also seems stable (I’ve done more memory and CPU tests this eve on OCCT and all good, no errors).
So then motherboard? But again, seems to be OK?
I will check my motherboard bios, but I am pretty sure when these crashes started it was also up to date at the time, although another release may be out now.
So here I am, I have a PC with all ‘new’ parts in this build other than OS HDD and old PSU. But it would be great to actually pin point the issue without throwing money at something that doesn’t need replacing.
My only other thought is to perhaps play with the CPU voltage, it runs at 1.286v max on auto, with package power around 117w. Temperatures aren’t an issue, so did I get a bad one that just needs more juice to run stable at the stock 4.68? Again if that is the case wouldn’t this manifest in VR?
Pretty much stumped guys, and if you’ve made it this far well done, and thanks for reading.
Seriously welcome any ideas / testing I can do to pin this one down.
Thanks.
I am seeking some assistance from the tom's Hardware collective please to stop me going insane!
First I guess the info of the system:
Windows 10 Pro, build 19044 (up to date)
I9 9900K, not overclocked - bios all default settings / auto
2x8GB Corsair DDR4 2132 w/XMP @ 3596 - non XMP profile loaded
MSI Z390 Gaming Pro Carbon
Nvidia 3090Ti FE
1000w EVGA 80+ modular PSU
Crucial CT250 MX200 SSD for Operating System
Corsair MP600 Core 2TB SSD for game installs
2x WD 2TB standard HDDs
Widescreen 2560x1080 (so not many pixles!)
Quest 2 @ 1.6x SS / 90hz
I built this system around Jan 2022 (originally with my titan XP, then upgraded to 3090ti later in the year).
My issues started not long after building the PC, I purchased BF2042, and when I was playing the game, I experienced random locking up of the PC, with no mini dump, or system errors, only buttoning and rebooting would free up the PC.
I could play a game sometimes for 2 hours or so, other times maybe I couldn’t even play a single round and the PC would lockup.
At this time I had XMP profile loaded, and was running a titan XP. I have only experienced one other lockup, and that was after around 3-4 hours of Warzone, but mostly, all games run OK.
Fault finding:
Re-installed game
Tweaked XMP profile, as notice manufacturer timings differed to what bios was recommending, but still locked up
Removed XMP and set to default speed
Reset bios / CPU settings all to default and auto
Ran numerous OCCT tests, RAM and CPU tests passed
Conducted GPU stress tests with furmark - all passed
Memcheck – passed
Thermals checked – all good (CPU rarely more than mid 60’s, GPU same)
OCCT power test (crashed / locked after around 3 hours)
Checked 3.3v, 5v and 12v for any instability (only via software OCCT) – all good
Underclocked GPU RAM and core clock / reduced power target
Removed / reinstalled GPU drivers
Scanned all HDDs / checked for errors
Fresh install of Windows 10
Added Corsair NVME and fresh install of all game to a new / different HDD
Swapped PSU power connectors to GPU
Have since changed GPU to 3090ti
When the machine locks up, it is often during title screen, loading, after game, although can happen during game.
During last lockup:
CPU @ 49% utilisation
CPU package temp 57c
RAM @ 12GB usage
Disk 0, 1, 2 @ 0% (disk 0 OS volume)
Disk 3 @ 5% (game SSD)
Ethernet usage high-ish 344kbps
GPU usage 11%
GPU power 27%
VRAM 6579mb
GPU temp 53c
There is never anything in the event log I can see other than unexpected shutdowns / kernel power caused by me buttoning.
I also play VR, and I run @ 1.6SS, so that is 5408x2736, this depends on title but according to EVGA my GPU usage can vary from 60ish up to 90% or so. I play Project cars for hours, no problem, and other games such as Alyx, utilising over 16GB VRAM and with high GPU utilisation with no crashing.
The only needle I can find is that last night, on one of the crashes I sat and waited (I have before for a long time and never a BSOD or error), one of my screens went almost black and I did get a BSOD!) now this may be a coincidence, but anyway it was ‘DPC WATCHDOG VIOLATION’ and I had at least a dump file:
On Mon 19/12/2022 21:35:01 your computer crashed or a problem was reported
| Crash dump file: | C:\WINDOWS\Minidump\121922-8828-01.dmp (Minidump) |
| Bugcheck code: | 0x133(0x1, 0x1E00, 0xFFFFF805758FB320, 0x0) |
| Bugcheck name: | DPC_WATCHDOG_VIOLATION |
| Driver or module in which error occurred: | aswVmm.sys (aswVmm+0x28363) |
| File path: | C:\WINDOWS\system32\drivers\aswVmm.sys |
| Bug check description: | The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL or above. This could be caused by either a non-responding driver or non-responding hardware. This bug check can also occur because of overheated CPUs (thermal issue). |
| Analysis: | This is likely caused by a hardware problem, but there is a possibility that this is caused by a misbehaving driver. This bugcheck indicates that a timeout has occurred. This may be caused by a hardware failure such as a thermal issue or a bug in driver for a hardware device. Read this article on thermal issues A full memory dump will likely provide more useful information on the cause of this particular bugcheck. |
| Google query: | aswvmm DPC_WATCHDOG_VIOLATION |
On Mon 19/12/2022 21:35:01 your computer crashed or a problem was reported
| Crash dump file: | C:\WINDOWS\MEMORY.DMP (Kernel memory dump) |
| Bugcheck code: | 0x133(0x1, 0x1E00, 0xFFFFF805758FB320, 0x0) |
| Bugcheck name: | DPC_WATCHDOG_VIOLATION |
| Driver or module in which error occurred: | aswVmm.sys (aswVmm+0x28363) |
| File path: | C:\WINDOWS\system32\drivers\aswVmm.sys |
| Bug check description: | The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL or above. This could be caused by either a non-responding driver or non-responding hardware. This bug check can also occur because of overheated CPUs (thermal issue). |
| Analysis: | This is likely caused by a hardware problem, but there is a possibility that this is caused by a misbehaving driver. This bugcheck indicates that a timeout has occurred. This may be caused by a hardware failure such as a thermal issue or a bug in driver for a hardware device. Read this article on thermal issues A full memory dump will likely provide more useful information on the cause of this particular bugcheck. |
| Google query: | aswvmm DPC_WATCHDOG_VIOLATION |
So I removed and cleaned AVG in safe mode – still had a lock up in BF2042.
When this BSOD was generated thermals were fine, I want to add that on custom settings in BF with everything on ultra, and all additional settings enable, my GPU rarely goes about 38%, so GPU temps in BF are normally in the 50’s or lower, and CPU never goes over mid 60’s.
Windows debugger tells a slightly different story though?
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (16 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff805
74c00000 PsLoadedModuleList = 0xfffff8057582a2b0Debug session time: Mon Dec 19 21:35:01.932 2022 (UTC + 0:00)
System Uptime: 4 days 21:29:46.062
Loading Kernel Symbols
...............................................................
................................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
......................
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff805
74ff92d0 48894c2408 mov qword ptr [rsp+8],rcx ss:ffffbd01de692e20=00000000000001333: kd> !analyze -v
***
- *
- 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: fffff805758fb320, 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: 3749
Key : Analysis.DebugAnalysisManager
Value: Create
Key : Analysis.Elapsed.mSec
Value: 4088
Key : Analysis.IO.Other.Mb
Value: 0
Key : Analysis.IO.Read.Mb
Value: 0
Key : Analysis.IO.Write.Mb
Value: 0
Key : Analysis.Init.CPU.mSec
Value: 249
Key : Analysis.Init.Elapsed.mSec
Value: 3917
Key : Analysis.Memory.CommitPeak.Mb
Value: 86
Key : Bugcheck.Code.DumpHeader
Value: 0x133
Key : Bugcheck.Code.Register
Value: 0x133
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: 121922-8828-01.dmp
BUGCHECK_CODE: 133
BUGCHECK_P1: 1
BUGCHECK_P2: 1e00
BUGCHECK_P3: fffff805758fb320
BUGCHECK_P4: 0
DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
TRAP_FRAME: ffffe403cb271ee0 -- (.trap 0xffffe403cb271ee0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=00000000003506f8
rdx=00000000000c00e1 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80574ebb970 rsp=ffffe403cb272070 rbp=0000000000000003
r8=000000000000082f r9=00000000000000e1 r10=fffff80574f376e0
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
nt!KiIpiSendRequestEx+0xb0:
fffff805
74ebb970 8b87802d0000 mov eax,dword ptr [rdi+2D80h] ds:0000000000002d80=????????Resetting default scope
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: BF2042.exe
STACK_TEXT:
ffffbd01
de692e18 fffff8057505bf02 : 0000000000000133 0000000000000001 0000000000001e00 fffff805758fb320 : nt!KeBugCheckExffffbd01
de692e20 fffff80574ed2973 : 00001796ea01adaf ffffbd01de640180 0000000000000000 ffffbd01de640180 : nt!KeAccumulateTicks+0x186d32ffffbd01
de692e80 fffff80574ed245a : ffffd30b342b6d40 ffffe403cb271f60 0000000000000000 ffff87000beb4d02 : nt!KeClockInterruptNotify+0x453ffffbd01
de692f30 fffff80574e08a45 : ffffd30b342b6d40 fffff80574f545e7 0000000000000000 0000000000000000 : nt!HalpTimerClockIpiRoutine+0x1affffbd01
de692f60 fffff80574ffb26a : ffffe403cb271f60 ffffd30b342b6d40 0000000000000001 0000000000000000 : nt!KiCallInterruptServiceRoutine+0xa5ffffbd01
de692fb0 fffff80574ffba37 : 00000000d79761d4 ffffbd01de643088 ffffe403cb272011 0000000000000003 : nt!KiInterruptSubDispatchNoLockNoEtw+0xfaffffe403
cb271ee0 fffff80574ebb970 : 0000000000000028 fffff80574ebd2e9 0000000000000001 0000000000000000 : nt!KiInterruptDispatchNoLockNoEtw+0x37ffffe403
cb272070 fffff80574eda8ac : 0000000000000000 0000000000000002 0000009000000000 ffff8a0000007000 : nt!KiIpiSendRequestEx+0xb0ffffe403
cb2720b0 fffff80574eda5eb : 0000000000000004 0000000000000000 0000000003800000 0000000000000002 : nt!KxFlushEntireTb+0x1bcffffe403
cb272100 fffff80574e86592 : 0000000000000000 0000000000000000 0000000000000000 fffff80575850b00 : nt!KeFlushTb+0x7bffffe403
cb272160 fffff80574e888d1 : 0000000000000000 0000000000000000 ffff87000beb4d40 ffff87000beb4d40 : nt!MiFlushEntireTbDueToAttributeChange+0x3affffe403
cb272250 fffff80574e3ffd5 : 8a000003f919c96b 0000000000000001 ffff87000beb4d62 0000000000000000 : nt!MiChangePageAttributeBatch+0x91ffffe403
cb2722c0 fffff80574e3cd58 : ffffe403cb272690 0000000000000000 0000000000000001 0000000000000000 : nt!MiGetPageChain+0xd75ffffe403
cb272500 fffff80574e3c2a8 : ffffe403cb272690 ffffe403cb2728e0 ffffd30b00000000 0000000000000000 : nt!MiResolvePrivateZeroFault+0x6e8ffffe403
cb272630 fffff80574e3b67d : 00000000c0000016 0000000000000002 0000000000000000 0000000000000002 : nt!MiResolveDemandZeroFault+0x208ffffe403
cb272720 fffff80574e39769 : 0000000000000111 0000000000000004 00000000c0000016 0000000000000000 : nt!MiDispatchFault+0x22dffffe403
cb272860 fffff80575008dd8 : 000000004e71d084 ffffe403cb272a80 000000004e71d098 0000000000000001 : nt!MmAccessFault+0x189ffffe403
cb272a00 00000001422cc1fc : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiPageFault+0x35800000000
4e718f60 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00000001`422cc1fcSYMBOL_NAME: nt!KeAccumulateTicks+186d32
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
IMAGE_VERSION: 10.0.19041.2251
STACK_COMMAND: .cxr; .ecxr ; kb
BUCKET_ID_FUNC_OFFSET: 186d32
FAILURE_BUCKET_ID: 0x133_ISR_nt!KeAccumulateTicks
OS_VERSION: 10.0.19041.1
BUILDLAB_STR: vb_release
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {65350307-c3b9-f4b5-8829-4d27e9ff9b06}
Followup: MachineOwner
---------
In a last ditch attempt at anything meaningful, I noticed some DPC watchdog errors related to iastora.sys, and so re-installed the driver for the OS SSD, but you guessed it, still several lockups this evening, resulting in me buttoning the PC and no dump files, nothing I can see being meaningful in event viewer.
I am now leaning towards a PSU issue, it is after all, 7 years old now! However, if BF2042 is taxing my system less overall than running 14 million pixels in VR, and drawing a hell of a lot more power, how can it be stable there and fall over when ticking over in BF2042?
The PSU is a single rail, but I am not familiar with how the CPU / mobo circuit works vs PCIE and HDD supply.
My other thoughts were HDD, but the OS HDD although also an older crucial drive from a previous build seems reliable – no vanishing files, no corrupt files or weirdness, no errors.
With power ‘appearing’ stable in VR and OCCT tests I am not sure.
Perhaps I got a dodgy stick of RAM, but memtest checks out, and OCCT memory tests always seem to work just fine using 95% of memory.
Maybe I got a dodgy CPU? But a CPU burn or stress test at 100% also seems stable (I’ve done more memory and CPU tests this eve on OCCT and all good, no errors).
So then motherboard? But again, seems to be OK?
I will check my motherboard bios, but I am pretty sure when these crashes started it was also up to date at the time, although another release may be out now.
So here I am, I have a PC with all ‘new’ parts in this build other than OS HDD and old PSU. But it would be great to actually pin point the issue without throwing money at something that doesn’t need replacing.
My only other thought is to perhaps play with the CPU voltage, it runs at 1.286v max on auto, with package power around 117w. Temperatures aren’t an issue, so did I get a bad one that just needs more juice to run stable at the stock 4.68? Again if that is the case wouldn’t this manifest in VR?
Pretty much stumped guys, and if you’ve made it this far well done, and thanks for reading.
Seriously welcome any ideas / testing I can do to pin this one down.
Thanks.
Facebook
Twitter
Instagram