修复 OpenCore 引导 Windows 蓝屏

前言

本文最后更新：2022-6-14

自 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、DSDT、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 文件中不能使用中文进行注释

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

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

修正 ACPI 方法的补充

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

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

通用 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 注入三码」中的 SystemUUID 补充说明部分；
• 改用其它人修改过的 OpenCore ：OpenCore 一直存在一个非官方的 Mod 版本，这个版本的最大特点就是去掉了全局信息注入，也就是本文提到的信息注入带来的所有问题，理论上 Mod 版本都没有，但是原来在 GitHub 上更新的 N.D.K 版本 2020 年就已停更，新的 Mod 版本主要在远景论坛发布和维护。

尾声

这一切问题其实说起来都很简单，不要惧怕困难，多了解多动手，是解决黑苹果各类问题的绝佳方法。