Open Core Windows Blue Screen

Hab dazu auch schon einen Thread eröffnet. Bisher ohne Antwort. In den Opencore Troubleshoots steht was vom Eintrag "SyncRuntimepermissions" aktivieren bzw deaktivieren. So richtig Abhilfe schaft das nicht

Hast du die SSDTs / DSDTs so erstellt, dass die nur bei MacOS geladen werden?

Mir fällt gerade auf, du hast sehr viele unnütze Treiber in deiner EFI.

Hab nur Openruntime, HFSPlus, ExFatDxe und PartitionDxe drin und innerhalb des Opencore sowie booten funktioniert ohne Probleme. Z.B. ApfsDriverLoader brauchst du seit Version 0.58 nicht mehr. Wenn du NullCPUPowerManagement aus den Kext-Ordner rausnimmst sollte auch Speedstep der CPU funktionieren, sonst läuft sie durchgehend mit dem höchsten Takt. AppleALC.kext anstatt VoodooHDA nehmen. Klingt auch schöner. Musst natürlich dann auch die Einträge in der config.plist anpassen

https://dortania.github.io/Ope…esktop-Guide/AMD/zen.html

Grundsätzlich übernimmt OpenCore alle Änderungen die an den ACPI Tabellen vorgenommen werden für alle Betriebssysteme die über OpenCore gestartet werden und damit ist eigentlich schon die Erklärung für den BlueScreen von Windows gefunden. Viele Tutorials, die so im Netz rumschwirren, sind leider oftmals ein gutes Beispiel dafür wie man ACPI Patches nicht macht. Schaut man mal in Deinen EFI Ordner finden sich dort zwei ACPI Dateien einmal eine DSDT.aml und eine SSDT-EC0.aml bei der DSDT kann ich natürlich nicht sagen was daran verändert wurde hier kenne ich das Original nicht daher lassen wir die mal außen vor (vermutlich wird sie eh nicht gebraucht) aber anhand der SSDT-EC0.aml kann man schön aufzeigen wie man so etwas so gestalten kann das es sich nur auf macOS auswirkt und alle anderen Betriebssysteme ignoriert, was es im vorliegenden Fall auch tut. Die von Dir eingesetzte Version sieht wie folgt aus:

auffällig dabei ist der folgende Block:

Die IF Bedingung unterscheidet in dem Fall ob das Betriebssystem macOS (Darwin) ist oder nicht und im Falle von macOS gibt die Methode den Wert NULL zurück andernfalls den Wert 0x0F wobei der "andernfalls" Wert dem entspricht was auch zurückgegeben würde wenn es die SSDT nicht geben würde. Das Beispiel zeigt wie man ACPI Patches so anfertigt das sie sich nur auf ein bestimmtes Betriebssystem auswirken. Wie wir sehen entspricht die SSDT-EC0.aml den notwendigen Standards und kann daher nicht der Grund für den ACPI Fehler sein den Windows anmeckert. Das Problem ist also irgendwo in der DSDT zu suchen und hier ist es leider nahezu unmöglich einen Diagnose zu stellen ohne die originale DSDT zu kennen. Wie auch immer ich würde an Deiner Stelle die DSDT erstmal aus dem Rennen nehmen und gucken ob Windows damit zufrieden ist und falls das der Fall ist (ich gehe davon aus) dann würde ich im nächsten Step gucken ob auch macOS ohne die DSDT auskommt und wenn auch das der Fall sein sollte (ehrlich gesagt gehe ich auch davon aus) dann kannst Du Dich langsam ran tasten und ausprobieren was unter macOS mit der DSDT funktioniert hat und ohne nicht mehr und gezielt diese Dinge adressieren. Heute braucht man eigentlich so gut wie gar nicht mehr an der DSDT rum schrauben weil vieles von dem was man da mal geregelt hat sich viel eleganter anderweitig regeln lässt (Stichwort IOREG bzw. Lilu.kext und Co.)...

Wenn das eine PCIe-Karte mit USB-Kabel ist, wähle doch einen anderen USB-Port, der noch funzt.

Windows sollte nicht über OC gestartet werden, OC ist ein loader für Hackintosh

und alles was der " ändert " ist nicht gut für windows.

Auch wenn OC jetzt die Möglichkeit bietet Einstellungen für OSx und Win zu separieren

ist OC nicht wirklich als Bootmanager zu gebrauchen.

entweder über BIOS/ UEFI ( F2/ F12 oder was euer Board erfordert ) zum Bootauswahl

oder Grub verwenden.

Clover funktionier auch nur als Bootmanager eingesetzt , mann kann damit auch OC starten