Noch ein Nachtrag in eigener Sache: Die Ursache für das Secure Boot-Problem, welches nach dem April-Patchday bei UEFI-Systemen von ASUS unter Windows 7 auftrat, ist zwischenzeitlich sowohl von Microsoft als auch von Asus adressiert worden.
Zum Hintergrund: Nach dem April 2016-Patchday streikten diverse Rechner mit Asus UEFI-Mainboards, wenn Windows 7 installiert war. Mitte April 2016 hatte ich im Artikel Windows 7: Patchday-Nachwehen „Secure Boot Violation“ von diesem Problem berichtet und einen Workaround vorgeschlagen.
(Quelle: Computerbase)
Jetzt bin ich bei betanews.com auf eine Erklärung gestoßen, die meine Hinweise im Blog bestätigt. Auch dort wird bestätigt, dass Update KB3133977 die Ursache sei. Neu für mich ist aber die Erklärung seitens Microsoft, die wohl irgendwann im verlinkten KB-Artikel nachgetragen wurde.
After you install update 3133977 on a Windows 7 x64-based system that includes an ASUS-based main board, the system does not start, and it generates a Secure Boot error on the ASUS BIOS screen. This problem occurs because ASUS allowed the main board to enable the Secure Boot process even though Windows 7 does not support this feature.
Aber es wäre doch gelacht, wenn Microsoft keine Lösung für dieses kleine Problemchen hätte. Ihr ahnt es sicherlich schon:
The Secure Boot feature is supported in Windows 10. To learn more about the security advantages of this feature and about the upgrade path from Windows 7 to Windows 10, go to the following Windows website …
Asus hat zu diesem Fehler zwischenzeitlich diese FAQ-Seite aufgesetzt. Dort wird der von mir ursprünglich skizzierte Workaround “Secure Boot abschalten” ausführlich beschrieben.
Dass Microsoft auch eine tatsächliche Lösung des Problems anbietet, die nicht auf Windows 10 verweist, hast du aber jetzt irgendwie unterschlagen… ;-)
„To resolve this problem, go to the following ASUS support website to learn how to disable Secure Boot for Windows 7“
Leider erklärt auch Betanews nicht, was das wirkliche Problem an der Sache ist: ASUS hat eine Routine in ihrem UEFI, die automatisch SecureBoot aktiviert, wenn ein OS erkannt wird, das dieses beherrscht. Durch das Update für Windows 7 werden u.a. die Bootloader-Dateien aktualisiert, da sich der entsprechende Fix nun mal auch auf den Bootloader bezieht. Das ASUS UEFI verschluckt sich hinterher und erkennt das installierte System nicht mehr als Windows 7 und aktiviert SecureBoot – und legt damit den Bootvorgang lahm.
Hätte man einfach den Leuten gesagt „Windows 7 unterstützt kein SecureBoot, also schalte es ab!“, wäre nix gewesen. Aber ASUS musste da ja solch eine Automatik einbauen. Und wenn die spinnt, ist das ganz alleine Schuld von ASUS. Schreibt aber keiner, denn auf Microsoft kann man ja besser fluchen…
Mit der Microsoft-Lösung meinst Du den Verweis auf die ASUS-Lösung? Da der KB-Artikel verlinkt ist, konnte das jeder selbst herausfinden – und das war ja auch im Ursprungsbeitrag bereits als Lösung aufgeführt.
Zum Henne Ei-Problem „wer hat Schuld“ – klar, kann man ASUS beschuldigen – und deren Lösung ist doof. Wenn mich nicht alles trügt, ist der Fehler ja auch bei MSI-Boards aufgetreten. Flotter wäre möglicherweise aber gewesen, keine Ahnung, ob das technisch geht, den Fall Secure Boot abzufangen.
Nachtrag: Das Problem hat nun wohl auch Eingang bei heise.de gefunden. Zudem entnehme ich diesem Beitrag, dass Asus wohl „Secure Boot“ auf den betroffenen Mainboards per default aktiviert. Nachdem das fragliche Update letzten Woche von optional auf wichtig umgestellt wurde, hat es wohl mehr Leute getroffen.