About __Seraph_

__Seraph_ · ‎15.05.2026

Nachtrag vom 15.05.2026 Nachdem heute nach dem Mai 2026 Windows-Update eine Secure Boot Violation trotz neuer Zertifikate erschienen ist, habe ich hier beschrieben, was bei mir die Ursache war. Vorweg: Man konnte es in wenigen Minuten fixen (zumindest wenn man den ganzen Aufwand mit dem manuellen Updaten erfolgreich hinter sich gebracht hat). Grüße, __Seraph_

__Seraph_ · ‎15.05.2026

Hallo @kyle_kee_lee_un , vielen Dank für deinen Beitrag. Ja, das ist das typische Fehlerbild, wenn der Task einen Schreibprozess für die NVRAM-Variablen initiiert, das System dann aber nicht mehr reagiert. Secure Boot zu deaktivieren hilft hier dahingehend, dass keinerlei Prüfung der Signaturen beim Booten vorgenommen wird. Ich meine auch, dass der Task dann auch wirkungslos ist, weil das nur bei aktiviertem Secure Boot umgesetzt wird. Wenn du eine "bessere" Zwischenlösung suchst, wäre eben nur das Deaktivieren des in diesem Beitrag genannten Secure-Boot-Update Tasks möglich. Das verhindert, dass die Freeze auslösenden Update-Prozesse überhaupt ausgeführt werden. Da mich das alles nicht zufriedenstellte, habe ich am Ende einen Weg gefunden, wie es zumindest bei mir manuell doch mit dem Update geklappt hat, ohne dass man auf Secure Boot verzichten muss. Das habe ich hier beschrieben. Das ist aber wohl eher etwas für diejenigen, die es maximal ausreizen wollen. Ob es auf jedem System fehlerfrei klappt, kann ich nicht versichern. Am liebsten wäre es denen wohl, wenn man alles auf den Müll schmeißt und sich einen neuen PC kauft. 😑 Grüße, __Seraph_

__Seraph_ · ‎15.05.2026

Hallo zusammen, nachdem ich hier sehr ausführlich beschrieben habe, wie man auch auf älteren Medion-Boards die Secure-Boot-Updates manuell umsetzen kann, wenn die Windows-Bordmittel versagen bzw. zu einem Freeze führen, hatte ich nach dem gestrigen Windows-Update aus Mai 2026 heute einen schönen roten Bildschirm mit einer Secure Boot Violation. Zunächst war ich verwundert, da ich die 2023er Variablen alle mühsam, aber dennoch erfolgreich, manuell einspielen konnte. Also begann die Fehlersuche von Neuem. Die Ursache war jedoch schnell gefunden: Im Bios Secure Boot erst mal deaktiviert, damit der PC überhaupt bootet. Danach mit den üblichen Tools (siehe in meinem oben verlinkten Beitrag) die Secure Boot Variablen ausgelesen. Hier lag dann auch der Fehler: Das Windows-Update, welches diese Woche den mit dem 2023er Zertifikat signierten Bootmanager ausgerollt hat, führte zu einem Reset der Secure Boot Variablen im Bios, es wurden die Default bzw. Factory Values wiederhergestellt. Demnach fehlten also wieder alle 2023er Zertifikate und damit war der neue Bootmanager nicht vertrauenswürdig. Am Ende also das ganze Procedere, wie in meinem Beitrag beschrieben, von vorne: Secure Boot auf Custom setzen und alle Keys löschen > Secure Boot befindet sich im Setup Mode > KeyTool.efi vom Stick booten > selbst erstellte .esl-Listen für KEK, db und dbx einspielen, danach mit dem selbst signierten PK als .auth-Datei wieder alles zumachen > Secure Boot wieder aktivieren. Da man die EFI-Signature-Lists (.esl-Dateien) schon hat, war das diesmal in 2 min erledigt. Der PC bootete dann ohne Probleme mit dem neu signierten Bootmanager. Im Oktober 2026 werde ich mir dann noch die dbx vornehmen, denn ggf. wird durch den selbst signierten PK kein dbx-Update von Microsoft durchlaufen. Das muss man dann ggf. selbst durchführen, wenn man den 2011er Bootmanager in der Sperrliste haben will. Aber bis dahin ist ja noch Zeit. Vielleicht hat jemand dasselbe Thema. Es liegt daran, dass das OEM-Mainboard aus unerfindlichen Gründen einen Factory Reset durchgeführt hat. Grüße, __Seraph_

__Seraph_ · ‎04.05.2026

Hallo @medionRAM66 , ja die liebe Zeit ist oft das Problem... 😑 Ich bin gespannt, ob es bei dir klappt. Mir ist noch was eingefallen, was es vielleicht nicht einfacher machen könnte: Ich weiß nicht genau, was dein Bios-Update alles beinhaltete, ob es wirklich rein nur das Bios betroffen hat oder nicht noch mehr wie Updates an der Intel Management Engine oder Microcode-Updates für die CPU. Je nachdem, was da im Hintergrund alles ausgeführt wurde und an was es am Ende gescheitert ist, könnte auch das eine Ursache sein, warum der PC nicht mehr hochfährt. Hier ist noch die Seite, wo ich den "solderless Fix" für den Programmer gefunden habe: Link Mein gelieferter Programmer sah ein bisschen anders aus, aber ich konnte diese besagte Leiterbahn dennoch gut identifizieren. Offenbar gibt es mittlerweile wohl doch noch mehr Versionen. Man muss wirklich alles abkratzen. Die Verbindung an den gelben Pins mittels Jumper habe ich mit einer normalen Flachsteckhülse verbunden. Die kleinste Größe und ein wenig mit der Zange noch zusammengedrückt und das hat perfekt gepasst. Ist jetzt nicht so ästhetisch wie ein Jumper, aber sowas hatte ich nicht mal eben so auf Vorrat rumliegen. Den Kabelschuh kann man in jedem Baumarkt kaufen. Den muss man nur noch um ca. 90 Grad oben abknicken oder abschneiden, weil man sonst den Adapter für den Kabelclip (mit dem man den Chip im eingelöteten Zustand ausliest) nicht aufgesetzt bekommt. Bezüglich der Treiber: Ich hatte das Treiberpaket genommen, was beim NeoProgrammer V2.2.0.10 in der .zip dabei war. Man kann auch manuell auf die Suche gehen, jedoch gibt es einen parallelen und einen seriellen Treiber. Ich habe daher das aus dem NeoProgrammer-Ordner genommen, weil das funktioniert hat. Falls die Verbindung mit dem Chip nicht zustande kommt: Ich dachte am Anfang, der Programmer taugt nix. Es sieht zwar meist so aus, als wäre die Klemme richtig drauf, aber es muss wirklich 100%ig exakt ausgerichtet sein. 1 mm daneben ist schon nix mehr. Das ist eine ziemliche Fummelei. Aber im Programm selbst (zumindest bei NeoProgrammer) kommt unten immer ein Fehler, wenn man auf "Detect" klickt. Falls wirklich gar nichts mehr hilft: Hast du schon mal geschaut, ob es auf den einschlägigen Websites ein gebrauchtes Mainboard gibt oder vielleicht eins mit einem Defekt, wo aber der Bios-Chip noch funktioniert hat? Wenn man das für schmales Geld bekommt, könntest du entweder das ganze Board tauschen (und den Weg über Windows > "Ich habe meine Hardware geändert" versuchen) oder dann zumindest von diesem Chip einen Full Dump ziehen. Man sollte hier aber auf die Versionen bzw. Revisionen achten. Ich hatte damals für 20 € ein Mainboard als Ersatz gekauft (bisher glücklicherweise nicht gebraucht, außer mir eben auch davon einen Full Dump gezogen). Grüße, __Seraph_

