HOWTO: 解决 Windows Insider 0x800BFA0E 错误
HOWTO: 解决 Windows Insider 0x800BFA0E 错误
好久没有分享关于排错的日志，今天简单分享一个最近遇到的 Windows Insider 0x800BFA0E 错误，该错误代码是 Windows Insider Program 专有的，而且官方没有披露相关代码的含义，在 Windows Insider Troubleshooting 中也没有找到任何线索，那我们该如何着手去排错呢？！
回顾该设备的历史情况，已加入到 Intune，使用 M365 账号的登录，先前可见 Windows 预览体验计划是被预先配置的，因为用户无法更改。转到 Intune 管理中心排查设备策略，初步怀疑与更新策略有关。
检查默认的更新策略，发现“启用预发布的内部版本”为未配置，查询 Intune 审核日志可见该策略之前有被重新修改，经确认该配置之前未启用状态，且发布频道设定为“Windows 预览体验计划 - 发布预览”，之后因某些设备要更改发布频道，则在 Intune 上变更了该策略以允许用户自行配置，之后该策略设置在设备端被取消，用户可自主控制 Windows Insider 频道，在加入过程中便于到了前面截图中的 0x800BFA0E 错误。
综上所述，问题应该发生在策略设置取消后，之前的配置信息残留在了某个位置。Windows 上重要的配置存储就是注册表了，当然也可能保存在某些文件中，比较繁琐的排查方法是检索那些关键词，例如先从微软官方文档中了解到发布频道的信息 - Deeper look at flighting，然后逐步去排查可疑信息的位置。
如果你也能够非常熟练使用 Sysinternals，那将变得非常容易。哦！说到这里我需要特别致敬一下我非常敬重的一个技术超群的殿堂级大佬 - Mark Russionovich，有幸在 2011 年亚特兰大见过一面，还拿到了亲笔签名的 Zero Day: A Novel！
炫完回归正题，经排查确认 Windows Insider 相关信息仅保存在注册表中，项值“WindowsSelfHost”，位于“HKLM\SOFTWARE\Microsoft”，如果你有兴趣可以逐一查阅其中的信息，那么下来要解决我们当前遇到的问题只需要删除 WindowsSelfHost 项即可，可以使用命令行，或者使用注册表编辑器，随你的喜好！
reg delete "HKLM\SOFTWARE\Microsoft\WindowsSelfHost" /f
最后重新启动设备便可手动重新注册并选择发布频道！
HOWTO: 升级 Secure Boot 证书解决2026年到期问题
HOWTO: 升级 Secure Boot 证书解决2026年到期问题
在开始我们今天的话题前应该先了解一下 Secure Boot（安全启动），它是基于 UEFI 提供的一项安全功能，确保设备加电启动后仅能够从受信任的程序执行启动。这是保护操作系统的第一步，它的工作原理十分容易理解，在设备 UEFI 中预置了受信证书，当我们的设备要执行启动的程序包含匹配的受信证书，则设备会继续执行启动，否则失败！
安全启动在 Windows 上通过其内核的受信任启动序列从 UEFI 创建安全可信的启动路径，其示意如下，这一过程首先验证固件是否已进行数字签名，从而降低固件 rootkit 的风险。然后，安全启动会检查操作系统之前运行的代码，并检查启动加载程序的数字签名。
Secure Boot 最初是在 Windows 8 总引入的，直至今日的 Windows 11。早前微软已公布相关的启动证书将于2026年过期，参考如下：
Microsoft Corporation KEK CA 2011，2026年6月到期，KEK，对 DB 和 DBX 进行签名更新，更新后：Microsoft Corporation KEK 2K CA 2023。
Microsoft Windows Production PCA 2011，2026年10月到期，DB，用于对 Windows 引导加载程序进行签名，更新后：Windows UEFI CA 2023。
Microsoft UEFI CA 2011，2026年6月到期，DB，对第三方引导加载程序和 EFI 应用程序进行签名，更新后：Microsoft UEFI CA 2023。
Microsoft UEFI CA 2011，2026年6月到期，DB，签署第三方选项 ROM，更新后：Microsoft Option ROM UEFI CA 2023。
如果你或你所管理的组织设备已启用 Secure Boot，则需要重点进行设备信息的调查汇总并指定响应的更新计划并着手开始实施。因为当这些 CA 过期后，系统将停止接收 Windows 启动管理器和安全启动组件的安全修补程序，并影响 Windows 设备的整体安全性。
首先，我们需要确认设备是否启用了 Secure Boot，可以通过 msinfo32 查看，或使用 PowerShell 命令：Confirm-SecureBootUEFI。
然后，联系或检查设备 OEM 供应商是否提供了对应的 UEFI 更新固件，根据说明进行操作。
更新固件后，可以通过检查以下注册表键值来进行确认是否应用了 Windows UEFI CA 2023 签名启动管理器。
“HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing”，UEFICA2023Status 值为 Updated 时表示已完成并应用更新。否则我们需要借助 OEM 的 UEFI 更新程序或微软提供的方案执行。
我们也可以在 PowerShell 中执行以下命令，进行 Windows UEFI CA 2023 的检查。
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
当然，启动设备进入 UEFI 界面也是一个非常直接的方法。
是的，你没有看错前面的描述，微软也提供了更新 UEFI 固件证书的方法，但如果不适用当前设备，则需要由 OEM 提供支持。我们可以参考以下几种方案：
1. 安装 Windows Update，这是最简单有效的办法！注意：根据微软 KB5036210 的说明，从 2024年 2月 13日及之后发布的 Windows 更新包含了 Windows UEFI CA 2023 证书应用于 UEFI 安全启动允许签名数据库（DB）。
2. 对于组织用户，同理在满足基本系统版本需求的前提下，可以通过注册表、GPO 和 WinCS 的方式立刻开始更新。对于注册表，运行以下命令行。
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”
第一条命令将启动证书和启动管理器部署，第二条会立刻运行 AvailableUpdates 所对应的计划任务，否则需等待每 12小时运行一次。当重启设备后其键值变为 0x4100 后，可在执行上面的任务计划，触发启动管理器更新。整个过程 IT 人员都可以通过检查 UEFICA2023Status 和 UEFICA2023Error 注册表键值或 DB 和 DBX 事件（ID 1801，1808）进行跟踪。
3. 如果计划使用 GPO，可配置 计算机配置 - 管理模板 - Windows 组件 - Secure Boot，如下图所示。
4. 我们也可以使用 WinCS API 进行更新操作，执行下面的命令行可先进行查询。
WinCsFlags.exe /query --key F33E0C8E002，如下图所示如当前配置为 F33E0C8E001，则未应用新的证书。
执行下面的命令行以应用新证书。
WinCsFlags.exe /apply –-key “F33E0C8E002
注意：通过运行 WinCS 响应的命令并不意味着安全启动证书安装过程已启动或已完成，它仅指示对应的计划任务准备运行，我们也可以手动触发该计划任务，之后重启设备两次以确认正在使用更新的证书。
目前主要的设备 OEM 厂商（Lenovo、HP、Dell 等）都已经提供了更新支持。如果你所在的组织正面临该问题，可与 gOxiA 联系。
HOWTO: 设置 Windows IoT 设备以实现 Soft Real-Time
HOWTO: 设置 Windows IoT 设备以实现 Soft Real-Time
今天 gOxiA 要分享是如何设置 Windows IoT 设备以实现 Soft Real-Time，在开始前我们需要先了解一下什么是 Real-Time！这里的 Real-Time 通常是指实时操作系统，运行在其中的程序执行结果和获得这些结果所花费的时间是确定的，而我们平常使用的操作系统在运行程序时只会给出确定性的结果，但允许有不确定的时间来完成任务。实时操作系统有硬实时和软实时两种，前者是可以确定到确切时刻的系统，如汽车发动机或飞机内的微型控制器、打印机、激光切割机等。而后者如其名会有一些操作系统的抖动，虽然程序完成的时间窗口很小但仍不是精确的时刻，其精度较低，但可以在多核上运行并对应用程序施加较少的限制。此外，实时性能不代表更快的性能，只是可预测的性能，如果我们的应用场景有实际的限制，例如必须在机器人环境改变之前执行的计算或必须在传送带移动之前激活的电机，那么软实时可能就是我们所需要的。
从 Windows 10 IoT Enterprise 21H2 开始支持 Soft Real-Time，通过以下四个关键设置引入：
- CPU 隔离：将系统级干扰从隔离的 CPU 迁移出去，减少对用户实时应用程序的潜在抖动
- 自定义 ISR (Interrupt Service Routine - 硬件中断发生时立即执行)/DPC (Deferred Procedure Call - ISR 结束后由系统调度执行)在独立实时 CPU 上高度绑定执行：所有硬件中断都路由到系统和非实时内核，但通过编写自定义 ISR/DPC 驱动程序，可将设备特定的中断路由到实时内核。
- 互斥体的优先级继承：通过启用优先级继承，系统在检测到高优先级线程等待低优先级线程持有的互斥体时，会自动调整线程优先级，从而保持任务调度的实时性与确定性。
- 最多16个RT线程优先级别：通过提供16个可配置的实时线程优先级级别，系统允许开发者根据任务的重要性分配资源，以实现对执行顺序的精确控制。
接下来 gOxiA 将在 Windows 11 IoT Enterprise 24H2 上配置以实现 Soft Real-Time：
- 禁用空闲状态
- powercfg.exe /setacvalueindex SCHEME_CURRENT SUB_PROCESSOR IdleDisable 1
- powercfg.exe /setactive SCHEME_CURRENT
- 禁用服务
- sc config dps start=disabled
- sc config audiosrv start=disabled
- sc config sysmain start=disabled
- 禁用 Windows 更新
- sc config wuauserv start=disabled
- 禁用线程 DPC
- reg add "HKLM\System\CurrentControlSet\Control\Session Manager\kernel" /v ThreadDpcEnable /t REG_DWORD /f /d 0
- 设置 Windows IoT CSP 以实现实时性能
- 以 SYSTEM 权限执行以下脚本：
$nameSpaceName="root\cimv2\mdm\dmmap"
$className="MDM_WindowsIoT_SoftRealTimeProperties01"
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
Add-Type -AssemblyName System.Web
Set-CimInstance -CimInstance $obj
$obj.SetRTCores = 3
Set-CimInstance -CimInstance $obj
在这个配置中，我们将在一个 4 核 CPU 上保留 3 个内核（3、2、1）用于实时任务，并将内核 0 留给系统和非实时任务。注意：系统会从编号最高的核心开始分配实时用途，然后依次向下，但是无法保证实时核心始终位于最高编号，其不会自动调整。
视频Demo：https://weibo.com/tv/show/1034:5223802787790893?from=old_pc_videoshow
