À propos de __Seraph_

Hallo zusammen,   ich hoffe, ich poste das in den richtigen Bereich. Vor ca. 1 Monat hatte ich starke Probleme mit ständigen Freezes nach 5 min. Ursache war der Task Secure-Boot-Update, über den Windows versucht, automatisiert die 2023 auslaufenden Secure Boot Zertifikate auf die 2023-Versionen upzudaten (im Detail: siehe mein Beitrag hier). Nach nun ungefähr 1 Monat und stundenlangem Testen allen möglichen Anleitungen habe ich tatsächlich einen Weg gefunden, wie man die Updates doch installiert bekommt. Wesentlich einfacher wäre das alles, wenn Hersteller für ältere Systeme auch ein Bios-Update bereitstellen, da der Weg über Windows oft nicht funktioniert. Leider ist das aber nicht so.   Hinweis: Ich bin kein IT-Experte und ich war mir bewusst, dass das auch nach hinten losgehen kann. Dennoch will ich nachfolgende Infos nicht für mich behalten, sondern teilen. Wer es nachmacht oder teilweise versucht: Auf eigenes Risiko und eigene Gefahr. Ich kann nicht versichern, dass das überall funktioniert.   Der einzige Workaround, um diesem Freeze sinnvoll zu entkommen, war bislang a) Secure Boot deaktivieren oder b) den Task in der Aufgabenplanung deaktivieren. Da ich aber keine Lösung für sinnvoll hielt und meinen PC nicht zu Elektroschrott machen wollte, habe ich recherchiert. Ja, der PC ist alt, aber für mich reicht er noch vollkommen. Hier noch die wichtigsten Systeminfos: Modell: Medion Akoya P5378I (über die Jahre allerdings stark modifiziert) CPU: Intel i7-6600 GPU: AMD Radeon RX6500 XT OC RAM: 2x 16 GB DDR4-2133 Mainboard: Medion H110H4-EM v1.05 OS: Windows 10 22H2 (für ESU registriert)   Ich versuche es möglichst detailliert zu beschreiben, sodass andere mit demselben Problem ggf. selbst abwägen können, was sie tun wollen/können oder nicht. Für einige Begrifflichkeiten und Funktionen würde ich gerne auf das Internet oder Gemini verweisen. Ja, am Ende hat mir die KI dabei geholfen, das Problem zu lösen, auch wenn es ein sehr mühsamer Weg mit etlichen Fails war.   Am Ende hing der Windows-Update-Prozess am Fertigstellen der Aktualisierung der Secure-Boot-Variablen im NVRAM des Mainboards. Insgesamt gibt es 4 neue Zertifikate, die dafür sorgen, dass Windows nach Ablauf der 2011-Zertifikate in 2026 mit Secure Boot hochfährt. Wenn hier eine Verletzung der Validierung stattfindet, bekommt man bei aktivem Secure Boot einen roten Bildschirm "Secure Boot Violation" und kann in diesem Zustand grundlegend erst mal nicht booten. Die 4 Zertifikate sind in verschiedenen Datenbanken abgelegt. Insgesamt gibt es: PK (Platform Key) KEK (Key Exchange Key) db (eine Art Whitelist für Zertifikate) dbx (Revocation List, eine Art Blacklist für ungültige Zertifikate, die geblockt werden). Das Ganze folgt nach meiner Info einer sog. Root of Trust, d.h. der PK steht über allem und wird i.d.R. vom Hersteller (OEM) verwaltet. Er autorisiert Änderungen am KEK. Der KEK wiederum überwacht die Änderungen an db und dbx. Dazwischen gibt es alle möglichen Ausprägungen und es funktioniert auch nicht immer alles nach Lehrbuch, insbesondere bei abgespeckten oder modifizierten OEM-UEFI-Versionen.   Im Internet findet ihr etliche Anleitungen, wie man den Zustand des Updates prüfen kann. Am einfachsten ist die Nutzung von Skripten, die man auf GitHub finden kann. Alternativ kann man sich das auch in der Registry ansehen. Dafür dem Pfad Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing folgen.   Zertifikatsübersicht Ihr braucht folgende Zertifikate, damit das System komplett auf neuem Stand ist. Es sind grundsätzlich nicht alle unbedingt nötig, das hängt aber davon ab, welche Hard- und Software ihr habt. Daher habe ich da nicht groß geschaut und versucht, alles auf Stand zu bringen. Microsoft Corporation KEK 2K CA 2023 (KEK) Windows UEFI CA 2023 (db) Microsoft UEFI CA 2023 (db) Microsoft Option ROM UEFI CA 2023 (db) Wichtig ist, dass das mindestens in der sog. Current-Database enthalten ist. In den Default-Databases nicht zwingend, denn die werden nur mit einem richtigen Bios-Update aktualisiert und stellen dann auch die Werkseinstellung dar. Bei älteren Geräten wird hier vermutlich immer nur die 2011-Version stehen bleiben. Das muss man auch bei einem Reset wissen, die 2023-Zertifikate sind dann nämlich erst mal weg.   Fehlerursache Warum schlägt das Update überhaupt fehl? In der Theorie sollte das bei den meisten Geräten alles klappen. Ich konnte bei meinem Medion-Motherboard feststellen, dass es einfach nicht dieselben Spielregeln hatte. Eine Ursache wäre gewesen, dass schlichtweg der Speicherchip des Bios voll ist. Er ist für heutige Verhältnisse sehr klein, bspw. 8 MB. Darauf muss alles Platz haben. Für jede Funktion ist ein Bereich definiert. Wenn voll, dann voll. Gerade die dbx-Updates werden vergleichsweise groß und beinhalten hunderte Einträge. Gerade da scheitert es bei älteren Geräten oft. Da es letztlich geklappt hat, ist es das doch nicht gewesen.   Bei dem H110H4-EM war es schlichtweg, dass das UEFI keine Schreibvorgänge, die von Windows aus initiiert wurden, zuließ oder zumindest die Befehle nicht verarbeiten konnte. Ergebnis: Der Update-Task sendet ein To Do aus und das UEFI meldet sich nicht. Der PC friert ein oder quittiert den Dienst, weil man in geschützte Bereiche reinschreiben will. So zumindest meine Theorie.   Werkzeuge und Tools Auch hier vorab: Nur mit Windows-Bordmitteln kommt man zu nichts. Man braucht grundlegend nur Software, sollte sich für den Ernstfall, aber auch geeignete Hardware aneignen. Ich möchte nicht zu weit ausholen, wer tiefer einsteigen will kann die KI fragen, die gibt relativ gut Auskunft und unterstützt auch beim Finden dieser Sachen. Ich habe am Ende nicht alles benötigt, aber es hat mir beim Weg dorthin geholfen: oben genannte GitHub-Skripte zur Kontrolle des Erfolgs, alternativ das Modul UEFIv2 via PowerShell installieren, sodass man damit die Variablen auslesen kann. IntelCSTools (auch auf GitHub zu finden). Das sind ziemlich mächtige Tools, um direkt auf Firmware-Ebene einzugreifen. Für jede Generation an CPUs braucht es eine andere Version, für Generation 6 Skylake braucht man die Tools in der v11. Darin relevant dann eigentlich nur das Flash Programming Tool, für 64-Bit-Systeme unter WIN64. USB-Stick, FAT32-formatiert ein Hex-Editor wie HxD sowie das Tool UEFITool NE A73 schaden nicht. Damit kann man sich Bios-Files und Zertifikats-Dateien (teilweise) ansehen, um ein wenig besser zu verstehen, was da genau passiert. Für die finale Lösung ist es nicht unbedingt nötig. Auch das Tool AMIBCP von American Megatrends Inc. (Bios-Software) ist nützlich, aber man braucht es nicht unbedingt. Damit könnte man sein Bios-File modifizieren. Ich hatte zunächst gedacht, durch Freischalten versteckter Menüs für das Key-Management komme ich zum Ziel, war aber glaub auf dem Holzweg. Ein CH341-Programmer. Den gibt es billig als China-Ware für 10 Euro oder auch professionell für hunderte Euro. Das ist eine Programming-Hardware mit USB-Anschluss. Damit kann man mittels einer Klemme oder durch Auslöten des Bios-Chips sowohl enthaltene Daten darauf lesen oder schreiben. Sowas habe ich mir gekauft, falls ich was zerschieße und mein PC nicht mehr startet. Da man dann keine Benutzeroberflächen mehr hat, bleibt einem nur das Flashen des Chips mit einem Programmer. Das ist also eher ein Backup. Man muss sich dazu dann im Internet eine passende Software sowie den fürs System geeigneten Treiber suchen, bspw. NeoProgrammer. Wenn alles klappt, braucht man das Teil nicht. Man kann mit dem o.g. auch ein Backup erstellen Flash Programming Tool (nur wenn der Chip nicht teils gesperrt ist, sonst hilft nur ein Auslesen mit der Hardware). Wenn man sich einen solchen Programmer holt, dann sind diese oft falsch geschaltet. Bios-Chips laufen entweder mit 3,3 V oder 1,8 V. In meinem Fall 3,3 V. Der Programmer stellt das auch grundlegend bereit, aber nicht an allen 8 Pins. Daher sollte man den Programmer modifizieren, dass auf allen relevanten Leiterbahnen 3,3 V anliegen. Ansonsten besteht die Gefahr, den Chip zu zerstören. Anleitungen gibt es im Netz genug. KeyTool.efi Das ist eine Art Programm, welches man noch vor Windows direkt im Bios ausführt. Es ist ein sehr wirksames Werkzeug, um Variablen direkt in den NVRAM zu schreiben. Das wird am Ende auch die Software sein, die das Update ermöglicht. Hier muss man aber ewig suchen, bis man das findet. Man muss es im .efi-Format haben und dann auf dem USB-Stick einen Ordner EFI, Unterordner BOOT anlegen. Da rein muss dann KeyTool.efi, wobei man es in BOOTX64.efi umbenennen muss, damit es gefunden wird. Startet man den PC, muss man schnell F8 drücken, bis man ins Bootmenü kommt. Dann wählt man nicht den Windows Boot Manager, sondern den Stick und man startet das Tool. Gefunden habe ich das mithilfe von KI aus einem Debian-Paket. Es hieß efitols_1.9.2.-3_amd64.deb. Shell.efi Das ist eigentlich eine Art cmd auf Bios-Basis. Ich habe es am Ende nicht gebraucht. Damit könnte man auch direkt auslesen und schreiben. Auch das findet man nur auf Umwegen, ich weiß gar nicht mehr genau, wo ich es her habe. Ich meine aus einem Linux-Paket.   Vorbereitung Um für etwaige Ausfälle bestmöglich gerüstet zu sein, habe ich folgendes gemacht. Jeder muss selbst entscheiden, was er tun will. Einen Klon meiner SSD, damit ich im Falle eines Windows-Fehlers nur die Festplatte tauschen muss und dann bin ich wieder auf Stand vorher. Das kann man bspw. mit Macrium Reflect machen. Ein Backup vom Bios-Chip. Falls irgendwas schiefläuft, kann man damit 1:1 Byte für Byte auf den Chip zurückschreiben und das System sollte wieder booten. Das gilt nur für Software-Fehler. Zerstört man die Hardware, müsste man einen neuen Chip einlöten. Für das Backup kann man entweder das Intel Flash Programming Tool verwenden oder mit dem CH341-Programmer direkt auslesen. Wichtig dabei: Für ein Backup braucht man immer einen sog. Full-Dump, d.h. alles. Wer mittels Software nur das Bios sichert, hat bei einem Brick keinen wirklichen Vorteil. Muss man doch mit dem Programmer den Chip neu beschreiben, so wird i.d.R. zunächst alles gelöscht und dann beschrieben. Dann wäre nur das Bios-File auf dem Chip und das geht nicht. Jedes Byte muss an der vorgesehenen Stelle sein. Erstaunlicherweise hat Medion in dem Board keinen Schutz verbaut, sodass man es mit dem komplett Flash Programming Tool auslesen kann. Der Full-Dump hatte bei mir dann 8.192 KB, das isoliete Bios-File hätte nur 6.148 KB. Das muss man unbedingt vorher prüfen, sonst muss man es über den Programmer direkt am Chip auslesen. Das Bios-File allein ist eigentlich nur für Bios-Mods sinnvoll. Ein Export der aktuellen Secure-Boot-Variablen (PK, KEK, db und dbx). Das kann man direkt im Bios über "Export Keys" machen, wenn man Secure Boot in den Custom Mode umstellt oder man nutzt KeyTool.efi. Letzteres hat den Vorteil, dass man sowohl eine gesamte Zertifikatsliste als auch die einzelnen Zertifikate sichern könnte. Wichtig: Solange Secure Boot noch aktiv ist bzw. die Keys gesetzt sind, bringt der Export allein noch nicht viel. Der ist für die Modifikation später aber hilfreich. WSL (Windows Subsystem for Linux) Ehrlicherweise weiß ich gar nicht genau was das ist. Ich verstehe darunter eine unter Windows lauffähige Oberfläche, über die man Linux-Distributionen (bei mir Ubuntu) bzw. deren Befehle, die es bei Windows nicht gibt, in einer Art cmd-Kommandofenster nutzen kann. Am Ende ging es nur damit. Die KI führte mich aber gut durch die Installation. Das Ganze wird über PowerShell angestoßen. Sonstige Sicherungen, die einem wichtig erscheinen.   Gescheiterte Lösungsansätze Um allen unnötige Ansätze zu ersparen, teile ich euch meine Erfahrungen. Ich bin seit Anfang März 2026 bis gestern nahezu täglich nach der Arbeit am PC gesessen und habe Lösungen gesucht, die auch ein "normaler User" bewerkstelligen kann. Am Ende ging es aber nicht und ich musste mich technisch weiterbilden: Learning by doing. Egal wie man es direkt über Windows machen will, es klappt nicht. Es ist kein direkter Zugriff auf die Variablen im UEFI möglich. Restore Factory Keys im Bios ist auch nicht zielführend. Damit löscht man die Current-Database und setzt alle Variablen zurück. Man kann dann zwar den Update-Vorgang neu starten, aber es kommt wieder zum Freeze. Es wurden bei mir nur 2 Zertifikate installiert, der Rest geht nicht. Warum? Weil es 2 db-Zertifikate waren, die über den KEK 2011 legitimiert wurden, ab dann ging nichts mehr. Am Ende muss man versuchen, die Keys manuell zu importieren. Zwischenfazit: Man braucht gewisse Tools dafür, alles andere erscheint unsinnig. Nicht, dass es nicht geht, es ist schlichtweg zu fehleranfällig. Ich habe mittels KeyTool.efi zunächst versucht, einzelne Keys hinzuzufügen. Das führte zu mehreren Problemen. Die Funktion "Add Keys" gibt es zwar, wird vom Medion-Board aber nicht zugelassen. Wenn man mithilfe von KI und einem Hex-Editor mehrere Zertifikate/Keys zusammenführen will, geht das zwar technisch führt aber zu folgenden Fehlern: Es ist das falsche Format, es fehlen gewisse Header (Security Violation beim Import), die Bytes passen nicht (Alignment führ zu Invalid Parameter) oder man schafft es irgendwie mehrere Zertifikate in einer Datei unterzubringen, aber das Bios erkennt das dann nur als 1 riesiges Zertifikat, weil in der Datei keine saubere Trennung drin ist. Falls es bei jemandem klappt: Solange Secure Boot Variablen noch gesetzt sind, d.h. der PK ist aktiv, können Änderungen auch mit KeyTool.efi nur mit sog. .auth-Dateien erfolgen (zumindest bei mir war das so). Das sind Dateien, die über eine digitale Signatur verfügen. Da man dafür aber den Private Key von Medion bräuchte (KEK wird vom PK bewacht), kann man das vergessen. Im Allgemeinen klappte bei mir ohnehin nur die Einspielung der Keys mit einer Zertifikatsliste, einer sog .esl-Datei (EFI_SIGNATURE_LIST). Sie führt alle notwendigen Zertifikate in einer Datei. Die .esl ist auch das, was man beim Export der Keys als Backup bekommt, wenn man alles gesammelt exportiert. Die Medion-Programmierung des Bios ließ bei mir keine Einzelbefehle zu. "Addend Key" oder "Add Key" ist wirkungslos und mündete immer in einem Fehler.   Lösung Hier versuche ich euch zu schildern, was ich gemacht habe, weil alle anderen Wege nicht geklappt haben. Alle Tools, Backups etc. vorbereiten. Ins Bios booten und dort unter Security den Seucre Boot Mode auf Custom umstellen, dann ins Key Management gehen und dort die Funktion Default Key Provisioning (?) auf Disabled stellen. Ein paar Zeilen weiter unten muss dann anstelle der Funktion Restore Keys to Factory Settings die Funktion Clear all Keys kommen. Man muss das tun. Nur wenn alle Variablen inkl. PK gelöscht werden, gelangt das System in den sog. Setup-Mode. Warum ist das wichtig? Für die Platzierung von db, dbx und KEK sind dann keine signierten .auth-Dateien mehr nötig, sondern das Bios frisst auch die unsignierten .esl-Dateien. Wenn man den PK stehen lässt, muss man die Root of Trust einhalten und das wird einem nicht ohne Weiteres gelingen, weil man keine private keys der OEM hat. Daher hatte Windows den OEMs die Zertifikate geschickt, um sie zu signieren. Das wurde gesammelt und hätte über Windows Update ausgesteuert werden sollen. Auf GitHub findet man sogar für meinen Medion-PC signierte KEK-Update-Pakete als .auth, aber es ging dennoch nicht. Ich habe dann von unten nach oben angefangen.  Die dbx habe ich 1:1 als .esl wieder eingespielt. Da braucht man nichts modifizieren. Der db-Export als .esl enthielt ja nur die 2011er Zertifikate bzw. bei mir 2 von 3 2023er Zertifikaten, die über Windows Update bereits geschrieben werden konnten. Mir fehlte nur noch das Microsoft UEFI CA 2023. Das habe ich von Microsoft als .crt-Datei heruntergeladen (eigentlich für was anderes vorgesehen). Das Problem nun: Wie füge ich dieses Zertifikat einer EFI_SIGNATURE_LIST hinzu, damit alle Bytes und Header passen? Das konnte ich nur über die Befehle aus WSL umsetzen. Da hat mich Gemini sehr gut durchgeführt. Man nimmt die exportierte .esl und erstellt aus der heruntergeladenen .crt zunächst eine .pem-Datei, damit das Zertifikat sicher umgewandelt wird (direkt ging bei mir nicht und verursachte Import-Fehler im Bios). Danach wurde die .pem in eine .esl umgewandelt. Dabei wird mit dem Befehlssatz cert-to-efi-sig-list unter Verwendung der Microsoft-GUID 77fa9abd-0359-4d32-bd60-28f4e78f784b als Signaturinhaber genutzt. Sodann muss mit einem Befehl die alte .esl und die einzelne .esl fusioniert werden. Das geht aber nur mit den WSL-Befehlen vernünftig. Die dann erhaltene neue .esl kann dann als eine Datei in die db importiert werden. Es geht bei diesem Board immer nur 1 Vorgang über "Replace key/s". Beim KEK war das eigentlich dasselbe. Ich habe den 2023 KEK der .esl des Exports angefügt und alles über WSL unter Verwendung der Microsoft GUID zu einer neuen .esl zusammenführen lassen. Der Knackpunkt ist dann der PK. Solange der nicht sitzt, ist das System im Setup Mode. Sobald ein PK gesetzt wird, ist die Datenbank wieder zu und man kann nicht mehr mit .esl-Importen arbeiten. Der PK wacht sozusagen über alles. Das Problem ist nur, dass KeyTool.efi in meinem Fall auch im Setup Mode keine .esl als PK zuließ, sondern nur eine .auth. Da ich aber von Medion nicht den private key habe, konnte ich pk.esl nicht signieren, um daraus eine .auth zu machen. Man hat nun 2 Möglichkeiten. Man generiert sich mit WSL und openssl-Befehlen ein eigenes Zertifikat und nutzt den Microsoft Standard PK WindowsOEMDevicesPK oder man erstellt sich selbst eine eigene Signatur. Ich habe mich für letzteres entschieden, weil ich nicht weiß, ob im Mainboard dann irgendwo das Medion-PK bei Firmware-Checks erwartet wird. Man generiert sich einen eigenen private key mit RSA-2048-Verschlüsselung und bekommt dazu auch ein öffentliches Zertifikat mit dem public key. Als Inhaber kann man dafür einen beliebigen Namen nehmen, ich habe meinen eigenen Nachnamen genommen. Das wird auch später nicht in der Abfrage der Secure-Boot-Variablen auftauchen. Es geht nur darum, dem Bios zu signalisieren, dieser Medion-PK wurde von einer übergeordneten Stelle signiert und für ok befunden. Nur in dem Fall bin ich nicht Medion, sondern signiere meinen eigenen PK. Das frisst das Bios dann und in dem Moment ist Secure Boot dicht und man kann es wieder aktivieren. Am Ende kann man dann die Checks machen und es sollte alles gesetzt sein.  Ausblick Damit bin ich prinzipiell durch. In der Registry stehen natürlich die ganzen Fehler noch drin und dass der Prozess "in Progress" steht, weil ich alles direkt im UEFI gemacht habe und Windows nichts mitbekommt. Ich belasse es auch erst mal dabei. Ob ich dann ggf. in der Registry die Werte mal lösche und den DWORD-Wert auf 0x4000 setze, damit Windows denkt, es passt alles, werde ich noch entscheiden.   Wichtig ist nun, dass man sich seine ganzen .esl-Listen sowie den selbst generierten Schlüssel für die PK-Signatur gut sichert. Warum? Wenn künftig wieder ein KEK-Update nötig wäre (wenn auch unwahrscheinlich), wird das nicht mehr gehen. Da ich den PK nun mit meinem Key signiert habe, ist die Medion-Signatur wertlos. Ich muss also künftig selbst signieren, um es einzuspielen. db und dbx sollten nicht betroffen sein, da sie über KEK bewacht werden und der ist ja nun gesetzt.   Theoretisch müsste nun im Laufe der Zeit per Windows Update der Bootmanager auch auf 2023 signiert werden. Das dürfte Windows automatisch merken, dass die Zertifikate vorhanden sind. Ab dann können 2011er Bootloader nicht mehr verwendet werden. Also sollte man dann auch seinen bootfähigen Stick etc. aktualisieren oder einen zweiten erstellen. Dann hat man beide Bootloader-Varianten noch drin.   Am Schluss nicht den Fehler von mir machen: Nach alldem hatte ich Secure Boot Violations beim Booten und kam nicht weiter. Das lag aber daran, dass ich den Stick mit KeyTool.efi noch im PC stecken hatte. Da das nicht signiert ist, kommt es zur Secure-Boot-Verletzung. Ich habe mich ewig zu Tode gesucht.   Am Ende hat es alles geklappt und hat mich, wenn auch nebenher, 4 Wochen meiner Lebenszeit gekostet. Aber damit wäre bewiesen, dass es auch Anfänger hinbekommen können und dass es doch einen Weg gibt, die Sicherheit aufrecht zu erhalten.   Grüße, __Seraph_ ... Afficher plus