__Seraph_ · ‎01.05.2026

Hallo @PatrickBerlin und @kek-win10Update, ich hatte bei meinem Medion-PC auch das Problem, dass ich kein vollständiges Update der Secure-Boot-Zertifikate durchführen konnte. Bei mir war es aber das Problem, dass mein Medion-Bios die vom Microsoft Update vorgesehenen Befehle für die Aktualisierung des KEK nicht verarbeiten konnte, was immer zu einem Freeze des PC geführt hat. Wenn der Updateprozess dann einmal unterbrochen wurde, wird er nicht mehr automatisch fortgeführt. Das Problem haben viele User, auch anderer Hersteller. Wenn es kein Bios-Update vom Hersteller gibt, hat man erst einmal Pech. Da mein PC aus 2016 ist, wird es da von Medion auch nichts mehr geben und der Weg über Windows Update klappte auch nicht. Ich habe darüber nur 2 Zertifikate installiert bekommen und der Rest hat gefehlt. Da eure Geräte noch nicht so alt sind, sollte es eigentlich herstellerseitige Lösungen geben. Das mit den Secure Boot Zertifikaten läuft wohl aber alles nicht so wie geplant, im Internet liest man oft von Problemen und das bei vielen Herstellern. Die Thematik mit älteren PKs halte ich für weniger relevant. Bei meinem alten Medion hat der PK eine Gültigkeit bis 2032. Soweit ich verstanden habe, wäre der Plan gewesen, dass der Hersteller den KEK mit seinem PK signiert und an Microsoft sendet. Microsoft sammelt diese signierten KEKs entsprechend und verteilt diese über Windows Update zum Aktualisieren. Theoretisch würde das auch funktionieren, aber nur, wenn das Mainboard auch mitspielt und die Befehlskette nicht unterbricht. Ich konnte bei mir nur zwei Einträge aus der sog. db-Datenbank (Windows UEFI CA 2023, Microsoft Option ROM UEFI CA 2023) und eine neue Version der dbx-Datenbank über Windows Update automatisch aktualisieren. Das Microsoft UEFI CA 2023 sowie das Microsoft Corporation KEK 2K CA 2023 ließen sich nicht installieren. Am Ende musste ich als Laie tief ins System eingreifen, was mich sehr viel Zeit gekostet hat und man sollte sich gut vorbereiten. Ich habe meine Vorgehensweise hier dokumentiert. Kurzfassung: Ich musste das Mainboard bei Secure Boot in den sog. Setup-Mode versetzen, also alle Variablen löschen. Danach ist das System offen und ich habe direkt im UEFI die db, dbx, KEK und PK manuell installiert. Das ging aber nur mithilfe von KI und Linux-Befehlen, weil man sich neue EFI-Signature-Lists bauen muss. Am Ende hat man dann die Problematik, dass man keinen vom Hersteller signierten PK mehr hat, also musste ich meinen PK mit einem eigenen Schlüssel selbst signieren. Damit hätte man dann auch das Problem von ablaufenden PKs theoretisch gelöst. Das ist aber alles entsprechend aufwändig und gar nicht so einfach. Ich habe es als Nicht-Experte zwar hinbekommen, habe aber ewig gebraucht. Das Risiko muss jeder selbst abwägen. Da es bei mir nur an einer Blockade des Bios gescheitert ist: Habt ihr ggf. versucht, die Updates manuell anzustoßen? Hier und hier wird das bspw. von Microsoft für IT-verwaltete Umgebungen beschrieben. Andere Anleitungen dazu gibt es massenweise im Internet. Man muss dazu in der Registry Variablen setzen und den Task "Secure Boot Update" ausführen. Der schreibt dann die Variablen. Ich habe das erst letzte Woche bei einem Dell Notebook durchgeführt und dort ging es problemlos. Nach 5 min war alles aktualisiert. Ich habe nur nicht die Variante mit dem Setzen des Wertes 0x5944 verwendet. Wenn ich das richtig verstanden habe, würde man damit auch gleich den Bootmanager auf das neue 2023 Zertifikat ändern. Da man damit auch alle bootfähigen Sticks und Wiederherstellungsmedien neu machen müsste, habe ich das ich bei mir noch nicht gemacht, weil ich nicht weiß, was noch kommt. Da warte ich mal noch ab. Ich habe nur die Zertifikate aktualisiert, d.h. meine Hard- und Software ist nun grundsätzlich für alles Neue bereit. Bei den PowerShell Checks sollte man nach meiner Erfahrung übrigens immer aufpassen, was man abfragt. Wenn man konkrete Zertifikate mittels "match" abfragt, prüft PowerShell auch nur nach diesem Zertifikat. Für eine vollumfängliche Aktualisierung müssen folgende Zertifikate vorhanden sein: Microsoft Corporation KEK 2K CA 2023 Windows UEFI CA 2023 Microsoft UEFI CA 2023 Microsoft Option ROM UEFI CA 2023 Zudem muss man immer prüfen, welche Datenbank man abfragt. Es gibt eine "current" Datenbank und eine "default" Datenbank. Default ist das, was im Bios selbst gespeichert ist und auch bei einem Reset wiederhergestellt wird. Da das fix auf dem Bios-Chip ist, kann man das nur mit einem Bios-Update aktualisieren. Die Current-Datenbanken können, wenn die Komponenten mitmachen, auch durch Windows-Update geändert werden. Das sind die aktuell verwendeten Zertifikate. Sie sind auch in den NVRAM-Variablen des Bios-Chips gespeichert, aber in einem anderen Bereich. Relevant ist also primär der "current" Bereich. Default-Datenbanken werden nur bei einem Reset oder der Werkseinstellung herangezogen. Eine andere Alternative ist natürlich, Secure Boot im Bios zu deaktivieren. Unter Windows 10 geht das noch, weil es da nicht verpflichtend ist, bei Windows 11 wird es standardmäßig vorausgesetzt. Es gibt aber auch Möglichkeiten, das zu umgehen. Je nach Bios gibt es teilweise sogar die Einstellung, dass man Secure Boot zwar aktiviert hat, bei einer Violation aber nur eine Fehlermeldung bestätigen muss und der PC fährt dann trotzdem hoch. Dann denkt Windows 11 zwar, Secure Boot ist an, aber es ist de facto wirkungslos. Das ist aber nur ein Workaround und bietet nicht den vollen Schutz. Am Ende gilt jedoch: Jeder muss sich selbst ein Bild darüber machen, ob das infrage kommt. Nur weil es bei mir geklappt hat, gibt es keine Garantie dafür, dass es woanders auch problemlos klappt. Alles läuft auf eigene Gefahr und man sollte immer die nötigen Backups usw. haben. In jedem Falle auch ein Full Dump des Bios-Chips, falls etwas schief läuft. Sonst fährt der PC gar nicht mehr hoch. Je nachdem, wann das Notebook 2024 gekauft wurde, wäre ja sogar noch Gewährleistung vorhanden, dann müsste sich Medion damit befassen, wenn es nicht klappt. Grüße, __Seraph_

