Nach dem letzten Windows 11-Update (Kumulatives Update für Windows 11 24H2, KB 5063060), das am 14.06.2025 routinemäßig eingespielt wurde, ging nichts mehr! Nach dem Einschalten des Rechners erschien das Logo ‘Fujitsu’ auf dem Bildschirm und das war es dann. Der Esprimo-Rechner fror ein. Man nennt so etwas ‘bricking’. Der PC ist damit faktisch nicht mehr brauchbar, damit Elektroschrott.
Ich kam auch nicht mehr in das BIOS (Drücken der Taste F2 nach dem Einschalten). Ich hatte vorher schon einmal flüchtig über Probleme beim Updaten mit Windows 10 auf Fujitsu Esprimo-Rechnern gelesen aber das Problem tritt offensichtlich auch bei Windows 11 auf. Mein Esprimo-Rechner ist ein Modell P956/E94+. Er erfült mit seiner CPU Intel i7 6700 (Skylake‑S, 3,4 GHz) offiziell zwar nicht mehr die Hardware-Voraussetzungen für ein Upgrade auf Windows 11, aber mit Einfügen eines Registry-Key klappte es doch. Zumindest bisher. Hier ist ein Link (https://www.deskmodder.de/wiki/index.php?title=Windows_11_auch_ohne_TPM_und_Secure_Boot_installieren) zu dieser Möglichkeit, ältere Rechner noch von Windows 10 (Support endet im Oktober 2025!) auf Windows 11 upzugraden.
Abbildung: Updateverlauf von Windows 11 (24H2) auf meinem Esprimo-Rechner vor dem bricking. Das letzte Update wurde am 14.06.25 (“erfolgreich”) eingespielt, beim nächsten Boot-Versuch des Rechners ging dann nichts mehr.
Haben andere Nutzer auch so ein Problem?
Beim Recherchieren stieß ich auf einen Blogbeitrag von Gunnar Haslinger (https://hitco.at/blog/fujitsu-d3410-b-mainboard-recovery-uefi-bios-flash-nach-secureboot-dbx-windowsupdate/) zu diesem Problem, d. h. de facto-bricking von Esprimo-Rechnern nach einem Windows 10-Update. Das konkrete Problem ist das Update der Secure-Boot-Datenbank (DBX-Update). Offensichtlich sind die Einträge in der Secure Boot DBX (Forbidden Signature Database) inzwischen so angewachsen, dass das BIOS damit ein Problem hat und das BIOS “aussteigt”. Wahrscheinlich ist der vom BIOS hierfür reservierte Platz zu klein. Man muss bedenken, dass diese Rechner betagt sind. Vermutlich wird Fujitsu kein BIOS-Update mehr liefern wird. Ob Microsoft sich des Problems annehmen wird?
Problemlösung: BIOS neu einspielen.
Die Lösung, die bei mir geholfen hat, steht in dem Blog von Gunnar Haslinger (Link siehe oben). Man muss das entsprechende BIOS-File für das verbaute Mainboard herunterladen. Auf dem FTP-Server von KONTRON (https://ftp.kontron.com/ (Benutzername ist „anonymous“, kein Passwort)) fand ich das BIOS-File, das zu meinem Mainboard (D3402-A1) passte. KONTRON bittet, das BIOS hier herunterzuladen, da der Server inzwischen überlastet sei. Bei mir gab es aber (16. Juni) keine Probleme. Auf dem Support-Server von Fujitsu (https://support.ts.fujitsu.com) fand ich das BIOS-File nicht. Die Seite wirkt auf mich sehr unübersichtlich.
Ich konnte den gezippten Ordner namens D3402-A1x.R1.29.0.ZIP herunterladen und u. a. folgende Files extrahieren:
- D3402-A1.rom
- D3402-A1.UPC
- D3402-A1.UPD
- EfiFlash.exe
Die Bezeichnungen variieren je nach Mainboard. In meinem Falle war das Mainboard ein D3402-A1.
Entsprechend den Vorgaben von Gunnar Haslinger formatierte ich einen USB-Stick mit RUFUS (https://rufus.ie/de/), FAT32 und FreeDos bootfähig. Danach kopierte ich die Files in dem heruntergeladenen und entpackten Files auf den USB-Stick. Fujitsu hat eine Firmware BIOS/UEFI Recovery Möglichkeit vorgesehen, die ganz ohne Betriebssystem bzw. Bootmedium auskommt. Um dieses Recovery zu aktivieren, muss man erst mal den hierfür nötigen Jumper im vorderen Bereich (Front Panel) des Mainboards suchen. Den Netzstecker vorher ziehen! Bei mir war der Jumper vor den Steckkontakten der Speicherriegel positioniert. Wie im Blog von Gunnar Haslinger und auch in der “Short Description” des Mainboards gezeigt, muss man den Jumper (bei meinem Board hinter den vierpoligen + / — Steckkontakten der Speaker) von der Normal-Position auf dem zweiten und dritten Pin auf der ersten und zweiten Pin versetzen (“Recovery”).
Abbildung: Schematische Zeichnung des Mainboards Fujitsu D3402-A1, ntnommen aus dem Handbuch des Mainboards. Die mit ‘Front panel’ bezeichnete Pin-Leiste am vorderen Ende des Mainboards ist vergrößert (rote Pfeile). Die für das BIOS-Recovery wichtigen drei Pins sind grün umrandet. Der ‘Normalzustand’ (Jumper auf PIN 2 und 3) ist mit einem grauen Balken unterlegt. Für das BIOS-Recovery muss der Jumper auf Pin 1 und 2 (von links her gesehen) gesteckt werden. Zwischen diesen beiden Pins steht ‘Recovery’ in der Abbildung.
Abbildung: Fotografie des Mainboards Fujitsu D3402-A1. Die Lokalisation des zu versetzenden Jumpers im ‘Front panel’ ist mit einem lila Pfeil gekennzeichnet. Ich musste zuvor den vierpoligen Stecker mit dem + / — Kabel des Lautsprechers abnehmen, damit ich an den Jumper herankam. Bevor man an die Sache rangeht, empfehle ich ein Foto zu machen, damit man später weiss, was wo platziert war!
Den formatierten USB-Stick mit dem BIOS-File steckt man in eine auf der Rückseite (!) des Mainboards angebrachte USB-Buchse. Danach verbindet man den Rechner wieder mit dem Netz und drückt den Einschaltknopf vorne am Rechner. Danach dauert es einige Minuten. In dieser Zeit bleibt der Bildschirm schwarz und es kommen verschiedene (wild klingende) Piepstöne aus dem Lautsprecher des Rechners. Danach erscheinen auf dem Bildschirm Anweisungen, was als Nächstes zu tun ist. Ist das erledigt, schaltet man dann den Rechner aus und zieht den Netzstecker. Anschließend wird der Jumper wieder in die ursprüngliche Position (Pin zwei und drei) gesteckt. Dann schaltet man den Rechner wieder ein. Ich drückte dann die F2-Taste und ging in die BIOS-Oberfläche. Sicherheitshalber schaltete ich im BIOS ‘Secure-Boot / TPM’ aus und sicherte die BIOS-Einträge. Bei mir bootete der Rechner nun problemlos in das Betriebssystem und das Windows 11-Logo erschien. Der Rechner funktionierte wieder. Entsprechend den Empfehlungen im Blog von Gunnar Haslinger deaktivierte ich in der Aufgabenplanung von Windows 11 ‘Secure-Boot-Update’ (Aufgabenplanung -> Microsoft\Windows\PI -> Secure-Boot-Update). Zusätzlich wollte ich wie im Blog beschrieben den den Registry-Key auf den dword-Wert ‘0’ ändern, um ein erneutes Secure Boot-Update zu verhindern:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot]
“AvailableUpdates”=dword:00000400
Bei mir stand der dword-Wert aber schon auf 0, vielleicht weil ich im BIOS ‘Secure Boot’ schon auf ‘disabled’ gestellt hatte.
Verhindern, dass Windows-Update erneut patzt!
Das beschriebene Vorgehen sollte vorerst erneute Versuche von Windows-Update unterbinden, ein Secure-Boot-Update durchzuführen. Secure Boot / TPM lasse ich erst einmal im BIOS deaktiviert, auch wenn es ein Sicherheitsrisiko darstellt. Den USB-Stick mit dem BIOS-File halte ich zur Sicherheit in Griffnähe bereit.
Schlussfolgerungen
Ich nutze seit ca. 40 Jahren Betriebssysteme von Microsoft, beginnend mit MS-DOS über Windows 3.11, Windows 95, Windows 98, Windows XP, Windows 7, Windows 8, Windows 10 und jetzt zum Schluss Windows 11. Jedemal saß ich bangend vor dem Rechner, wenn Updates von Windows eingespielt wurden. Ich habe jetzt für mich die Konsequenz gezogen und einen Mac mini von Apple angeschafft. It works like a charm! Seit über einem Jahr nutze ich ihn. Updates werden problemlos eingespielt, und der Rechner funktioniert danach genauso wie vorher. Ehrlicherweise muss man aber auch sagen, dass Apple sein Betriebssystem auf eine definierte Hardware ufsetzt und damit Problemen aus dem Weg geht, die Windows mit einer Vielzahl zu bedienenden Hardwarekomponenten und ‑plattformen hat. Den Windows 11-Rechner (Fuijitsu Esprimo) brauche ich noch für einige Programme, für die es aus meiner Sicht kein Äquivalent auf dem Mac gibt. Probleme bei Upgrades von Ubuntu speziell von Kubuntu (https://linuxnews.de/upgrade-von-ubuntu-24–10-auf-25–04-gestoppt/) musste ich leider auch immer wieder erleben. Auch Linux muss wie Windows auf eine Vielzahl von Hardwarekomponenten aufsetzen.