[Sammelthread] Wenn Secure Boot macht Probleme...

[Dennis50300]

"fTPM" Stutter" soll damit ja behoben werden, ohnehin eine Sache die es bei niemandem gibt, wo die Rechner durch meine Hand vernünftig eingerichtet worden sind...

Nunja, an sich läuft es, macht aber blöderweise Probleme, ich hab zwei Beispiele, vielleicht habt ihr aber dann noch ähnliche weitere Probleme

- Asus Prime B450 Plus
- MSI B450-A Pro

Auf dem Asus ein 2600X auf dem MSI oh wunder, ein 2700X.
Alles funktioniert soweit, nur beim Herunterfahren (egal ob "Schnellstart" aktiviert oder deaktiviert ist) bleibt die Kiste beim Herunterfahren sowie beim "Neu Starten" kleben.
Irgendwie kommt der Rechner dann nicht mehr zum warmstart sowie auch zu keinem Kaltstart, bzw. Kaltstart erreicht man dann nur mit Power-Button gedrückt halten, also Rechner komplett aus und dann wieder einschalten.
Kein instabiles OC, oder überhaupt OC, ist dasselbe.

Das gab es bei meinem MSI Brett zuvor beispielsweise nicht, da hatte ich zuletzt ein Beta-Bios drauf, was die Agesa 1206 drin gehabt haben muss.
Blöd ist jetz nur das ich das alte Beta-Bios File von davor, zumindest nicht auf die Schnelle mal eben zu Hand habe, hab meinen Bios-USB Stick irgendwie gerade verlegt oder wo vergessen, wo ich dann mal wieder zur Hilfe kam...hm...

Workaround:
Herunterfahren per Power-Button scheint davon nicht betroffen zu sein, hilft leider für "Neu Starten" nicht (sind wohl andere Softwareparts dahinter, könnte also auch ein reines Windows-Problem sein, who knows )


Gruss Dennis

 