__Seraph_ · ‎01.05.2026

Hallo @medionRAM66, vielen Dank für die bislang ausführlichen Beschreibungen. Das ist sehr ärgerlich. Ich kann leider nicht mit einem Dump o.ä. weiterhelfen, da ich keinen passenden PC habe. Ich habe aber erst kürzlich Erfahrungen mit einem SPI-Programmer und Bios-Updates gesammelt, als ich meine Secure Boot Zertifikate manuell updaten musste, da weder ein Bios-Update existiert noch das Windows Update funktioniert. Ob dein Weg über AFUWIN wirklich fehlgeschlagen war, lässt sich vielleicht so gar nicht sagen, außer ich habe einen Denkfehler. Mit AFUWIN kann man meines Wissens nur die Bios-Region selbst dumpen. Ich kenne jetzt deine genaue Mainboard-Architektur nicht, aber da du etwas von 8 MB geschrieben hast, gehe ich davon aus, dass du ein File in der Größe von 8.192 KB erwartet hast, was einem Full-Dump (also des kompletten SPI-Chips) entsprochen hätte. Bei mir ist bspw. der reine Bios-Dump nur 6.148 KB groß gewesen. Der Rest sind dann noch Descriptor, Intel ME Region, GbE Region etc. Die Nutzung von Intel FPT ist tatsächlich sehr komfortabel. Man findet das bspw. auf GitHub zum Downloaden. Man muss nur schauen, welche Version man braucht, meist für jede Intel-CPU-Generation eine andere. Das kann man aber gut mit KI lösen, ich kam damit gut durch. Aktuell nutzt es dir nichts, weil dein PC gar nicht mehr hochfährt, aber sobald du alles wieder in Gang gebracht hast, würde ich mir damit auf jeden Fall eine Sicherung erstellen. Allerdings geht das nur, wenn das Mainboard keinen Block drin hat. Sonst kannst du auch damit oft nur einen reinen Bios-Dump erstellen. Bei meinem Medion-Desktop-PC war das glücklicherweise nicht der Fall. Mit Intel FPT konnte man den gesamten Chip dumpen. Zuvor kann man sich auch noch den Chip-Typ sowie die Größe ausgeben lassen. Falls mehrere Chips verbaut sein sollten, würde man auch das sehen. Ich kenne dein Mainboard nicht, aber falls es 2 Chips geben sollte, wäre sogar die Chance groß, dass auf einem ausschließlich das Bios enthalten ist und auf dem anderen der Rest. Dann könnte man mit einem SPI-Programmer vielleicht sogar nur diesen einen Bios-Chip flashen. Ich tippe aber, dass Medion hier nur einen Chip verbaut hat. Das würdest du beim Zerlegen gleich sehen. Man muss nur aufpassen, dass man auch den richtigen Chip findet. Manchmal sind mehrere 8-Pin-Chips auf Mainboards verbaut. Die sehen dann zwar gleich aus, beinhalten aber was anderes. Oft sind es Chips mit dem Aufdruck "Winbond" (= Hersteller). Ist aber kein Muss. Für die Nutzung des Programmers. Falls du so einen CH341A-Programmer aus dem Internet bestellt hast: Die gibt es ja wie Sand am Meer und entweder in blau oder schwarz. Nachdem du auf dem Mainboard den Chip gefunden hast, würde ich nachsehen, mit wie viel Volt er betrieben wird. Meist 3,3 V oder 1,8 V. Falls du einen 1,8 V Chip haben solltest, brauchst du ohnehin erst einmal einen Adapter für den Programmer. Falls du 3,3 V brauchst, verspricht der Programmer zwar, dass er das kann, aber es gibt im Netz etliche Berichte darüber, dass nicht alle Leitungen auf dem Programmer mit 3,3 V laufen, sondern einige mit 5 V Ausgangsspannung aus deinem USB-Port. Insbesondere wenn du dann am Chip im eingelöteten Zustand arbeitest (wovon ich ausgehe), können Beschädigungen auftreten, weil der Chip nicht für 5 V ausgelegt ist. Falls der Chip Schaden nimmt, ist erst mal komplett vorbei. Du müsstest dann einen neuen Chip kaufen und diesen erst mal auf dem Mainboard einlöten. Im Netz gibt es verschiedene Anleitungen für das Fixen. Viele User schreiben, dass sie das nicht gemacht haben und es auch ging, aber das Risiko muss dann jeder selbst abwägen. Als Fix muss man 2 Kabel selbst anlöten (Anleitungen gibt es viele). Ich habe eine Alternative ohne Löten gefunden: Auf der Rückseite ist eine Leiterbahn zu durchtrennen und es müssen 2 Pins auf der Oberseite des Programmers miteinander verbunden werden. Normalerweise mit einem Jumper. Ich hatte keinen und habe einen Kabelschuh genommen, das geht auch. Ich habe dann alle relevanten Pins durchgemessen und hatte entsprechend 3,3 V anliegen. Ich bin gespannt, ob du weiterkommst. Je nachdem, was genau passiert ist, wirst du ggf. einen aktualisierten Teil und einen alten Teil in der Bios-Region finden. Ob das dann ohne Weiteres manuell mit einem Hex-Editor behebbar ist, wird spannend. Es muss ja alles blockgenau dort platziert werden, wo es vorgesehen ist, sonst klappt das nicht. Falls dein Chip 8 MB fasst, muss das fertige File 8.192 KB haben. Ich bin kein Experte, daher gerne korrigieren 😉, aber soweit ich weiß: Wenn man mit einem Programmer arbeitet, muss in jedem Falle der Full Dump geflasht werden. Nur die Bios-Region lässt sich mit den üblichen Tools wie NeoProgrammer nicht flashen, da der Programmer den Chip am ersten Speicherblock beschreibt und nicht weiß, wo die Bios-Region beginnt. Daher muss sichergestellt sein, dass dein erstellter Full Dump in allen anderen Regionen schadfrei geblieben ist. Am einfachsten wäre es wohl tatsächlich, wenn jemand einen Full-Dump bereitstellen könnte. Aber leider hat sich bislang hierzu noch keiner gemeldet. Ein Thema dabei wird aber ggf. folgendes sein: Soweit ich weiß, sind bei OEM-PCs, wie auch bei Medion, die Windows Lizenzschlüssel im Mainboard verankert. Daher muss man bei einem OS-Reinstall auch nie einen Key eingeben und findet auch oft auf den PCs keinen Key-Aufkleber. Wenn man nun einen Full Dump eines Spenders erhält, hat man bei einem Flash auf den eigenen PC erst mal dieses Abbild und damit auch den Key vom Spender. Soweit ich weiß, ist das erst mal nicht dramatisch (da darf man mich aber gerne korrigieren), weil OEMs dafür meist sog. DM-Lizenzen nutzen, die für ganze Serien oder Chargen immer dieselben sind. Das bedeutet, dass Windows erst mal nicht meckern wird, dass es derselbe Key ist. Relevant ist aber, dass hier mit einer sog. Hardware-ID gearbeitet wird, die sich aus Faktoren wie CPU, Seriennummern, TPM usw. ergibt. Das wird nach meiner Info mit den Daten aus der sog. MSDM-Tabelle im Bios-Chip und dem Microsoft-Server abgeglichen. Bei einem Spender-Dump übernimmst du damit dessen MSDM-Tabelle mit dessen Werten. Beim Hochfahren wird Windows dann ggf. merken, dass deine Hardware-ID eine andere ist und vermutlich eine Aktivierung verlangen. Selbst wenn du zuvor dienen Key mit PowerShell ausgelesen hast, kann es sein, dass das nicht klappt, weil DM-Keys nicht für eine manuelle Eingabe vorgesehen sind. Damit alles funktioniert, könnte es sein, dass du die MSDM-Tabelle aus deinem aktuellen Bios brauchst. Das könntest du dann in den Spender-Dump einbauen, damit dein PC korrekt erkannt wird. Eine Alternative wäre natürlich, dass du vom OEM einen Dump mit korrekter MSDM-Tabelle erhältst, aber wie ich das hier aus dem Chat lese, ist das wohl ausgeschlossen. Falls du eine Verknüpfung mit deinem Microsoft Account hattest und eine digitale Lizenz verknüpft hast, könnte das dann auch deine Rettung sein, indem du online die Funktion auswählst, dass du kürzlich deine Hardware geändert hast. Dann kann es sein, dass die Aktivierung ungeachtet dessen klappt, was im Bios geflasht wurde. Microsoft speichert das dann bei sich serverseitig neu ab. Aber das ist auch nur das, was ich mir im Zuge meiner Probleme damals alles durch Lesen angeeignet habe, 100%ig wissen tue ich es nicht. Daher bin ich auch gerne für Klarstellungen dankbar. 😎 Grüße __Seraph_

