昨天打完游戏，突然发现 Windows 的开始菜单打不开了。
一开始我还以为是卡了，毕竟 Windows 偶尔抽一下也不是啥新鲜事。结果重启资源管理器没用，重启电脑也没用；更离谱的是，输入法候选框也不出来了。开始菜单坏了还能忍，输入法坏了就很难忍了，尤其是这个问题不是“某个软件打不开”，而是系统自己的 Shell 组件开始集体发癫。
最后是用 Codex 一步步排查，确认不是 Clash 代理，不是单纯用户配置损坏，也不是单靠 DISM/SFC 能修好的系统文件问题，而是 Windows XAML 相关组件链和系统更新状态不一致。真正解决问题的是安装 Microsoft 的 KB5095093 累积更新，并重启。
整个过程看完之后我真有一种感觉：以后连修电脑都可以让 Agent 先上了，至少比我自己在网上搜一堆“开始菜单打不开怎么办”然后挨个玄学尝试要靠谱得多。
现象看起来很玄学，日志其实很直接
用户侧看到的东西很简单：开始菜单无法打开，输入法候选/输入界面无法正常显示，点击开始菜单或者触发输入面板之后没有正常 UI 反馈。这样的描述放到搜索引擎里，大概能搜出一大堆互相复制的解决方案：重启资源管理器、重注册开始菜单、DISM、SFC、创建新用户，实在不行就重装系统。不能说完全没用，但这种问题最怕的就是上来一通乱修，最后把问题修得更复杂。
Codex 先看的不是网上教程，而是系统日志。这里最明显的异常是，StartMenuExperienceHost.exe、TextInputHost.exe、ShellExperienceHost.exe 这些进程都不稳定，而且崩溃时集中指向同一个模块：
C:\Windows\System32\Windows.UI.Xaml.dll
典型错误长这样：
Faulting application name: StartMenuExperienceHost.exe
Faulting module name: Windows.UI.Xaml.dll
Exception code: 0xc0000409
以及：
Faulting application name: TextInputHost.exe
Faulting module name: Windows.UI.Xaml.dll
Exception code: 0xc0000409
看到这里其实就有点意思了。开始菜单坏了，输入法也坏了，Shell 体验宿主也崩，而且都崩在同一个 Windows.UI.Xaml.dll 上，那就不像是某一个应用自己的配置坏了。更合理的猜测是：这些东西共同依赖的 XAML 组件链出问题了。
常规修复也试了，但没有把问题真正解决
一开始还是走了一遍常规路线。比如看相关进程还在不在，看最近几小时的 Application 日志，看开始菜单、Shell、CBS 这些 AppX 包状态：
Get-Process explorer,ctfmon,StartMenuExperienceHost,ShellExperienceHost,TextInputHost,SearchHost -ErrorAction SilentlyContinue
Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-3)}
Get-AppxPackage -Name Microsoft.Windows.StartMenuExperienceHost,Microsoft.Windows.ShellExperienceHost,MicrosoftWindows.Client.CBS
当时 explorer.exe 和 ctfmon.exe 都在，但是 StartMenuExperienceHost.exe、ShellExperienceHost.exe、TextInputHost.exe 不稳定或者缺失。于是也尝试了普通用户级的 Shell 修复，比如重启 explorer.exe、启动 ctfmon.exe、重注册开始菜单和 Shell 相关包。为了避免越修越坏，Codex 还先备份了相关用户态包目录，这点我觉得很重要，因为 Windows 这种问题一旦开始手动删配置，真的很容易删着删着就回不去了。
结果是：没解决。
后面又跑了 DISM /RestoreHealth 和 sfc /scannow。这一步也不是完全没有意义，SFC 确实修复了一些系统文件损坏，至少把系统基线拉回了一个更干净的状态。但重启之后，开始菜单和输入法依然没有恢复。也就是说，系统文件检查有用，但它不是这次问题的最终解。
问题卡在 AppX 和 XAML 这一层
真正开始接近根因，是管理员级 AppX 诊断之后。这里出现了几个比较扎眼的状态：
MicrosoftWindows.Client.WebExperience_526.11701.50.0_x64__cw5n1h2txyewy
Status: Modified, NeedsRemediation
以及：
Microsoft.WindowsNotepad_11.2604.5.0_x64__8wekyb3d8bbwe
Status: Modified, DependencyIssue, NeedsRemediation
AppXDeploymentServer 日志里也有这些错误：
0x80073CF6
0xD0000001
windows.activatableClass.inProcessServer
更有意思的是，后面做定向 AppX 重注册的时候，结果分成了两类。开始菜单、Shell、CBS、输入相关包可以重注册成功：
OK: Microsoft.Windows.StartMenuExperienceHost
OK: Microsoft.Windows.ShellExperienceHost
OK: MicrosoftWindows.Client.CBS
OK: MicrosoftWindows.61869836.InpApp
但是 XAML、Windows App Runtime、WebExperience 这些依赖包失败：
FAILED: Microsoft.UI.Xaml.2.8
FAILED: Microsoft.WindowsAppRuntime.2
FAILED: MicrosoftWindows.Client.WebExperience
失败原因仍然是：
HRESULT: 0x80073CF6
0xD0000001: 系统无法注册 windows.activatableClass.inProcessServer 扩展
这一步基本把方向带出来了：开始菜单包本体不是唯一问题，甚至可能不是根因。你把开始菜单包重注册了，它也能成功，但依赖它的 XAML/AppX/Windows App Runtime 链条不正常。所以这就不是“把开始菜单修一下”这么简单。
Clash 很可疑，但这次不是它
中间还检查到了代理配置：
HKCU proxy: 127.0.0.1:7897
WinHTTP proxy: direct
如果只看表面，很容易怀疑是不是 Clash 之类的代理影响了 Windows Update 或系统组件。说实话，我自己一开始也会很自然地怀疑它，毕竟 Windows 上代理相关的问题有时候确实很烦。但这次证据不支持这个判断：核心崩溃发生在本地系统组件 Windows.UI.Xaml.dll；DISM /RestoreHealth 在 WinHTTP direct 状态下成功跑完；最后安装 Microsoft 更新包后问题恢复，而整个过程没有修改 Clash 代理配置。
所以 Clash 最多可能影响联网下载或者 Windows Update 检测，不是这次开始菜单和输入法崩溃的根因。这一点其实挺重要的，因为人手动排障的时候很容易被“我最近动过什么”带偏，最后在一个看起来有关系、其实解释不了现象的方向上浪费半天。
最后还是 Windows 自己的更新修掉了
修复前，系统状态大致是：
CurrentBuild=26200
UBR=8655
已安装：KB5094126
Windows.UI.Xaml.dll = 10.0.26100.8521
修复后变成：
CurrentBuild=26200
UBR=8737
已安装：KB5095093、KB5095182
Windows.UI.Xaml.dll = 10.0.26100.8737
真正生效的动作，是安装 Microsoft Update Catalog 里的 KB5095093：
2026-06 Cumulative Update Preview for Windows 11, version 25H2 for x64-based Systems (KB5095093)
安装时 KB5095093 返回 3010，也就是安装成功但需要重启。重启之后，StartMenuExperienceHost.exe、TextInputHost.exe、SearchHost.exe、explorer.exe、ctfmon.exe 都能正常运行，Application 日志里也没有再出现新的 StartMenuExperienceHost.exe / TextInputHost.exe / ShellExperienceHost.exe 的 Windows.UI.Xaml.dll 崩溃。微软自己也有一篇说明高度吻合这个问题：KB5072911: Explorer, the Start menu, and other XAML-dependent apps might not start or close unexpectedly on some enterprise devices。
这基本就把证据链闭合了：修复前是 26200.8655 / Windows.UI.Xaml.dll 10.0.26100.8521，开始菜单和输入法相关进程在 XAML 初始化阶段崩溃；安装并重启到 KB5095093 / 26200.8737 / Windows.UI.Xaml.dll 10.0.26100.8737 后恢复。
Codex 真正有用的地方
这次并不是“AI 神奇地知道答案”。如果只看最后的结果，那确实就是“装个更新，重启，修好了”，听起来平平无奇。但真正麻烦的是，在你不知道该装哪个更新、不知道是不是用户配置坏了、不知道是不是代理、不知道是不是 AppX 包炸了的时候，怎么不把系统越修越坏。
Codex 这次最有用的地方，是它把排障顺序管住了。它没有一上来就让我重装系统，也没有让我满世界下载来路不明的修复工具，而是按证据一步步走：先看进程，再看事件日志，再看 AppX 状态，再做用户级修复，再做系统基线修复，再做管理员级诊断，最后才定位到系统更新层。
更重要的是，它能把每一步操作留下日志。哪些包重注册成功，哪些包失败；DISM 和 SFC 的退出码是什么；更新安装返回码是什么；修复前后的 Windows.UI.Xaml.dll 版本是什么。这些东西单独看可能都不难，但人自己排障的时候很容易做着做着就乱了，尤其是 Windows 这种问题，一旦开始“玄学修复”，就很容易陷入“我也不知道刚才到底改了啥”的状态。
这就是我觉得 Codex 这种 coding agent 很适合修电脑的原因。修电脑本质上也很像调试一个屎山项目：现象很乱，依赖很多，日志分散，网上答案一堆，而且其中不少还是复制粘贴的玄学偏方。人真正需要的不是“凭空猜一个答案”，而是一个能把线索收集起来、把步骤排好、把风险控制住的执行者。
一点感想
这次故障不是 Clash 代理导致，也不是单纯用户配置损坏。根因最符合 Microsoft 已知的 XAML-dependent apps 更新问题：系统停在 26200.8655 / Windows.UI.Xaml.dll 10.0.26100.8521 时，开始菜单和输入法相关进程在 XAML 初始化阶段崩溃；安装并重启到 KB5095093 / 26200.8737 / Windows.UI.Xaml.dll 10.0.26100.8737 后恢复。
但是这篇文章真正想记的不是这个 KB，而是这个过程本身。以前我遇到这种问题，要么自己慢慢翻日志，要么上网搜一堆半真半假的方案，要么最后烦了直接重装。现在至少多了一种选择：让 Codex 先把问题按工程方式拆开，把能验证的东西验证掉，把不能解释现象的猜测排除掉，最后再动真正有风险的操作。
所以说到底，AI 不一定要“神谕式”地告诉你答案才有用。很多时候，它只要能老老实实地查日志、做记录、对照证据、谨慎执行，就已经很有用了。修电脑如此，写代码如此，很多乱七八糟的工程问题也是如此。
以后 Windows 再发病，先让 Agent 看看吧。