Hallo zusammen, vielleicht kann mir jemand helfen? Vorweg: Sorry für den langen Text, aber ich habe alles Mögliche probiert. Ich habe seit vier Tagen ein Problem mit meinem Desktop-PC (P5378I), genaue Daten siehe unten. Vielleicht hat jemand dasselbe Problem. Der PC ist nicht mehr der neueste, allerdings erwies er bislang immer treue Dienste und kam mit meinen Anforderungen problemlos klar. Recherchen zeigten, dass das Problem aktuell auch bei vielen anderen Usern auftritt, alle mit denselben Symptomen. Der PC lief bislang ohne Abstürze o. ä.   Spezifikationen Modell Medion Akoya P5378I / C304 DE MSN 10021413 (In den letzten 10 Jahren habe ich aber schon einiges ausgetauscht.) OS Windows 10 Home, 10.0.19045 Bulit 19045 (für ESU registriert) Mainboard H110H4-EM BIOS American Megatrends Inc. 110EMW0X.105, 12.01.2018 CPU Intel i7-6700 (nicht mehr OEM) RAM 32 GB DDR4 2.133 MHz (2x 16 GB Samsung M378A2K43BB1-CPB) (nicht mehr OEM) GPU ASUS Dual AMD Radeon RX6500 XT OC Edition 4GB GDDR6 (nicht mehr OEM) Secure Boot Aktiviert TPM 2.0 Aktiviert   Problem Nachdem ich zunächst keinen Zusammenhang erkannt habe: Der PC startet ganz normal, es lässt sich alles wie gehabt bedienen. Nach ziemlich genau 5 min (Nutzungszeit abhängig, wie schnell gebootet wurde) kommt es zum Freeze. Es gibt keinen Bluescreen oder einen Absturz, das Bild friert einfach ein, der PC reagiert auf nichts mehr. Es hilft nur ein Hard Shutdown. Startet man den PC neu fährt er normal hoch, das Spiel beginnt von vorne.   Im abgesicherten Modus (auch mit Netzwerk) läuft alles normal, es kommt zu keinen Fehlern. Man kann so lange man will arbeiten.   Seit Tagen bin ich an verschiedenen Lösungen dran (siehe unten). Bisher konnte ich im Web User finden, die dasselbe Problem nach einem Windows Update hatten, teils schon im Januar. Ich bin bei mir jedoch verwundert, da das letzte Update zunächst keine Probleme verursachte. Am System selbst wurde nichts geändert, keine neue Software installiert etc. Die bisher einzige Abhilfemaßnahme: Vor Ablauf der 5 min das Internet abstellen, warten und wieder aktivieren. Danach läuft alles wie vorher. Kein Freeze.   Lösungsansätze Folgendes habe ich bislang unternommen. Ich würde behaupten, dass ich technisch nicht ganz blank bin, vieles ist für mich aber zu komplex. Am Anfang hatte ich die neu eingespielten Secure Boot Zertifikate im Verdacht, da es zu einigen TPM-Fehlern kam, aber die gab es auch schon, als das System noch lief. Hardware-Prüfung auf lose Stecker, abgeknickte Kabel etc.: Kein Ergebnis. Sensoren wie CPU-/GPU-Temperatur, Auslastung (CPU, GPU, RAM) beobachtet: Kein Ergebnis, die Betriebszustände waren normal. CMOS-Batterie entfernt, wieder eingesetzt: Kein Ergebnis. Treiber auf Aktualität geprüft, Updates gesucht: Kein Ergebnis. Windows-Update auf neue Updates geprüft: Alles auf Stand. Mithilfe eines Wiederherstellungslaufwerks versucht, Windows zu reparieren: Kein Ergebnis. cmd-Befehl sfc /scannow ausgeführt: Erfolgreiche Reparatur, allerdings keine Auswirkung auf den Fehler. cmd-Befehl chkdsk C: /f ausgeführt und beim nächsten Start laufen lassen: Fehlerhafte Sektoren wurden repariert, allerdings kein Ergebnis auf den Fehler. Selbiges für die anderen Volumes laufen lassen. cmd-Befehl DISM /Online /Cleanup-Image /CheckHealth ausgeführt: Keine Komponentenspeicherbeschädigung. cmd-Befehl DISM /Online /Cleanup-Image /ScanHealth ausgeführt: Keine Komponentenspeicherbeschädigung. Auf DISM /Online /Cleanup-Image /RestoreHealth wurde daher verzichtet. Ich hatte jahrelang die Auslagerungsdatei deaktiviert. Recherchen ergaben, dass das Freezes auslösen kann, also habe ich es für Boot C:\ wieder aktiviert: Kein Ergebnis. Diagnosetool dxdiag laufen lassen: Keine Fehler. Ereignisanzeige Ich habe zudem angefangen, die Ereignisanzeige zu studieren. Direkt zum Zeitpunkt des Freeze kommt es jedoch nie zu Fehlern oder kritischen Ereignissen. Ein solcher Eintrag wird nur kurz danach ausgewiesen, weil man den PC am Power Switch einfach abgeschaltet hat. Ich habe dann begonnen, Fehler, die innerhalb der 5 min auftreten, zu analysieren und im Rahmen meiner Möglichkeiten behoben: ID 46, volmgr: Die Initialisierung des Speicherabbildes ist fehlgeschlagen. \Device\HarddiskVolume5. Es handelte sich um die 836 MB große Wiederherstellungspartition auf Boot C:\. Das habe ich mit o. g. chkdsk behoben. Der Fehler war dann weg. ID 7000, Service Control Manager: Der Dienst "LMS" wurde aufgrund folgenden Fehlers nicht gestartet: Das System kann die angegebene Datei nicht finden. Ich konnte das der Intel Management Engine (ME) zuordnen. Obwohl unter dem Pfad die .exe verfügbar war, ging es nicht. Ich habe daraufhin über die Recovery-Partition von Medion die ME deinstalliert und reinstalliert. Danach habe ich via Gerätemanager die ME wieder auf die aktuellste Version gebracht. Der LMS Dienst funktioniert nun wieder. Bei der ME habe ich dann gleich noch die Schwachstelle Intel-SA-00086 (Sicherheitslücke) gefixed; das ging mir wohl damals unter. Es gab noch diverse Fehler mit dem Google-Updater (ich habe Chrome neu aufgesetzt). ID 27, TPM: Fehler bei der Initialisierung des TPMs (Trusted Platform Module). Das TPM befindet sich möglicherweise im Fehlermodus. ID 7009, Service Control Manager: Das Zeitlimit (45000 ms) wurde beim Verbindungsversuch mit dem Dienst Intel(R) TPM Provisioning Service erreicht. ID 1026, TPM-WMI: Die Trusted Platform Module-Hardware auf diesem PC kann nicht automatisch zur Verwendung bereitgestellt werden. Richten Sie das TPM mithilfe der TPM-Verwaltungskonsole (Start->tpm.msc) interaktiv ein, und verwenden Sie die Aktion zum Vorbereiten des TPMs. Fehler: TPM hat ein unerwartetes Ergebnis zurückgeliefert. Weitere Informationen: 0x0. Ich habe daraufhin den Status des TPM über tpm.msc geprüft. Grundlegend gab es dort keine Fehler. Allerdings gab es dann auch Phasen, wo gemeldet wurde Die Verwaltungskonsole kann nicht geladen werden. Ich habe daher TPM im BIOS einmal deaktiviert und wieder aktiviert. Danach ging das TPM wieder, aber nicht immer. TPM Interessant ist, dass folgender Fehler aktuell nur einsehbar wird, wenn man das Internet getrennt hat (der Fehler war auch schon Tage zuvor in der Anzeige zu sehen, allerdings gab es da keinen Freeze). Ich dachte daher, dass die Generierung dieses Ereignisses den Freeze auslöst: ID 1801, TPM-WMI: Aktualisierte Zertifikate für den sicheren Start sind auf diesem Gerät verfügbar, wurden aber noch nicht auf die Firmware angewendet. Lesen Sie den veröffentlichten Leitfaden, um das Update abzuschließen und den vollständigen Schutz aufrechtzuerhalten. Diese Geräte-Signaturinformationen sind hier enthalten. DeviceAttributes: BaseBoardManufacturer:MEDION;FirmwareManufacturer:American Megatrends Inc.;FirmwareVersion:110EMW0X.105;OEMModelNumber:invalid;OEMModelBaseBoard:H110H4-EM;OEMModelSystemFamily:Desktop;OEMManufacturerName:MEDION;OEMModelSKU:invalid;OSArchitecture:amd64; BucketId: 756a24641c7af894c09924f4e1708b4cbe062d31696da7a94b5e65e8de9855b5 BucketConfidenceLevel: Under Observation - More Data Needed UpdateType: Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=2301018.   Wenn ich abwarte, bis diese Ereignisanzeige auftaucht, kann ich das Internet wieder aktivieren und es gibt keinen Freeze. Ich habe daher noch folgendes untersucht: Soweit mir bekannt, gibt es von Medion für das Mainboard keine aktuelle BIOS-Version, die nützlich wäre. Ich meine, dass man bei 110EMW0X.105 auch nur BIOS-Updates mit 1.x nutzen darf. Alles was es dazu bislang gab, war ohnehin vor jeglichen Zertifikatsupdates. Der PowerShell Befehl (Get-UEFISecureBootCerts db).signature lieferte mir folgende Einträge. CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond,... CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmo... CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US CN=Microsoft Option ROM UEFI CA 2023, O=Microsoft Corporation, C=US Der PowerShell Befehl (Get-UEFISecureBootCerts dbdefault).signature lieferte folgende Einträge: CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond,... CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmo... Der PowerShell Befehl Get-UEFISecureBootCerts -Variable kek | Format-List -Property SignatureSubject lieferte nur einen Eintrag: SignatureSubject : CN=Microsoft Corporation KEK CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US Und hier endet dann auch mein Knowhow. Neue 2023er Zertifikate sind nach meinem Verständnis also in der db (Allowed Signature Database) vorhanden, aber nicht im BIOS (dbdefault) selbst hinterlegt. Das geht nur via OEM-BIOS-Update? Wenn ich diesen Beitrag hier lese, geht das aber dennoch, nur darf man Secure Boot nicht deaktivieren oder im BIOS Keys auf Default/Factory Setting zurücksetzen?   Abschluss Es scheint jedenfalls etwas sein, was mit dem Internet kommuniziert und dann einen Freeze verursacht. C:\Windows\Minidump ist übrigens immer leer, da wurde kein Eintrag erstellt. In der Ereignisanzeige gibt es dann noch diverse Informations-Meldungen, dass Dienst XY erfolgreich geladen und im Filter-Manager registriert wurde. Das waren auch oft eine der letzten Einträge aus der Ereignisanzeige. Allerdings gab es das vor dem Freeze auch schon immer.   Vielleicht hat noch jemand einen Tipp oder dasselbe Problem. Vielen Dank.   Grüße, __Seraph_ ... Afficher plus