__Seraph_ · ‎27.04.2026

Hallo @Riza ja, die Ursachenforschung dauerte bei mir auch ewig. Als das erstmalig kam, gab es auch noch nicht so viele Treffer im Netz. Am meisten konnte ich über reddit auf Englisch finden und es wurde von Tag zu Tag mehr. Irgendwann war es dann mal in diversen Foren angekommen. Solange man an der Aufgabe selbst nichts geändert hat, dürfte da eigentlich nichts passiert sein. Bis auf das Deaktivieren, um den Freeze zu vermeiden, würde ich da aber auch nichts tun. Ich meine, dass man das nicht ohne Weiteres wiederherstellen kann, wenn man da aus Versehen die Aufgabe löscht. Das wird dann eine aufwändigere Prozedur. Ich habe mittlerweile für mich eine Lösung gefunden, wie ich doch updaten konnte (ist aber eine sehr aufwändige Lösung gewesen, da das Medion-Mainboard wohl nicht wollte, dass ich da so viel ändere). Bei anderen Herstellern kann das alles recht unkompliziert sein. Habe heute einen Dell 5590 alltagsfähig gemacht und dort musste ich die Secure Boot Zertifikate manuell anstoßen. Ich musste nur die Registry-Values gemäß Microsoft-Anleitung setzen und in 5 min war ich fertig, kein Freeze und nix. So einfach kann das sein. 😀 Bei meinem Medion ist der Task dennoch deaktiviert, da er wohl nach jedem Systemstart irgendwas checken würde. Da ich dort nun auf Stand bin, brauche ich den Task erst mal nicht mehr. Bei dem Dell-Notebook kann ich ihn an lassen, denn er führt zu keinem Freeze. Zu deinem 5-min-Thema. Hast du in der sog. Aufgabenplanung unter dem Pfad Aufgabenplanungsbibliothek > Microsoft > Windows > PI den Task schon einmal geöffnet und mit Rechtsklick die Eigenschaften geöffnet? Dort steht unter Trigger: "Beim Systemstart - Nach Auslösung alle 12:00:00 unbegrenzt wiederholen." Klickt man diesen Eintrag an und wählt unten Bearbeiten... öffnet sich ein weiteres Menü Trigger bearbeiten und da steht dann eine Verzögerung für 5 min. Bleiben wir gespannt, was MS noch bringt. Es ist ja (noch) bis Juni 2026 Zeit... Grüße __Seraph_