[oNyX`]

Mit OC meinst du XMP? Die neueren AGESA Versionen sind bekannt dafür zickig zu sein mit XMP. 1.2.0.3 war die letzte die noch absolut stressfrei in der Hinsicht war.

 

[Dennis50300]

Mit OC meinst du XMP? Die neueren AGESA Versionen sind bekannt dafür zickig zu sein mit XMP. 1.2.0.3 war die letzte die noch absolut stressfrei in der Hinsicht war.

noch nichtmal das, auch ohne XMP
Mit OC meine ich, selbst getätigtes OC, anstelle PBO in dem Falle, XMP wäre durchaus aber auch schon OC ja, woran es aber nicht liegt.

Gruss Dennis

 

[Dennis50300]

Auch @PCFreak69
So moment mal, ein so altes BIOS kann solch ein Problem durch ein agesa Update ja nicht haben
Es sei denn der mikrocode wird wie bei einem Linux über den bootloader dann noch aktualisiert.(intel sowie AMD)

Ein älteres löst dies nicht, aber die unterschiedliche Nutzung den PC herunterzufahren macht ja einen Unterschied.

Soll ein Windows Update nach dem letzten patch day dafür verantwortlich sein was mich und meinen dad gleichermaßen mit zwei verschiedenen Boards dann wohl betrifft.

Also entweder hab ich jetz auch mal einen Bug dank Microsoft den die in win10 und 11 gleichermaßen reingebastelt haben, sei es drum das es an der agesa liegt die auch durch den bootloader auf den stand gebracht wird oder doch was anderes am OS mal dahingestellt

Auffällig ist das ich das problem mit Ubuntu LTS nicht habe, dieses OS ist ja quasi dahingehend was den microcode per bootloader aktualisieren angeht allerdings der Vorbote, sprich damit passiert das schon eher als mit einem Windows 10 oder auch 11

Ich vermute ja so langsam grad das es tatsächlich eher an Windows bzw Microsoft liegt.

Mal sehen, einfach nach "Neu Starten" werde ich jetz mal auf den power button legen... 😂

Zu geil, wegen so nem stuss das Board mal eben 2 bis 3 mal Flashen... Kannste dir nich ausdenken....

Gruss Dennis

 

[PCFreak69]

Beim aktuellen MSI B450 A-Pro Bios ist Secure Boot automatisch im Bios aktiviert, wahrscheinlich beim aktuellen Asus B450 ebenfalls.
Die Secure Boot Keys auf dem Windows Laufwerk und im Bios können auch noch dem deaktivieren von Secure Boot Probleme verursachen.

Wie du die Secure Boot Keys vom Windows Laufwerk und aus dem Bios gelöscht bekommst findest du mit Sicherheit per Google suche.


Edit:
100% gelöscht vom Windows Laufwerk bekommst du die Secure Boot Keys per diskpart clean all, dann ist das Windows Laufwerk aber komplett gelöscht.
Es gibt mit Sicherheit noch Methoden bei dem du das Windows Laufwerk nicht löschen musst.

 

[Glaskugel]

Ich wäre froh die AGESA 1.2.0.7 überhaupt zu haben .
Kein Plan was Asus da für Probleme hat oder warum das solange dauert bei den ROG B450er Brettern . Du bekommst halt auch nirgends Infos dazu wann oder ob überhaupt noch was kommt .
Das stuttering kann man definitiv feststellen in bestimmten Situationen in Game oder auch bei Spotify beim Audio.

 

[PCFreak69]

Das stuttering kann man definitiv feststellen in bestimmten Situationen in Game oder auch bei Spotify beim Audio.

Du kannst fTPM deaktivieren, Windows 11 Updates gibt es trotzdem.

Ich empfehle dir vor der Bios Installation mit AGESA 1.2.0.7 das Windows Laufwerk vom Mainboard zu entfernen,
und nach der Bios Installation sofort Secure Boot im Bios zu deaktivieren ansonsten hast du wahrscheinlich die gleichen Probleme wie der Thread Ersteller.

 

[Dennis50300]

Du kannst fTPM deaktivieren, Windows 11 Updates gibt es trotzdem.

Ich empfehle dir vor der Bios Installation mit AGESA 1.2.0.7 das Windows Laufwerk vom Mainboard zu entfernen,
und nach der Bios Installation sofort Secure Boot im Bios zu deaktivieren ansonsten hast du wahrscheinlich die gleichen Probleme wie der Thread Ersteller.

Secure Boot funktionierte vor dem letzten Patchday mit Windows allerdings auch einwandrei, soweit ich das sehe.
Wie schon geschrieben das Problem ist nicht die Agesa, nicht das Bios, von gewohnheiten Abweichen, behebt das Problem wie beschrieben, also kann es ziemlich sicher nunmal nur Softwaremurks sein seitens Windows.

Was Win11 anbelangt war Secure Boot ja eigentlich auch eine der neuen Systemvorrausetzung wenn ich da nun nicht irre.


Gruss Dennis

 

[Dennis50300]

@PCFreak69:
Bin nun wieder auf das aktuellste Bios, dein Tipp mit Secure Boot war nun halt auch nicht so abwegig, Secure Boot also neu eingestellt, praktisch neu aktiviert, könnte das ganze an sich ja nun auch behoben haben.
Erstmal jetzt Testen, wie schon geschrieben Secure Boot an sich ist ja nun eine "neue" Systemvorrausetzung, das zum einen, zum anderen muss man mit der AGESA halt auch sehen das so eine aktualisierung des Microcodes der CPU, es dabei längst nicht nur um OC oder RAM-OC geht und das sollte auch nicht im Fokus stehen.

Ich darf nochmal an Meltdown/Spectre erinnern, wenn du da ein Board mit EOL hattest warst du gelackmeiert oder konntest die eben selbst behelfen.
Mikrocode-Update über Bootloader ist und bleibt die schlechtere Wahl also:

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

Mittlerweile schon einige Tage her

Das Ding damals mit der Sandy Bridge war nunmal, nicht weit hergeholt aber man muss die Abhängigkeiten nunmal verstehen...
Es wurde mit dem Microcode an sich was rausgeworfen, gegen was ersetzt was dann durch Updates alternative zur Mitigation genutzt werden sollte.
Soweit so gut, ist nur blöde wenn die CPU das "neue" nicht so richtig kann ohne Mikrocode-Update, weil so kostete es nunmal Leistung.
Das Mikrocode-Update per Bootloader, was Linux konnte, bei Windows immernoch nicht wirklich save ist, es angeblich aber kann, war derzeit definitiv nicht der Fall. (Kein Windows Update beinhaltete das offiziell es gab dazu keine KBxxxx...)
Treiber, seitens Nvidia mit entsprechendem Update damit ging es unter anderem los, hattest du nicht den neuen Microcode = Leistungsverlust
Dann gab es zum Teil Updates für Windows die Meltdown/Spectre betrafen, ohne die alternativen durch den Microcode, konnte alte Software aber auch alte Methoden nicht durch die Updates auf die neuen Alternativen Umübersetzt werden (Was an sich theoretisch Leistung hätte kosten sollen/können, praktisch aber nicht der Fall war, wenn Microcode auf dem Stand der Dinge), was ohne Mikrocodeupdate aber eben nunmal schlichtweg nicht möglich war.
Alte Methoden (CPU-Befehle wie MMX nunmal) auf neue Umsetzen die nicht da sind, aber das Programm dennoch irgendwie anständig ausführen, nuja..., kostete Leistung

Der beste Weg ist also, der Microcode muss auf dem Stand der Dinge sein, ab Bios am besten, damit Betriebsysteme die die Mitigations bekommen haben, entsprechend am besten funktionieren können, das ist kurze Rede zum langen Sinn, mit den vielen Abhängigkeiten.

-----------------------------------
Hoffen wir das ein deaktivieren von Secure Boot und dann wieder aktivieren, die Lösung ist.
Das wäre bei diesem Bug, das Beste für alle beteiligten die in diesen Bug nun reinrennen


Gruss Dennis

 

[PCFreak69]

...Secure Boot an sich ist ja nun eine "neue" Systemvorrausetzung,

Laut Microsoft, es funktioniert aber auch ohne Secure Boot einwandfrei, wenn die Secure Boot Keys im Bios gelöscht werden.
Wahrscheinlich werden dann auch die Secure Boot Keys auf dem Windows Laufwerk gelöscht.

Bei mir ist Secure Boot deaktiviert (Bild unten), Windows 11 funktioniert trotzdem einwandfrei.

...dein Tipp mit Secure Boot war nun halt auch nicht so abwegig, Secure Boot also neu eingestellt, praktisch neu aktiviert, könnte das ganze an sich ja nun auch behoben haben.

Hattest du Secure Boot im neuen Bios mit AGESA 1.2.0.7 deaktiviert und die Secure Boot Keys im Bios gelöscht?
Wahrscheinlich nicht, dann haben die Secure Boot Keys auf dem Windows Laufwerk die Probleme verursacht als du eine älteres Bios installiert hast.
Wenn sich das Problem mit dem erneuten aktivieren von Secure Boot im Bios beheben lässt ist doch alles gut.

Edit:
Deinen Thread Titel solltest du umbenennen, der müsste lauten wenn AGESA 1.2.0.7 mit Secure Boot Probleme macht.

 

[Dennis50300]

@PCFreak69
Nice das man den Threadtitel hier einfach ändern kann, das war mal anders

Nun Secure Boot machte die ganze Zeit mit Updates egal ob Windows oder Bios an sich nie Probleme, mit dem neusten Bios seit dem letzten Patchday, da fing das nun an.
Es wird irgendwas bezüglich Secure Boot sein, bezüglich eher dem letzten Patchday mit Windows 10 & 11 als das Bios selbst.

Das war ja auch schon länger vor dem Biosdowngrad das Problem, daher na auch ziemlich sicher eher die Vermutung auf Windows.
Aber ja, vom neueren Bios mit dem auf der Partition vom Beta Bios davor gab es durch die Updates dann wohl diese Probleme.

Jetz kann ich ziemlich save demnächst das Problem bei meinem Dad mit dem Asus Prime lösen, müsste ja nur Secure Boot deaktivieren, hochfahren, neu starten, secure Boot wieder aktivieren, wieder hochfahren und fertig ist die Laube.
Ob es wirklich mitunter durch das Biosupdate kam wird sich dann zeigen wenn es sich so lösen lässt.

Bei meinem Dad hab ich in der Tat nach Neuinstallation von Windows 10 sowie 11, ein Biosupdate gemacht, passt zu demselbigen Fehlerbild wie es bei mir auftaucht.
Also wenn ich es sicher raus habe, wenn es sich so verhält wie es aussieht, dann kann ich den Threadtitel nochmals anpassen und wir können das sogar Verschieben weil es kein Bios/Agesa/Mainboard Problem ist sondern ein Bug mit Windows in den man reingeraten kann.

An und für sich hielt ich aber aus Erfahrung die letzten Jahre UEFI/GPT mit dem ganzen drum und dran aber für mittlerweile ausgereift und auch problemfrei wie zuvor altes Bios/CSM/MBR, aber gut, die letzten Kinderkrankheiten hat es dann wohl doch mal noch. (Linux Distributionen machen dahingehend ja auch keine Probleme mehr, sieht man ja so ein Ubuntu LTS juckts einfach mal garnicht, keine Probleme, hätte man auch dadurch auch eher darauf kommen können...naja)



Gruss Dennis

Beitrag automatisch zusammengeführt: 03.07.2022

Edit:
Deinen Thread Titel solltest du umbenennen, der müsste lauten wenn AGESA 1.2.0.7 mit Secure Boot Probleme macht.

Um es alleine auf die Agesa in spezielle zu beziehen dafür ist mir das bishierhin erstmal noch viel zu pauschal, da sind ja noch genügend andere Baustellen die mit Secure Boot (Abhängigkeiten eben mit dem kompletten Bios sowie auch Grafikkarten Firmware) deswegen hier ein "haken" verursachen können.

Ich denke Secure Boot selbst ist nur ein Symptom durch eine andere Sache, oder mehrere in Kombination, das kann man so mal eben nicht so sagen

Edit:
Es könnte ja genauso gut mit dem fTPM zu tun haben, was zugegebnermaßen dann zumindest ein Teil der Agesa wäre, aber wer weiss was und warum unterschiedliche Hersteller vielleicht sonst noch gemacht haben am Bios was ebenso dafür verantwortlich ist und zu demselbigem Fehlerbild führt
Die Agesa war jetzt halt einfach mal am offensichtlichsten und naheliegendsten, aber direkt darauf festnageln will ich es eher noch nicht

Gruss Dennis

Beitrag automatisch zusammengeführt: 03.07.2022

Zitat beim Asus Prime B450 Plus

PRIME B450-PLUS BIOS 3802
"1. Update AMD AM4 AGESA V2 PI 1.2.0.7.
2. Fix AMD fTPM issue causes random stuttering."

Hm, da wird fTPM halt schon extra aufgeführt, also ob das eine separate Sache vom AGESA wäre
Kann irreführend sein, kann aber auch schon so sein das es eben nicht teil der AGESA ist, oder nur zum Teil der AGESA entspricht.

So ein Bios hat rundherum um den Microcode für die CPU's auch noch jede Menge anderes drin im Code, man kann sich das halt nicht sooo einfach machen