[English]Kurze Information für Informationen, die noch Surface Pro 8-Geräte verwalten. Es scheint ein Problem zu geben, dass diese Geräte plötzlich ihrer UEFI-Informationen (Hersteller, Modell, Seriennummer) verlieren. Das bringt dann ziemlichen Ärger.
Anzeige
Eine Lesermeldung zum Ärger
Blog-Leser Mario H. hat sich bei mit per E-Mail gemeldet, weil er mit seinem Bestand an Surface Pro 8-Geräten in argen Ärger läuft. Insgesamt verantwortet er einen Bestand von über 430 Geräten. Nun musste die IT die unangenehme Erfahrung machen, dass von dieser Geräte-Flotte bereits sieben Exemplare ihre im UEFI Datenbereich gespeicherten Informationen zum Hersteller, zum Modell und zur Seriennummer von jetzt auf gleich verloren haben.
UEFI-Geräteinformationen weg
Der Leser schrieb dazu: "Diese Geräte verlieren alle ihre Identifikations-Merkmale im UEFI". Dann wird beim Start eine Bitlocker Recovery Key-Abfrage getriggert. Er vermutet zudem, dass diese Geräte auch keine weiteren Firmware Updates mehr via Microsoft Update bekommen werden, weil ja das Modell nicht mehr identifiziert werden kann.
Umstände des Datenverlusts unklar
Der Leser schrieb, dass die Umstände, wie es zu diesem Datenverlust auf den sieben betroffenen Geräten kam, bis jetzt noch völlig unklar seien. Die Geräte werden von der IT über Intune verwaltet und durch Autopatch aktuell gehalten.
UEFI-Datenbereich durch UEFI-Update gekillt?
Eine naheliegende Vermutung wäre ein UEFI-Update oder andere Firmware-Updates. Hier hegt der Leser aber Zweifel, da er viele Geräte mit der gleichen UEFI-Version betreibt, wo das Problem bis jetzt noch nicht aufgetreten ist. Dazu merkt er an: "Kann nicht sagen ob andere Firmen ihre Landschaft auch regelmäßig nach doppelten Seriennummern durchforsten."
Anzeige
Der Leser meinte dazu: "Wäre irgendwie interessant ob es anderen auch so geht oder dass jemand durch den Hinweis vielleicht auch mal seine Umgebung checkt."
UEFI-Datenbereich per Windows Update überschrieben?
Mir persönlich ging auch noch die dbx-Aktualisierung von Mai 2025 im Kopf herum, deren Auswirkungen ich im Blog-Beitrag Vorsicht: Windows Juni 2025-Updates bricken Fujitsu-Rechner beschrieben habe. Dort gibt es die Erklärung, dass die Secure Boot-Einträge durch ein Windows Update manipuliert wurden, die Einträge aber so umfangreich wurden, dass Speicherbereiche im UEFI nicht mehr ausreichen. In Folge kam es zu gebrickten Systemen – Abhilfe ist das Flashen eines UEFI/BIOS-Abbilds oder das Abschalten von Secure Boot. Das bezog sich nur auf Fujitsu-Rechner. Beim Surface Pro 8 könnte durch so eine Manipulation der dbx-Records möglicherweise ein Speicherbereich mit den OEM-Informationen überschrieben worden sein.
Ergänzungen des Lesers
Im Nachgang hat der Leser noch mitgeteilt, dass in seinem Umfeld die ersten beiden Geräte auch erst Mitte April 2025 bezüglich des obigen Problems aufgefallen seien. Zuerst dachte der Leser an einen Mainboard Tausch, wo der Techniker dann vergessen hat, die Informationen für das Gerät wieder in den UEFI-Datenbereich einzuspielen. Nachdem sich aber herausgestellt hatte, dass die Geräte nie in Reparatur waren, wurde der Leser hellhörig.
Der Leser ergänzte dann in einer Mail, dass dem Unternehmen jetzt nichts anderes übrig bleibt, als die Geräte einzuschicken. Die meisten dieser Geräte haben noch aktiven Support – es gilt halt lediglich logistische Klimmzüge zu absolvieren, da die Geräte in China, Frankreich, England und Österreich betrieben werden. Da hängt dann ein gewisser administrativer Aufwand (Leihgeräte) dran. Das sei zwar ärgerlich aber bis jetzt noch einigermaßen überschaubar, merkt der Leser an.
Mehr als Austausch gegen ein refurbished Gerät oder Reparatur wurde dem Unternehmen seitens Microsoft wohl nicht angeboten. Ein offizielles Tool zum Selbst-Nachtragen der Informationen, scheint es nicht für die Öffentlichkeit zu geben, merkt der Leser an. Er schrieb "Macht meiner Meinung nach aber auch Sinn, sonst könnte ja auch ein Dieb einfach die Seriennummer ändern um z.B. Geräte, die in Autopilot registriert sind, wieder nutzbar zu machen".
Weitere Fälle auf reddit.com
Der Blog-Leser hat mir noch einen Link auf den reddit.com-Beitrag Surface Pro 8 – issue – now identifies as OEMCT Product! mitgeschickt (danke dafür), wo ein Surface Pro 8-Besitzer das Problem ebenfalls beschreibt. OEMCT scheint der Platzhalter im UEFI für Surfaces zu sein. Der Betroffene hat sein Tablet in den Ruhemodus versetzt. Als er das Surface 8 Pro später zu Hause einschalten wollte, kam er nicht mehr in Windows.
Surface Pro 8 hängt beim Booten, Quelle: reddit.com
Nach dem Drücken der Lautstärke- und Einschalttaste konnte er das Surface Pro 8 zwar zum Booten überreden. Aber das Gerät fragte nach dem Bitlocker-Schlüssel, und beim Booten des Systems erschien ein roter Streifen mit offenem Schloss auf dem Display (siehe obiger Screenshot).
Der Betroffene schreibt, dass er kein Secure Boot einschalten könne, aber das Gerät habe gewusst, dass es ein Surface Pro 8 ist. Nach dem obigen Malheur identifiziert sich das Gerät als "OEMCT-Produkt". Der Leser schreibt auch, dass sich die Seriennummer auf 123123123 geändert habe. Das ist ein Platzhalter, der normalerweise durch die vom Hersteller zugewiesene Seriennummer überschrieben wird. Da sind offenbar Daten im UEFI gelöscht worden.
Es ist für den Nutzer also nicht mehr möglich, einen Treiber für das Surface Pro 8 zu installieren, da die Validierung fehlschlägt. Sogar unter dem MS-Profil wird dem Benutzer angezeigt, dass er sich auf einem anderen Gerät (OEMCT, nicht mehr Surface Pro 8) angemeldet hat. Den Namen im Profil kann er nicht bearbeiten, da dieser vom System generiert wird. Der Betroffene hat den Fall mit weiteren Screenshots dokumentiert.
An dieser Stelle wird klar, dass eine Neuinstallation von Windows wenig erfolgversprechend sein kann. Der MS-Techniker im Live-Chat konnte nichts für den Betroffenen tun.
Auch dieser Nutzer fragt, ob jemand ähnliche Erfahrungen gemacht habe, oder weiß, wie man es beheben kann? Geht man den reddit.com-Thread durch, bestätigen weitere Betroffene diesen Fehler, der seit ca. Ende April (seit ca. 2 Monaten) auftritt. Ein Betroffener schreibt, dass Microsoft das auf das Motherboard schiebt und ein UEFI-Reset per Flash als Lösung angibt. Das kann aber wohl nur Microsoft erledigen und wollte dem Betroffenen ein kostenpflichtiges refurbished Surface Pro 8 als Ersatz anbieten. Sieht mir entweder nach einem Serienfehler aus, wo ein Flash-Speicher zum Ablegen der volatilen UEFI-Werte mit der Zeit stirbt. Oder irgend etwas mischt da per Update bei den Geräten im UEFI mit.
Anzeige
UEFI entpuppt sich als perfekter Killswitch, wer hätte das gedacht. Ein "passendes" Windows Update und man kann beliebige Geräteserien oder Regionen zu Elektroschrotthalden machen, selbst wenn die Eigentümer der Geräte sich eigene ISOs für Desaster Neuinstallation gespeichert hätten. Genial.
oh junge, wie recht du hast.
die Welt bleibt spannend.
Just my 2 cents: https://github.com/LongSoft/UEFITool/blob/new_engine/README.md
Idee: Von USB Flash Disk ein Linux booten, das passende Binary starten und passende/erforderliche Werte für Herstellerbezeichnung etc. von Hand eintragen. 'Die KI' empfiehlt Kali Linux oder SystemRescue (Linux), in denen UEFITool jedoch nicht integriert ist!
Alles auf eigene Gefahr, ich habe keinerlei praktische Erfahrung mit dem Tool.
Unter https://uefi.org/specifications gibt es allfällig nützliche Dokumente betr. UEFI Platform Initialization Specification (aka UEFI PI Specification).
Moin,
ich habe noch mal paar weitere Informationen, die vielleicht hier rein passen, vielleicht aber auch nicht.
Ein Notebook (2 1/2 Jahre alt) unserer Familie hatte letzte Woche nach einem Windows Update Boot Probleme. Das Notebook hing beim Gigabyte Logo fest. Ich kam nicht mehr ins Windows. Außer ins BIOS oder ins Bootmenü.
Daraufhin bin ich dann auf Reddit auf folgendem Beitrag gestoßen:
https://www.reddit.com/r/gigabyte/comments/1ladf27/gigabyte_g5_kf5_stuck_on_startup_screen/
Gleiche Notebook-Serie G5. Daraufhin dann mit der Anleitung aus dem Beitrag das System wieder zum Laufen gekriegt. Bootstick erstellt, Gigabyte BIOS drauf und ein Shell-Skript in der Kommandozeile ausgeführt. BIOS "Update" durchgeführt. Dadurch war das erste Release des Gigabyte BIOS wieder installiert. Soweit so gut .. es startete.
Anschließend wollte ich die ganze Geschichte abschließen und das aktuellste BIOS wieder installieren… großer Fehler … Nach der Installation (der Installationsbalken war bei 100%) und im Status machte mein System auf ein mal ein Bluescreen. Es ging nichts mehr… keine Akkuladestand, Power-Button reagiert nicht mehr, das Notebook ist komplett tot.
Hatte noch probiert die BIOS Batterie zu entfernen, Akku raus, Gerät entladen usw… keine Chance. Das Gerät startet einfach nicht mehr.
Mein aktuelle Stand ist, dass ich versuche das BIOS mit einem Programmer selbst wieder zu flashen da ich seitens Gigabyte gar keine Rückmeldung bekomme.
Zufall dass das alles mit einem Windows Update begann? Ich denke nicht …
"Es ist für den Nutzer also nicht mehr möglich, einen Treiber für das Surface Pro 8 zu installieren, da die Validierung fehlschlägt."
Wenn UEFI Update nicht mehr installiert werden können wäre das nachvollziehbar. Diese scheitern dann halt am Kompatibilitätstest.
Ein Treiber sollte doch nur eine Hardware ID abfragen. Über dem Gerätemanager sollte man die von Hand zuordnen können. Ein entpacktes Installationspaket vorausgesetzt. .inf von Lokalem Datenträger auswählen und anschließend zu Installierendes Gerät aus einer Liste auswählen. Ohne aktives Secure Boot sollte eigentlich alles was Installiert wird geladen werden.
Das Bild mit dem Surface Pro 8 und dem offenen Schloss könnte auch auf ein gelöschtes TPM hindeuten. In der Regel werden die Geräte mit vorinstalliertem Windows seitens der Hersteller mit partiell aktiviertem Bitlocker ausgeliefert. Wenn man in so einem Fall den Revovery-Key nicht hat, sind die Daten dann weg.