Bluescreen unter Windows 10

Hallo zusammen,
ich habe seit ich meinen Rechner habe immer mal wieder Bluescreens, die sich in letzter Zeit häufen. In den meisten Fällen treten diese bei
Leistungsintensiven Spielen auf. Am häfigsten ist der Stopcode "IRQL_NOT_LESS_OR_EQUAL". Ich habe bereits meine Treiber überprüft,
mehrfach "sfc /scannow" dürchgeführt, meine Platten gecheckt, Graka in einem anderen Rechner getestet und meinen RAM überprüft.

Mein System:
WINDOWS 10 PRO
ROG STRIX Z390-F GAMING
i7-8700K @ 3.70GHz - OC auf 5.00 GHz (Temperaturen liegen unter lasst bei ca. 65 Grad im schnitt)
G.Skill RipJaws V DDR4-3200 2 x 16GB CL16 (timings stimmen)
Samsung 860 EVO M.2
Samsung 970 EVO m.2
NVIDIA GeForce RTX 2080 Ti
ASUS Essence STX II

Gespielt wird in WQHD auf einem Dell S2716DG (G-Sync aktiviert), als Anzeigeerweiterung wird ein Dell P2418 verwendet.
Ich habe die letzen 3 Minidumps angehängt, da die vergangenen, warum auch immer, nicht mehr da sind.

Ich hoffe das mir hier jemand weiter helfen kann um mein Problem in den griff zu bekommen.
Danke schonmal im voraus.

Die Minidumps sind erwatungsgemäß unergiebig, ein randalierdender Treiber ist nicht auszumachen.

>OC auf 5.00 GHz<

Hier könnte instabiler RAM oder instabiler MemoryController die Ursache sein, entsprechend die Spannung des RAM oder QPI/VTT vorsichtig anpassen.

Eventuell kann auch der Driver verifier etwas bringen, der "beobachtet" laufende Treiber, bei Fehlern gibts dann einen beabsichtigten Bugcheck (Bluescreen) mit dem "schuldigen" Treiber.

Driver Verifier - Windows drivers | Microsoft Docs

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