__Seraph_ · ‎21.04.2026

Hallo @Andi. Vielen Dank. 😎 Vielleicht hilft es ja jemandem. Und in dem Zuge kann ich gleich noch einen kleinen Fehler eingangs korrigieren: Die verbaute CPU ist ein i7-6700. Grüße, __Seraph_

__Seraph_ · ‎18.04.2026

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_

__Seraph_ · ‎09.04.2026

Hallo, genau so ist es. Im abgesicherten Modus läuft alles ohne Probleme (auch im abgesicherten Modus mit Netzwerkverbindung). Da wird der Task nicht ausgeführt. Ich habe zwischenzeitlich nochmals versucht, die Update-Kette manuell anzustoßen und die Aufgabe Secure-Boot-Update ausgeführt, aber der Freeze kommt immer noch. Ich weiß nicht, ob es dafür am Ende eine Lösung geben wird. Ich hatte auch schon vor, den Medion-Support bzgl. eines BIOS-Updates zu fragen, da doch einige ältere Geräte betroffen sind, aber ich kann das Kontaktformular nicht nutzen. Ich habe es mehrmals versucht, die Nachrichten lassen sich nicht senden. Das Formular scrollt immer wieder nach oben und die Eingabe lässt sich nicht abschließen. Eine E-Mail-Adresse gibt es auch nicht. Das Formular-Problem wurde hier in der Community schon mehrfach diskutiert, bei manchen geht es, bei manchen nicht. Wenn meine bisherigen Recherchen keine Falschinfo sind (ich kenne mich da technisch nicht so aus), dann hängt der Update-Vorgang aktuell an der Aktualisierung des KEK (Key Exchange Key). Er ist nach meiner Info ein Schlüssel zum Signieren von Updates für die Datenbanken db ("Whitelist" für vertrauenswürdige Zertifikate) und dbx ("Blacklist" für widerrufene Keys). Der KEK wird wiederum vom PK (Platform Key) beeinflusst, welcher Änderungen am KEK autorisiert. Der PK ist der oberste Plattformschlüssel und wird vom Hersteller ausgestellt, also geht das nur von Medion selbst. Die Kette wäre also PK → KEK → db + dbx. Wenn meine Websuche korrekt ist, dann passiert bei dem Freeze folgendes: Der Task Secure-Boot-Update versucht, UEFI-Daten zu schreiben, um den KEK 2023 zu speichern. Der von Windows ausgegebene Befehl wird vom Mainboard bzw. dem UEFI nicht korrekt verarbeitet. Der Kernel wartet sozusagen, das UEFI antwortet nicht und das System hängt sich auf. Es könnte also sein, dass das Mainboard schlichtweg moderne NVRAM-Routinen nicht unterstützt bzw. keine Unterstützung für db-/KEK-Updates zulässt. Es gibt zwar die PowerShell Befehle Get-SecureBootUEFI -Name PK | Format-List sowie Get-SecureBootUEFI -Name KEK | Format-List, bei denen unter Attributes zwar ACCESS für diverse Aktionen ausgegeben wird, aber das scheint nicht zu funktionieren. Daher würde nur ein "richtiges" BIOS-Update helfen, um die neuen Zertifikate by default zu speichern. Als letzter Ausweg wird teils noch genannt, im BIOS unter dem Secure-Boot-Menü in den Custom-Modus zu wechseln und die Keys auf Factory-Settings zurückzusetzen, um etwaige Fehler zu beheben. Das habe ich bislang tatsächlich noch nicht versucht, weil ich nicht weiß, ob das eine gute Idee ist oder mit Risiken verbunden ist. Solange man bei Windows 10 bleibt, ist Secure Boot ja nicht verpflichtend nötig, bei einem Upgrade auf Windows 11 ginge das aktuell nur auf Umwegen, bspw. mit einem über Rufus erstellten USB-Stick. Allerdings gibt es auch auch Programme, die Secure Boot voraussetzen, um überhaupt zu starten. Das Deaktivieren von Secure Boot ist daher also unter Windows 10 sowie 11, je nach genutzten Programmen eine unpassende Lösung. Grüße, __Seraph_

__Seraph_ · ‎03.04.2026

