Alles wird er nicht ganz abschalten können, schätze ich Mal. Was ginge, wäre es, einfach die Treiber allesamt nicht zu installieren, und erst Mal so zu testen. Dann installiert man einen Treiber nach dem anderen, und testet nach jeder Installation ausgiebig das System, um den Auslöser letztendlich zu finden.
Allerdings ist das ein ordentlicher Aufwand... und wer weiß, ob es nicht auch noch Wechselwirkungen zwischen einzelnen Treibern gibt.
Ich schätze das hat dann wohl irgendwas mit der Systemfirmware oder mit einem der Treiber zu tun. Vielleicht mag irgendeine Komponente auf dem Brett einfach das Betriebssystem nicht, oder die Systemfirmware hat irgendeinen Bug, der nur bei NT5.x Kerneln schlagend wird. An diesem Punkt isses echt schwer zu sagen.
Wenn du mit aller Härte drauf aus bist, AM3+ mit XP x64 zu verheiraten, dann bleibt dir eh fast nur ein Herstellerwechsel (ASRock? ASUS?), ggf. in Verbindung mit einer Kompatibilitätsrecherche zu jedem einzelnen Chip auf dem Brett und Win XP, sowie dem Board an sich mit Win XP.
Die Unmöglichkeit, die Minidumps per BlueScreenView zu analysieren macht das alles noch viel schwieriger... Weil sonst hätte sich vielleicht ein bestimmter Treiber/Chip als Verursacher herauskristallisieren lassen.
Aah, also so funktioniert das... Alles klar! 
Hab' die originale MX518 an meiner Linux Workstation auf der Arbeit. Und die bleibt da auch! 
Moment Mal... man korrigiere mich, falls ich bei der Idee falsch liege, aber... wieso ist noch keinem Flacherdler eingefallen, einfach die Fliehkraft durch die Scheibenrotation zu messen (müßte es ja geben, wenn sich das Ding um die Normale zur Scheibenebene dreht), und deren Vektor einfach nachzulaufen, bis man am Rand steht, und runterschauen kann? Das wäre der kürzeste Weg von einer gegebenen Position zur Scheibenkante...
Oder gehen die Flacherdler noch von einem geozentrischen Weltbild mit statischer Erde aus?
Wird halt so rasant laufen wie frischer Teer, wenn man keine RT Cores hat...
Das ist ausgesprochen seltsam... Kann ich mir nicht erklären. Wo hat Windows dann beim BSOD das Speicherabbild hingelegt.. Weil wenn der Dump fehlschlägt, kriegst am Ende vom BSOD normal noch eine entsprechende Fehlermeldung (z.B. wenn disk.sys und/oder ntfs.sys abgeschmiert sind, dann kann er den Dump auch nicht mehr ablegen).
Verwirrt mich, wieso Windows den Dump erfolgreich gespeichert haben will, selbiger dann aber nicht da oder leer ist...
Full Dumps (wenn aktiv) finden sich in der Einzeldatei %SYSTEMROOT%\MEMORY.DMP. Die üblicheren Minidumps finden sich in den Dateien %SYSTEMROOT%\Minidump\*.dmp. Das erste Icon in der BlueScreenView Menüleiste ganz links bringt dich zu den erweiterten Optionen. Hier kannst du auswählen, von wo du die Minidumps lesen möchtest. Damit ist es auch machbar, die Dumps von irgendwelchen anderen Ordnern einzulesen.
Er hat einen Dump (=Speicherabbild) auf deiner Systempartition erzeugt, siehst du am Ende deines Bluescreens. Wenn du einen Dump hast, dann findet BlueScreenView den auch. In dem Tool siehst du dann alle vorhandenen Dumps nach Datum sortiert, da pickst du dir einfach den letzten raus. Dann bekommst du einen Stacktrace (=Stapelverfolgung), in dem alle abgestürzten Kerneltreiber rot markiert sind.
Oft sind es mehrere Treiber, weil die sich auch oft in einem separaten Stack befinden. So z.B. der I/O Stack, wo disk.sys, ntfs.sys und IDE/SATA/SCSI Controllertreiber und auch Dinge wie Veracrypt oder Bitlocker drinstecken, oder der Netzwerkstack, wo tcpip.sys, Netzwerkkartentreiber, Firewalltreiber usw. zusammen sitzen.. d.H. ein crashender Treiber kann weitere Treiber, die von ihm abhängen mit in den Tod reißen.
Alle rot markierten Einträge in der Liste wären von Interesse.
Sind wohl Threads im Hintergrund abgestürzt bzw. in undefinierbare Zustände geraten, o.ä.
Wäre jedenfalls eine neue Form von Absturz. Normalerweise bricht der Test einfach hart ab, wenn irgendwas grobes schief läuft. Btw., der x265 Benchmark hat hierfür eine bessere Fehlerbehandlung eingebaut, zu sowas war ich beim Start vom x264 Benchmark Projekt noch nicht so Recht imstande. Teufel, das ist ja auch schon ewig her, grade geschaut... 2010. Himmel hilf, Ewigkeiten sind das!
Ist drin!
Habe dabei noch eine Unstimmigkeit in der Liste ausgebessert. ASUS enumeriert die Dinger in römischen Zahlen. In der Liste war das noch ein Mischmasch. Alle Rampage 3, 4, und 6 Extreme Boards sind jetzt korrekt als "Rampage III Extreme", "Rampage IV Extreme" und "Rampage VI Extreme" gelistet. Das "Rampage V Extreme" mit dem X99 Chipsatz ist bislang nicht vertreten.
Du könntest jetzt noch NirSofts' [BlueScreenView] ausprobieren, um den Kernel Minidump zu analysieren. Ist ein recht simpler Kernel Stacktracer. Das Tool ist recht einfach zu bedienen, und erlaubt es dir, mit relativ hoher Treffsicherheit zumindest die Komponente zu identifizieren, die zum Kernel BSOD geführt hat. Wenn es der SATA Treiber und/oder disk.sys war(en), dann wäre das Problem eh schon recht gut eingegrenzt.
Ist drin!
666psycho : Nach einigem Nachforschen scheint der Fall relativ klar zu sein. Sowohl die Windows Tools wie auch ASUS selber bekleckern sich da nicht grade mit Ruhm, was die Spezifizierung der verbauten SnapDragon 835 CPU angeht.
Der hat also 4 ARM Cortex A-73 Kerne mit 2.6GHz und 4 ARM Cortex-A53 Kerne mit 1.8GHz. Was Windows (und ASUS) da tun, ist etwas recht... dämliches: 4 × 2.6GHz + 4 × 1.8GHz = 17.6GHz. 17.6GHz / 8 Kerne = 2.2GHz pro Kern. So die Milchmädchenrechnung. Daß die unterschiedliche IPC der A73 und A53 Kerne aber schon auch noch eine Rolle spielt, wird dabei außen vor gelassen. Den typischen Endverbraucher wird's wohl nicht kümmern. Habe den Eintrag entsprechend ergänzt.
Wobei man diese big.LITTLE Systeme noch besser darstellen könnte... aber es gibt so wenige Einsendungen für solche Chips, daß es sich wohl nicht auszahlt, Code und Datenbank zu erweitern. Zumindest vorerst nicht.
Da frage ich mich, wie das genau laufen soll. Damit Glide Sinn macht, müßten's ja auch ziemlich alte Betriebssysteme unterstützen mit dem Spiel.. Aktuell setzt's ja mindestens Windows 7 voraus, offiziell halt zumindest.
Aktuell bei mir (mit ASUS Spiegel) 1,47TiB / 1.511,73GiB. Ich empfehle eh den Upload zu konstl, einfach weil er viel schneller unterwegs ist, als ich mit meinem Server. Der ASUS Upload zu ihm ist aber noch nicht abgeschlossen, das schreibe ich extra hier rein, wenn's soweit ist. Hab da extra einen Unterordner ongoing_uploads/ angelegt, damit keiner versucht, das noch unfertige File zu laden.
400-500 Stunden dauert der Upload noch so ca.
Und mein Account hat nach der Servermigration von konstl ohne weiteres wieder funktioniert, mit dem selben Passwort.
Ich hab's zwar eh im IRC schon gesagt, nachdem du das Netzteil als Ursache ausgeschlossen hast, aber ich wiederhole mich hier Mal: Mich besorgt das ziemlich... Eigentlich habe ich dein ASRock X399M Taichi ja auch für meine künftige Ripper Maschine eingeplant... Ich hoffe Mal daß das kein grundlegend problematisches Modell ist. Ersatz gibt's dafür ja keinen im µATX Bereich.
Ich weiß, daß man den DNS Server von MS programmatisch steuern kann. Ich glaub es geht auch per netsh oder war's wmic? Egal, auf jeden Fall geht's. Ich weiß nur nicht, ob man ihm erklären kann, daß er für gewisse Domänen gleich 0.0.0.0 zurückgeben soll. Vor allem wenn ihm die Domänen gar nicht gehören (also keine Subdomänen der eigenen Domäne sind).
Wie gesagt, ich kenne mich mit dem Trumm überhaupt nicht mehr aus. Mein letzter MS DNS Server... das war vor 17 Jahren oder so ca., mit Windows 2000. 
Ich kenne mich mit der Konfigurierbarkeit des Microsoft DNS Servers nicht so aus, daher weiß ich nicht, ob er die Rolle von dnsmasq im Pihole ersetzen kann. Wie flott der dann mit einer riesigen Blacklist wäre, das könnte man nur durch einen praktischen Test nachweisen. Ich habe keinen rumstehen, daher kann ich das nicht testen.
Abschließend möchte ich noch dazusagen, daß mein Batch Skript eine schöne Übung war, aber leider keine brauchbare Lösung bringt bzw. keinen Ersatz für Pihole darstellen kann. Nach dem Einpflegen der Hosts in die hosts-Datei muß noch der lokale DNS Cache updated werden (ipconfig /displaydns 1>NUL 2>& tut das, was bei 2 Millionen Hosts aber ewig dauert). Tut man das nicht, bekommt man bei DNS Abfragen nur mehr Timeouts, weil Cachemodifikationen so lahm sind.
Selbst wenn der Cache live ist, spürt man einen deutlichen Lag bei allen DNS Abfragen, und die werte svchosts.exe ist im Hintergrund fest am Arbeiten und CPU Konsumieren.
Fazit: Pihole ist scheinbar ungleich schneller, als die Verarbeitung der hosts-Datei und des lokalen DNS Caches durch Windows.
Also doch arg thermisch capped (gewesen)... Ist aktualisiert.
