修复 OpenCore 引导 Windows 蓝屏

自 OpenCore 慢慢普及开来以后，笔者时常见到有群友提问为什么使用 OpenCore 引导 Windows 会蓝屏，而直接在 BIOS 中选择 Windows Boot Manager 进行引导又不会？

OpenCore 和 Clover 最大的不同之一是，OC 开发团队 acidanthera 决定在 OpenCore 中的部分设置，SMBIOS 机型信息、DSDT 和 SSDT，都一视同仁地对所有操作系统生效。这样做的目的是让黑苹果更像白苹果，但是却有可能导致在 macOS 上正常可用的 ACPI 表到了其它操作系统上反而出现问题。

换言之，就是注入的信息让 Windows 崩溃了。这些信息共有三个部分，一是部分设置，二是 ACPI 文件（即 DSDT 和 SSDT），三是 SMBIOS ID。

接下来介绍对应的解决办法。

针对 Quirks 设置的修正

这个部分目前仅涉及一项，即 Booter 下的 Quirks 设置中的 SyncRuntimePermissions。

SyncRuntimePermissions 主要功能是修复与 MAT 表的对齐问题，并且需要使用 MAT 表启动 Windows 和 Linux，也推荐用于 macOS。当启用了 RebuildAppleMemoryMap 时，建议一同勾选此项，可解决部分机型引导 Windows 蓝屏问题。

下图是 OpenCore Configurator 的对应位置：

下图是 OCAuxiliaryTools 的对应位置：

下图是 ProperTree 的对应位置：

针对 ACPI 文件的修正

如果使用 OpenCore 引导 Windows 时出现蓝屏，并且明确注明“ACPI_BIOS_ERROR”或“ACPI_ERROR”（如下图），那么十之八九与 OpenCore 注入的 SSDT 文件有关。

修复的方法是编辑 SSDT 文件，可惜的是此方法需要一定的编程基础或理解能力，因此有一定门槛。

ACPI 文件一般以 xxx.dsl 或 xxx.aml 两种文件后缀形式出现，dsl 是源文件，aml 是已编译的文件，OpenCore 或 Clover 等引导工具使用的是后者。它们的编辑工具，macOS 建议使用 MaciASL，Windows 系统可使用 QtiASL。

下面以第十代酷睿 + 400 系主板为例进行演示：

「注意」SSDT 文件的命名并没有统一的强制性要求，文件名也不区分大小写，只要自己明白各个文件的作用就行。因此，上图中的三个文件在你的 EFI 文件夹里也可能被命名成以下几个：

• SSDT-AWAC-disable.aml ：用于关闭系统内置的 AWAC 时钟，因为 macOS 仅支持传统 RTC，用于 H310 及更高更新的主板芯片组
• SSDT-EC-USBX.aml ：这个略微复杂一些。在台式机上，EC（嵌入式控制器）与 AppleACPIEC 驱动程序不兼容，为了解决这个问题，我们需要禁用这个设备，并创建一个假的 EC 设备让 AppleBusPowerController 加载，在高于第六代酷睿的平台上，AppleBusPowerController 还需要一个名为 USBX 设备来为 USB 提供电源属性；而在笔记本机型上，EC 用于提供快捷键功能和电池控制，因此不能直接禁用，所以需要创建一个假的 EC 设备，以满足 macOS 的要求；综上，台式机和笔记本因需求不同，EC 相关的 SSDT 并不通用，注意选择。
• SSDT-PLUG.aml ：用于让 macOS 内核的 XCPM（XNU 的 CPU 电源管理）接管 CPU 的电源管理，有了原生电源管理，你的处理器才能正常睿频或休眠。

下面以修改 SSDT-AWAC.aml 为例：

我们将为它添加系统判断语句（用于判断当前系统是不是 macOS）：

If ( _OSI( "Darwin" ) ) {  // 判断当前系统是否macOS
    xxxx  // 如果是，则此部分内容生效
}  // 结束判断