Hallo @daddle , kann ich gerne noch nachholen. 😀 Da ist mir @Fishtown schon zuvorgekommen. Zur Vervollständigung, falls es jemand braucht, noch Screenshots dazu: Unter diesem Pfad dann den Ordner PI suchen. Danach sollte die Aufgabe Secure-Boot-Update erscheinen. In den Eigenschaften findet man entsprechend die Ursachen für den Freeze. Trigger ist eben 5 min nach Systemstart, deswegen passiert das auch mehr oder weniger immer zur selben Zeit: Mit Rechtsklick kann man dann die Aufgabe deaktivieren (in meinem Screenshot unten ist das bereits erledigt). Auf dem Wege könnte man das Ganze auch wieder aktivieren, falls der Update-Prozess irgendwann funktioniert. Ich habe auch schon versucht, über diesen Task herauszufinden, was da im Hintergrund genau passieren soll, um den Freeze zu erklären, allerdings ist in der Aufgabe als Aktion nur "Benutzerdefinierter Handler" hinterlegt. Wenn man das bearbeiten möchte kommt eine Meldung "Dieser Aktionstyp kann in diesem Tool nicht bearbeitet werden." Insofern kommt man da als "Normaluser" nicht weiter. Auch das Deaktivieren von Firewall und Anti-Virus-Programm bei Ausführung des Tasks bringt nichts. Der Task an sich ist jedenfalls nicht das Problem. Wenn man sich von Microsoft die Anleitungen für manuelle Update-Prozesse (bspw. für IT-verwaltete Geräte oder Server) durchliest, dann findet man Registry-Values, mit denen man den gesamten Update-Prozess anstoßen oder nur einzelne Teile davon ausführen kann. Im Rahmen der Fehlersuche hatte ich das auch mal versucht, für manche Teil-Tasks läuft die Aufgabe Secure-Boot-Update problemlos durch und es passiert nichts und bei anderen DWORD-Values in der Registry kommt es dann zum Freeze. Da man bei der manuellen Ausführung jedoch eine Reihenfolge einhalten soll, sollte man es nicht einfach wahllos durcheinander anwenden. Insofern weiß ich nicht genau, welcher Teil-Task genau verantwortlich ist. Ich könnte mir daher vorstellen, dass auch bei einer Neuinstallation der Fehler wieder auftreten wird (außer man hat Secure Boot deaktiviert oder man nimmt nicht an dem ESU-Programm teil. Nach einer Neuinstallation müsste man sich meiner Ansicht nach dafür erst wieder neu registrieren und solange das nicht passiert, kommt auch kein Windows-Update). Interessant wäre nun natürlich, ob @Bangalter0815 einen Check nach der Neuinstallation durchgeführt hat, ob die Secure-Boot-Zertifikate aktualisiert wurden. Dazu gibt es im Netz Anleitungen für PowerShell-Befehle oder cmd-Dateien wie bspw. auf GitHub beschrieben. Bei mir sieht das aktuell noch so aus. Wenn ich es korrekt verstehe, müsste es jeweils in der Current-DB auftauchen (Default-DB ließe sich nur über ein BIOS-Update aktualisieren). Es fehlen noch das Microsoft UEFI CA 2023 und Microsoft Corporation KEK 2K CA 2023. Grüße, __Seraph_

__Seraph_ · ‎02.04.2026

Hallo @Bangalter0815, auch wenn Dein Fall schon auf "gelöst" steht, könnte es dasselbe Problem sein wie bei mir. Das Ganze ist hier ausführlich beschrieben: Windows 10 friert nach Update im März 2026 nach 5 min ein. Eine finale Lösung, die dann auch das eigentliche Problem behebt, habe ich aktuell aber noch nicht gefunden. Das Problem haben jedenfalls einige. An was es auch bei dir liegen könnte: Windows hat seit einiger Zeit damit begonnen, per Windows Update die 2026 auslaufenden Secure-Boot-Zertifikate auszurollen. Damit soll Secure Boot auf älteren Geräten auch weiterhin nutzbar sein (auch wenn es bei Windows 10 keine "Verpflichtung" für Secure Boot gibt). Ich bin kein Experte für das alles, aber wenn ich es korrekt verstehe, gibt es grundlegend verschiedene Arten, das auszusteuern: Die Bilderbuchlösung wäre wohl, dass der Hersteller ein BIOS-Update liefert und Windows den Rest und dann ist alles gut. Bei unseren älteren PCs ist das aber Wunschdenken. Inwiefern Microsoft auch für Systeme ohne Hersteller-Updates eine funktionierende Lösung anbieten wird, kann ich nicht sagen. Nachdem ich fast wahnsinnig geworden bin, weil ich nach ziemlich genau 5 min keinen bedienbaren PC mehr hatte und jegliche Fehlersuche ins Leere führte, konnte ich den Übeltäter ausfindig machen: Für diese Secure-Boot-Updates gibt es in der Aufgabenplanung einen Task, der die Aktualisierung durchführen soll. Offenbar funktioniert das aber nicht auf jedem System. Sobald diese Aufgabe startet, friert das System ein, es gibt keinen Fehler o.ä. Was genau passiert, weiß ich nicht. Die Aufgabe wird mit 5 min Verzögerung nach dem Systemstart ausgeführt und nach 12 Std. wiederholt. Daher könnte das auch Deinen Freeze nach immer ziemlich genau 5 min erklären. Lösungen, die ich aktuell habe und funktionieren: Internet vor Ablauf der 5 min trennen, danach wieder aktivieren. Ist aufwändig und man muss immer die Zeit im Blick haben. Falls man den PC dann länger an hat, wiederholt sich der Task nach 12 Std. automatisch und es kommt wieder zum Freeze. Effektiver ist den Task komplett zu deaktivieren. In der Aufgabenplanung in der sog. Aufgabenplanungsbibliothek den Pfad Microsoft > Windows > PI aufrufen und die Aufgabe Secure-Boot-Update über Rechtsklick deaktivieren. Das ist dauerhaft und man kann dann beim Neustart das Internet aktiviert lassen. Mittelfristig wird das wohl keine sinnvolle Lösung sein, da man damit wohl auch den finalen Updateprozess für die Secure-Boot-Zertifikate unterbindet. Da es seitens Microsoft aber aktuell keine mir bekannte Lösung gibt, ist das das Einzige, was ich nutzen kann, damit der PC noch funktionsfähig bleibt. Man wird wohl abwarten müssen, was passiert. Dass die Neuinstallation auch eine Abhilfemaßnahme ist, habe ich bislang nicht verfolgt, da ich nicht alle Programme usw. neu einrichten wollte. Über die Jahre sammelt sich da doch einiges an. Zudem weiß ich auch nicht, ob der Fehler dann durch ein neues Windows Update wieder eingeschleust wird. Grüße, __Seraph_

__Seraph_ · ‎02.04.2026