Loading Dump File [E:\HELP\Blackwolf\021519-8453-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\Symbols*Symbol information
Executable search path is:
Windows 7 Kernel Version 17763 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 17763.1.amd64fre.rs5_release.180914-1434
Machine Name:
Kernel base = 0xfffff804`7c606000 PsLoadedModuleList = 0xfffff804`7ca21ad0
Debug session time: Fri Feb 15 19:04:44.765 2019 (UTC + 1:00)
System Uptime: 0 days 4:41:30.777
Loading Kernel Symbols
...............................................................
................................................................
........................................................
Loading User Symbols
Loading unloaded module list
.......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {4588c122, ff, 0, fffff8047c7baabc}

Probably caused by : ntkrnlmp.exe ( nt!KiInterruptSubDispatch+1c )

Followup: MachineOwner


---------

11: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

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: 000000004588c122, memory referenced
Arg2: 00000000000000ff, IRQL
Arg3: 0000000000000000, 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: fffff8047c7baabc, address which referenced memory

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


READ_ADDRESS: 000000004588c122

CURRENT_IRQL: 0

FAULTING_IP:
nt!KiInterruptSubDispatch+1c
fffff804`7c7baabc 440f22c1 mov cr8,rcx

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xA

PROCESS_NAME: System

LAST_CONTROL_TRANSFER: from fffff8047c7cac69 to fffff8047c7b9440

STACK_TEXT:
ffffd900`8b33bcb8 fffff804`7c7cac69 : 00000000`0000000a 00000000`4588c122 00000000`000000ff 00000000`00000000 : nt!KeBugCheckEx
ffffd900`8b33bcc0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!KiInterruptSubDispatch+1c
fffff804`7c7baabc 440f22c1 mov cr8,rcx

SYMBOL_NAME: nt!KiInterruptSubDispatch+1c

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: X64_0xA_nt!KiInterruptSubDispatch+1c

BUCKET_ID: X64_0xA_nt!KiInterruptSubDispatch+1c

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

11: kd> kb
RetAddr : Args to Child : Call Site
fffff804`7c7cac69 : 00000000`0000000a 00000000`4588c122 00000000`000000ff 00000000`00000000 : nt!KeBugCheckEx
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
11: kd> kv
Child-SP RetAddr : Args to Child : Call Site
ffffd900`8b33bcb8 fffff804`7c7cac69 : 00000000`0000000a 00000000`4588c122 00000000`000000ff 00000000`00000000 : nt!KeBugCheckEx
ffffd900`8b33bcc0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69

RAM Spannung liegt bei 1.350
QPI/VTT oder wie auch immer Asus das nennt finde ich beim besten willen nicht

Update zur Situation:
Nächster Bluescreen, Minidump im Anhang.

Vcore liegt für 5GHz (AVX ?) wo unter prime95 Last?
Bitte auch mal SA / IO unter Last auslesen.
Wie hast du Vcore für den OC eingestellt fix, offset oder addativ?

Eingestellt
Vcore - 1.314 (fix)
AVX offset - 3
IO - 1.328 (auto)
SA - 1.216 (auto)

unter Last
Vcore - 1.341
AVX offset - X
IO - 1.360
SA - 1.232

Temperaturen liegen bei 75 Grad

Edit:
Gefühlt treten seit dem letzem Treiber Update von Nvidia vermehrt Bluescreens auf, wären es davor alle 2-3 Tage war ist es jetzt 2-3 mal Täglich.

Edit2:
Da ist der nächste, Dump im anhang.

Es gab:

•2 Bugcheck 0xA IRQL_NOT_LESS_OR_EQUAL
FAILURE_BUCKET_ID: X64_0xA_nt!KiInterruptSubDispatch+1c bzw.
FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

•2 Bugcheck 0x3B SYSTEM_SERVICE_EXCEPTION
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Speicherzugriffsverletzung
PROCESS_NAME: Anthem.exe

•einen Bugcheck 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

A) Lösung für Softwareproblem könnte wie bereits erwähnt der Driver verifier sein.

B) Hardwarelösung für:

0xD1: QPI/VTT, increase/decrease as necessary, can also be unstable Ram, raise Ram voltage
0xA: unstable RAM/IMC, increase QPI first, if that doesn't work increase vcore
0x3B: increase vcore

Irql ist immer ram
Um das zu beheben muss man an den IO und an imc spannung angehoben werden
Was ich nicht empfehlen kann
Dies ist unter xmp oft automatisch angehoben
Oc man dazu muss diese weiter angehoben werden
das ergebnis- ist hohe temps und Schäden an der cpu
man kann ohne Probleme an der cpu vcore herumspielen das macht kaum was aus
außer es wird wärmer
bei vccio und vtt allerdings greift das direkt den imc in der cpu an
beim vccio kann sogar der mainboard bus (ringbus) beschädigt werden
dabei max
vccio 1,1v (cache)
vtt 1,1v (imc)
vcccin 1,9v Eingangsspannung von dieser wird alles abgeleitet
vcore cpu binning abhängig bei HEDT unnötig zu verändern
LLC je kleiner desto instabiler
Wichtig sind tdp long duration, short
und dauer des Turbos
cernümftigr werte sind
long 130w
short 180w
duration ~30 Sekunden (fürn benchmark)
-4 avx offset
Rest auto
man kan noch LLC auf extreme setzen 8kaum spannungsabfall
vcore ist schwierig da man geflegst raten kann.
Mein tipp spannung ansteigen lassen von möglichst niedrigen wert aus.
bsp last auf @stock vcore ohne boost 1,00v
LLC extrem dann geht bis 1,1v in 4 Stufen
das ist aber vom mainboard abhängig ob den positives LLC beherrscht.
Vorteil niedrigere Stromverbrauch bei stock (quasi uv) max takt und verbrauch oc
Nachteil hat nicht jedes mainboard

Warum die vcore egal ist
nun LLC basiert darauf das die spannung bei last fällt und somit spitzen zu vermeiden ie die cpu schädigen können
Den spannungsabfall kann man staffeln in 4 Stufen
4 Stufe also normal bis zu 0,025*4=-0,1v

1 hoch =-0,025v - -0,05v
bis extreme ist die stufe +1 von vcore aufwärts 4 stufen +0,1v
bsp
@oc 1,175v LLC normal dann -0,1v auf 1,075v LCC extreme dann stellt man 1,075v ein und addiert dann 0,1v dazu
dabei kann man die vcore sogar senken
also für base auf bsp 4,3ghz und 1,0v turbo auf 4,7 auf 1,1 auto per llc
will man mehr kommt man nicht um mindestens die vcore anzulegen die das uefi bei 4,7 allcore anwendet eventuell schafft man etwas weniger (ist aber die Ausnahme)
Denn die vcore hängt vom mainboard vrm ab, da kann die cpu noch so gut gebinnt sein sobald die vrm versagen ist die vcore dennoch hoch und die cpu dementsprechend warm

Stabil ist erst ein System wenn es ohne Fehler läuft
indikator bei test
cinebench weil es echt empfindlich reagiert bei cpu fehlern und cache fehler(ram)
prime und die temp zu finden
memntest86 v5 um den speicher zu prüfen ob xmp läuft.
ansonsten 3dmark
und einen h265 encode test video FHD 30min, je nach cpu kann das mal gut 3 std dauern
im übrigen temp sowie stabilitätstest.
Sollte als finnish gelten wo man sich fast sicher ist
ansonsten beobachten wie das System reagiert sobald irgendwas abstürzt und ein driver Fehler ausgeschlossen werden kann sollte man seine Settings prüfen ob diese ausreichen.
Zumal bei nen 8700k Oc eher prestige ist als notwendig.

UPDATE:
Ich habe am Samstag meinen Rechner mal neu aufgesetzt und bis jetzt lief alles ohne Probleme, jetzt gerade habe ich allerdings wieder einen Bluescreen gehabt. Ich werde mal versuchen mein system ohne OC laufen zu lassen um zu gucken ob das stabiler ist.
Minidump wie immer in Anhang.

System service exception
Simple filesystem beschädigt oder ram Fehler
Sfc /scannow
und
chkdsk C: \ f/r
ram auf jedec Einstellen
testen memtest86 v5, gebrannte cd oder usb stick

Habe "Sfc /scannow" durchlaufen lassen, hat auch was gefunden, log im anhang.
chkdsk C: \ f und /r sind auch durchgelaufen.
Memtest mache ich heute nacht.