「注意」上面是因为需要解释，SSDT 文件中不能使用中文进行注释

STAS = One

{ STAS = One }

If (  ) { STAS = One }

If ( _OSI("Darwin") ) { STAS = One }

If ( _OSI("Darwin") )
{
    STAS = One
}

.aml 编辑完成后直接保存文件即可，如果你编辑的是 .dsl 源文件，还需要导出成 .aml 格式，点击左上角 文件 → 另存为 → 文件格式选择 ACPI Machine Language Binary ，举例如下：

其它 SSDT 文件修改方法以此类推，全部修改保存完成后即可尝试引导 Windows 看是否解决了问题。

修正 ACPI 方法的补充

如果上述步骤未能解决你的问题，可继续参考此部分。

在不断的实践中，笔者发现有部分机型的 SSDT 文件在 Method 之后添加系统判断没有作用，需要放到外部表引用之后，例如：

If ( _OSI( "Darwin" ) ) {   // 判断当前系统是否macOS
    xxxx   // 如果是，则此部分内容生效
} else {  // 如果不是macOS
    // 这里空白什么都不要写
}   // 结束判断

通用 SSDT 文件包

标准通用的 SSDT 文件在 OC 发行包中会附带，不知道在哪里找的

SMBIOS 机型问题

通过 OpenCore 引导的 Windows，会将机型修改为 Mac 机型，这时如果通过鲁大师或其它系统检测软件进行检测，会得到类似“Acidanthera iMac20,2 All in one”这种结果，而不是原来的类似“Windows X64 电脑”的结果。

「提示」如果是真正的白苹果，则不会有“Acidanthera”字样，会被“Apple”或者“苹果”替代。

这也是因为 OpenCore 向系统注入了 SMBIOS 机型信息导致的结果。笔者刚开始并不觉得这个特点可能存在什么问题，直到后来遇到一位群友，他的主板是终生质保，在运行厂家配套的系统控制软件时，会显示主板的保修信息，但如果通过 OpenCore 引导，这个信息就无法读取了。

如果这种情况仅仅只影响信息读取和显示，那么另一种情况就是真切影响到了使用。这位倒霉的群友需要使用公司购买的行业专用软件，软件通过加密狗绑定主板信息才能正常开启和运行，所以通过 OpenCore 引导 Windows 后，完全没法使用。

这类情况目前可通过修改 config.plist 方法解决，如下：

• Kernel → Quirks → CustomSMBIOSGuid 勾选/Enabled
• Platforminfo → Generic → SpoofVendor 取消勾选/Disabled
• Platforminfo → UpdateSMBIOSMode → 设置为 Custom

除了以上方法外，其它途径还有几种思路：

• 改用 Clover ：在 OC 团队停止开发 AptioMemoryFix.efi 后，Clover 陷入了一段时间的沉寂，不过，自 r5123 版本开始，Clover 正式集成了 OpenCore 的内核，版本是 0.6.3，在近期升级到 r5142 后，OC 内核更新到了 0.7.5。因此，使用 Clover 引导 Big Sur 或目前的 Monterey 是可行的，Clover 一直以来都不会全局注入信息；
• 尝试使用 Windows 的 System-uuid：部分软件会以系统 uuid 为准进行绑定，因此在 OpenCore 等引导工具指定使用和 Windows 相同的 uuid 或许可以解决上述情况二的问题，使用相同 uuid 可能可以同时解决运行 macOS 后 Windows 激活失效的问题。
• 改用其它人修改过的 OpenCore ：OpenCore 一直存在一个非官方的 Mod 版本，这个版本的最大特点就是去掉了全局信息注入，也就是本文提到的信息注入带来的所有问题，理论上 Mod 版本都没有，但是原来在 GitHub 上更新的 N.D.K 版本 2020 年就已停更，新的 Mod 版本主要在远景论坛发布和维护。