(Zwischen-)Lösung Nachdem es seitens Microsoft bislang noch keine offizielle Abhilfe für das Problem gibt, wollte ich die aktuellen Lösungen zusammenfassen, um den Fall zu schließen: Man kann innerhalb der ersten 5 min das Internet trennen, danach wieder aktivieren. Dieser Workaround ist sehr umständlich, da man entweder genau auf die Uhr achten muss oder man bei standardmäßig deaktiviertem LAN/WLAN die ersten Minuten nach dem Start nicht viel machen kann. Zudem führt das, je nach installierten Programmen, auch zu Problemen, wenn automatische Updates etc. behindert werden. Das muss man dann oft alles händisch nachholen. Zudem kommt dazu, dass der PC nach 12 Std. Betrieb wieder einfriert, da sich die Aufgabe Secure-Boot-Update alle 12 Std. automatisch wiederholt. Weitaus sinnvoller scheint es, den Task Secure-Boot-Update in der Aufgabenplanung zu deaktivieren. Damit wird die Freeze verursachende Aufgabe gar nicht erst ausgelöst. Welche konkreten Auswirkungen dies mittelfristig haben wird, wird sich zeigen. Der PC funktioniert immerhin. Ob letztlich nur durch Windows Update alle notwendigen 2023er Zertifikate installiert werden können, wird sich dann wohl erst noch zeigen. Aktuell scheint es jedenfalls nicht zu klappen. Gerade beim KEK-Zertifikat wird der Fehlerwert Firmware_Unknown ausgegeben. Offenbar liegen Microsoft auch nicht genug Daten zu PCs mit dieser oder ähnlicher Konfiguration vor, da die Secure-Boot-Update-Values in der Registry Under Observation - More Data Needed anzeigen. Secure Boot im BIOS abstellen. Damit erübrigt sich dann auch das Secure-Boot-Update. Diese Lösung funktioniert zwar, allerdings kann ich mich aktuell dafür nicht begeistern. Wie von @Fishtown beschrieben (habe ich aber (noch) nicht getestet): Ein Upgrade des Boards auf v2.x und damit auch auf Kaby Lake CPU.

__Seraph_ · ‎23.03.2026

Hallo @Fishtown . Vielen Dank für deine Unterstützung. 👍 Den Switch auf die 7. Generation hatte ich tatsächlich schon länger im Hinterkopf, einmal ungeachtet von der aktuellen Problematik. Allerdings bin ich bislang immer davor zurückgeschreckt. Wenn ich den Antworten in der verlinkten Diskussion folge, bin ich etwas verwirrt, ob es nun klappt oder nicht. Wenn ich dort Antwort 20 von 24 lese, kann auf einem H110H4-EM Board der Revision 1.xx grundlegend erst mal nur ein Bios mit der Version 1.0x installiert werden. Da ich bereits 110EMW0X.105 habe, gehe ich mal davon aus, dass das für die 1er Revision die neueste Version ist. Die von Computer Bild beschriebene Update-Möglichkeit ist nicht mehr auf deren Website verfügbar. Wenn ich Antwort 11 von 24 lese, braucht man diese H110H4-EM BIOS 1.xx to 2.xx.exe und muss auch einen Jumper auf dem Mainboard umstecken. Der Upgrade-Patch stammt jedoch von Computer-Bild selbst und ist nicht Medion-seitig bereitgestellt? Wenn man das alles durchgeführt hat, läuft das Bios mit der Version 110EMW0X.207. Die in deiner Nachricht 17 von 24 aufgeführte Verlinkung führt zu einem Bios der Version 2.08 (also vermutlich 110EMW0X.208), wobei es hier eine Unsicherheit gibt, da es in der slowenischen Support-Doku um das Board H110H4-CM2 geht und wenn man die Datei entpackt, kommt ein Bios der Version 110EMW0X.204 zum Vorschein. Vollständig verwirrt mich dann die letzte Nachricht in der Diskussion, dass am Ende ggf. die Wiederherstellung von DMI-Informationen notwendig werden kann. Ich habe mal in die dort verlinkten Seiten reingeschaut, bin da dann aber raus. Ich habe irgendwo noch ein neues H110H4-EM Mainboard liegen. Wenn Windows selbst bis zum Ende der Zertifikatsgültigkeit keine Lösung anbietet, wäre es ggf. einen Versuch wert, das Bios auf eine v2.0x zu updaten. Wenn es nicht funktioniert oder der PC nicht mehr bootet, hätte ich immerhin noch ein "neues altes" Board mit v1.05 (oder vermutlich v1.03 wenn es noch OEM ist). Grüße. 😀

__Seraph_ · ‎21.03.2026

Nachtrag Heute bin ich wohl durch Zufall auf die Ursache gestoßen, eine Lösung habe ich dennoch keine. Durch diverse Anleitungen für IT-verwaltete Systeme und Server ist mir immer wieder der Befehl Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" aufgefallen. Ich habe mir Secure-Boot-Update in der Aufgabeplanung angesehen. Folgendes steckt dahinter: Mit dieser Aufgabe werden die Variablen für einen sicheren Start aktualisiert. Der Freeze erklärt sich aus der Konfiguration der Aufgabe: Als Trigger ist der Systemstart gesetzt. Es wird eine Verzögerung von 5 min und eine Wiederholung nach 12 Std. angegeben. Das erklärt dann den Freeze nach immer 5 min Betriebszeit. Einige User berichten von erneuten Abstürzen nach 12 Std., das ist dann der Wiederholungszeitpunkt. Ich habe mehrfach versucht, diese Aufgabe gemäß diverser Anleitungen anzuwenden, neu zu starten, auszuführen usw. Ergebnis: Fast immer führt das Starten der Aufgabe zum Freeze. Was genau im System passiert, kann ich jedoch nicht nachvollziehen. Es gibt keine BSOD oder sonstige Fehlermeldungen dazu. Auch der Aufgabenverlauf wird durch den Freeze nicht geloggt, beim Neustart sieht es aus, als hätte man die Aufgabe nie gestartet. Da ich immer noch den TPM-Fehler "Aktualisierte Zertifikate für den sicheren Start sind auf diesem Gerät verfügbar, wurden aber noch nicht auf die Firmware angewendet." habe, habe ich versucht, die Updates über die bei Microsoft ausführlich beschriebenen manuellen Registry-Änderungen unter HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing und anschließendem Start des Secure-Boot-Update Tasks anzustoßen. Allerdings führte das dann immer zu einem Freeze, hier sogar unabhängig davon, ob mit dem Internet verbunden oder nicht. Aktuell steht der REG_DWORD-Wert für AvailableUpdates unter HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing auf 0x00000000, das hat Windows nach dem letzten Security Update selbst so konfiguriert. Hier führt die Ausführung von Secure-Boot-Update ohne Internet zu keinem Freeze. Andere Werte, mit oder ohne Internetverbindung, schon. Als alternative Abhilfemaßnahme, die den Freeze verhindert und wo man den PC nach dem Hochfahren wenigstens gleich nutzen kann, bleibt aktuell daher das Deaktivieren der Aufgabe Secure-Boot-Update in der Aufgabenplanung. Wenn auch das irgendwann nicht mehr hilft und es keine Lösung dazu gibt, vermutlich nur noch das Deaktivieren von Secure Boot im BIOS.

__Seraph_ · ‎19.03.2026

Hallo, ggf. als Nachtrag für alle, die den Realtek RTL8821AU Wireless LAN 802.11 ac USB 2.0 Network Adapter verbaut und damit Probleme haben. Das Gleiche hatte ich bei meinem P5378 I ebenfalls und er war deswegen auch schon in der Reparatur. Wenn ich mich richtig erinnern kann, fiel das WLAN immer öfter aus. Zunächst verband sich der PC wieder automatisch und irgendwann führten die Abbrüche dazu, dass in der Taskleiste immer ein rotes "x" angezeigt wurde. In den Netzwerkeinstellungen konnte man oft nur ausgegraute Elemente vorfinden. Im Gerätemanager wurden auch Probleme angezeigt. Zunächst wurden Treiber-Updates, Treiber deinstallieren bis hin zum Zurücksetzen von Windows empfohlen, allerdings waren die Ergebnisse eher zufällig. Mal ging es, mal nicht. Die Netzwerkdiagnose lieferte immer vorhandene Probleme, die nicht behoben werden konnten. Nach dem Einsenden teilte man mir mit, dass es wohl an der Hardware selbst lag und es eine fehlerhafte Lötverbindung des Kabels gab. Die Reparatur hielt jedoch nicht lange, das Problem kam relativ zügig wieder. Da ich den PC nicht erneut einsenden wollte, da hierbei jedes Mal die Daten gelöscht werden, habe ich mich damit abgefunden und mir einen WLAN-Stick (FRITZ!WLAN USB Stick AC 860) gekauft. Die Verbindung und der Durchsatz waren damit ohnehin besser (zumindest in Kombination mit einer FRITZ-Box). Den "alten" Realtek Adapter habe ich in den Einstellungen entsprechend deaktiviert, nach Ablauf der Garantie dann das Kabel zudem vom Mainboard getrennt. Ergebnis: Ständige Abbrüche bei diesem WLAN Adapter können auch, wie schon eingangs beschrieben, an der Hardware selbst liegen. Grüße, __Seraph_

__Seraph_ · ‎19.03.2026

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_

__Seraph_ · ‎19.03.2026

Hallo @daddle , aktuell läuft mein Rechner noch mit Windows 10 (Windows 10 Home, 10.0.19045 Bulit 19045 (für ESU registriert)). Die vom Mainboard unterstützte CPU-Generation (Intel Core 6th Generation Skylake) ist offiziell nicht Windows 11 fähig. Im BIOS lassen sich Secure Boot und TPM 2.0 bei mir verwalten, beide sind aktiv. Das Einzige was für Windows 11 nicht qualifiziert ist, ist die CPU. Dazu muss ich mir dann zum Ende der Security-Updates für Windows 10 Gedanken machen. Über den Befehl tpm.msc kann man den Status des Sicherheitschips (TPM) auslesen: Grüße, __Seraph_

__Seraph_ · ‎18.03.2026

Hallo, Ich habe bei mir mit dem H110H4-EM sogar 32 GB RAM mit 2.133 MHz verbaut und es läuft ohne Probleme. Soweit ich weiß, ist das Board auf 2.133 MHz Taktfrequenz ausgelegt, die Verwendung von 3.000 MHz-RAMs (die zumindest auch mit dieser Taktrate laufen) fällt meiner Meinung nach damit aus. In den FAQ werden max. 16 GB beschrieben. Verbaut habe ich 2x 16 GB (Samsung M378A2K43BB1-CPB), allerdings weiß ich nicht, ob das bei jedem H110H4-EM Board problemlos funktioniert. Bei mir läuft die BIOS-Version American Megatrends Inc. 110EMW0X.105, 12.01.2018 Grüße, __Seraph_

__Seraph_ · ‎18.03.2026

Hallo, vielleicht etwas spät. Falls diese Info für jemanden interessant ist: Ich habe bei mir mit dem H110H4-EM 32 GB RAM mit 2.133 MHz verbaut und es läuft ohne Probleme. Soweit ich weiß, ist das Board auf 2.133 MHz Taktfrequenz ausgelegt. Ich habe damals in den FAQ recherchiert, wo max. 16 GB beschrieben sind. Ich habe zudem den cmd Befehl wmic memphysical get maxcapacity ausgeführt und als Ergebnis folgenden Wert erhalten: MaxCapacity 33554432 Mir war bewusst, dass dieser Ausgabewert ggf. nicht korrekt ist. Der wmic-Befehl ist hierfür nicht immer zuverlässig, aber ich habe es einfach probiert. Zumindest in meinem Fall laufen die 32 GB ohne Probleme. Verbaut habe ich 2x 16 GB (Samsung M378A2K43BB1-CPB). Grüße, __Seraph_

Date Registered	‎18.03.2026 22:05
Date Last Visited	‎03.06.2026 22:12
Total Messages Posted	20
Total Kudos Received	22

About __Seraph_

Re: Update von Secure-Boot-Zertifikaten auf (älter...

Re: Windows 10 friert nach Update im März 2026 nac...

Secure Boot Violation nach Mai-Update (Win 10) tro...

Re: Medion Akoya E7420 BIOS Dump benötigt

Re: Bios Update NEUE Zertifikate 2023

Re: Medion Akoya E7420 BIOS Dump benötigt

Re: Windows 10 friert nach Update im März 2026 nac...

Re: Update von Secure-Boot-Zertifikaten auf (älter...

Update von Secure-Boot-Zertifikaten auf (älteren) ...

Re: Windows 10 friert nach Update im März 2026 nac...

Re: Älterer MEDION ERAZER X5326 Freeze

Re: Älterer MEDION ERAZER X5326 Freeze

Re: Windows 10 friert nach Update im März 2026 nac...

Re: Windows 10 friert nach Update im März 2026 nac...

Re: Windows 10 friert nach Update im März 2026 nac...

Re: Medion Akoya P5378l Treiber setzt immer wieder...

Windows 10 friert nach Update im März 2026 nach 5 ...

Re: H110H4-EM Arbeitspeicher

Re: H110H4-EM Arbeitspeicher

Re: H110h4-em

Legal information

MEDION products and shops

About MEDION