用 WorkBuddy 一条龙修复 Win11 全部 UWP 应用打不开 — VCLibs 依赖损坏排查实录

一句话描述问题，WorkBuddy 自动完成诊断、定位、下载、修复、验证全流程，15 分钟全部搞定

一、故事起因：一句描述，全流程启动

第二天起床打开电脑，点开始菜单里的记事本，弹出来一个莫名其妙的提示：就是下面这个

"无法打开这个应用，查看 Microsoft Store，了解有关 XXX 的详细信息。获取它的帮助"

不仅只是记事本，画图、计算器、Microsoft Store、照片、邮件、终端……全都是同样的错误。双击 .txt 文件也报错。整个微软应用体系全瘫痪了。双击后都是报错

然后我就去网上找教程，找到了一模一样状况的修复教程：win11系统自带应用软件打不开，从开始菜单打开报错无法打开这个应用，下灰色读条不走，打不开记事本、画图、图片、视频、计算器、mail，0x80073CF6，0x800706D9，0x80070422 - 知乎

但是跟着修复教程到最后一步，发现自己电脑注册表一打开数值就是2，这就让我头疼了，上网也找不到其他修复方法了

好吧，那就让AI来修一下吧（因为俺真的不想要重装系统啊(ಥ_ಥ)），这次我使用WorkBuddy来修复，原因是我的Codex不知道是不是这个原因也打不开了。

提示词如下：

我打开电脑后，点开始菜单的系统自带应用，提示“无法打开这个应用，查看Micorsoft Store，了解有关 XXX 的详细信息。获取它的帮助”，系统自带应用软件都打不开，如：记事本、画图、图片、视频、计算器、mail、Microsoft store、powershell（win11叫终端）等，直接开文件也报错，如.txt的文本文档

抱着试试的心理等待了15分钟，没想到真的修好了。所以为了让大家知道这是什么原因导致的，也避免大家后面遇到同样的问题不知道怎么解决，所以把这次修复过程写篇文章。୧(๑•̀⌄•́๑)૭

整个修复过程以及问题所在我让WorkBuddy总结了一下

二、WorkBuddy 的诊断过程

WorkBuddy 直接通过 PowerShell 工具开始自动化排查，全程不需要我手动操作。

2.1 检查关键系统服务

WorkBuddy 第一步就排查了 AppX 相关的核心服务：

Get-Service -Name AppXSvc, LicenseManager, StateRepository, AppReadiness, ClipSVC

服务名	状态	启动类型
AppXSvc	Running	Automatic
LicenseManager	Running	Manual
StateRepository	Running	Automatic
AppReadiness	Stopped	Manual
ClipSVC	Stopped	Manual

✅ 核心服务都在运行，问题不在服务层面。WorkBuddy 迅速排除了这个方向，继续下一步。

2.2 检查 Appx 包状态 — 定位根因

WorkBuddy 用 Get-AppxPackage 检查记事本和 Microsoft Store 的包状态：

Get-AppxPackage -Name 'Microsoft.WindowsNotepad', 'Microsoft.WindowsStore' |
    Select-Object Name, Version, Status

输出：

Name                     Version               Status
----                     -------               ------
Microsoft.WindowsNotepad 11.2605.34.0           DependencyIssue
Microsoft.WindowsStore   22606.1401.6.0        DependencyIssue

2.3 追踪依赖链 — 找到罪魁祸首

WorkBuddy 没有停在这里，而是继续深挖记事本的依赖包：

$pkg = Get-AppxPackage -Name 'Microsoft.WindowsNotepad'
$pkg.Dependencies | Select-Object Name, Version, Status

依赖包名	版本	状态
Microsoft.WindowsAppRuntime.2	2.3.1.0	Ok
Microsoft.VCLibs.140.00	14.0.33519.0	Modified, NeedsRemediation
Microsoft.VCLibs.140.00.UWPDesktop	14.0.33728.0	Ok

🎯 根因定位
Microsoft.VCLibs.140.00（x64）的包状态为 Modified, NeedsRemediation，意为"已被修改，需要修复"。这个包是 Visual C++ 运行时库的 UWP 版本，几乎所有 UWP 应用都依赖它。一旦它损坏，所有依赖它的应用都会报 DependencyIssue。

2.4 全面排查 — 损坏范围

WorkBuddy 自动列出了所有状态异常的包：

Get-AppxPackage | Where-Object { $_.Status -ne 'Ok' } |
    Select-Object Name, Status | Sort-Object Status

结果发现 40 个应用包都受影响，全部是 DependencyIssue，外加 1 个 Modified, NeedsRemediation（VCLibs 本身）：

记事本、画图、计算器、照片、Microsoft Store、邮件

时钟、相机、录屏、便签、Solitaire、Clipchamp

Xbox 相关组件、Bing 系列应用、DesktopAppInstaller……

几乎覆盖了所有 UWP 应用。而罪魁祸首只有一个：Microsoft.VCLibs.140.00（x64 架构版本）。

三、WorkBuddy 的修复过程

找到根因后，WorkBuddy 开始尝试修复——同样是全自动的，我只需要在旁边看着。

3.1 第一次尝试：重新注册 VCLibs 包（失败）

WorkBuddy 先用最直接的方式——Add-AppxPackage -Register 重新注册：

Add-AppxPackage -DisableDevelopmentMode -Register `
    "C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe\AppxManifest.xml"

命令执行成功，但 WorkBuddy 主动验证状态后发现——仍然是 Modified, NeedsRemediation。

💡 WorkBuddy 的分析：为什么重新注册无效？
重新注册只是告诉 Windows "重新加载这个包的清单文件"，但包的文件本身已经损坏或被修改过了。重新注册读取的仍然是那些坏文件，所以状态不会改变。要修复这个问题，必须用全新且完整的包文件来覆盖损坏的文件。

3.2 第二次尝试：加 Force 参数重新注册（仍失败）

WorkBuddy 没有放弃，换了一套参数重试：

Add-AppxPackage -DisableDevelopmentMode -Register $manifestPath `
    -ForceApplicationShutdown -ForceUpdateFromAnyVersion

结果：命令成功，但状态依然不变。根因是文件本身被修改，重新注册无法修复文件内容。

3.3 第三次尝试：WorkBuddy 自动搜索方案 → 下载全新包 → 安装（成功 ✅）

这里是 WorkBuddy 最精彩的部分——它意识到本地文件已损坏后，自主决策从微软服务器下载全新包来覆盖。

Step 1：联网搜索解决方案

WorkBuddy 先用 WebSearch 搜索了相关资料，找到了戴尔支持文章描述的同类问题，确认了"下载全新包覆盖安装"的修复思路。

Step 2：获取下载链接

VCLibs UWP 包不像 Desktop 版有 aka.ms 短链接，WorkBuddy 自动通过 store.rg-adguard.net API 获取微软 CDN 直链：

$body = "type=PackageFamilyName&url=Microsoft.VCLibs.140.00_8wekyb3d8bbwe&ring=Retail"
$headers = @{
    "Content-Type" = "application/x-www-form-urlencoded"
    "Referer"      = "https://store.rg-adguard.net/"
    "Origin"       = "https://store.rg-adguard.net"
    "User-Agent"   = "Mozilla/5.0"
}

$ProgressPreference = 'SilentlyContinue'
$response = Invoke-WebRequest -Uri "https://store.rg-adguard.net/api/GetFiles" `
    -Method Post -Body $body -Headers $headers -UseBasicParsing

API 返回的 HTML 中包含多个架构的下载链接，WorkBuddy 用正则提取出 x64 版本：

Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe.appx
→ http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/...

Step 3：下载并安装

# 下载全新的 VCLibs UWP x64 包（约 876 KB）
Invoke-WebRequest -Uri $downloadUrl -OutFile "VCLibs.UWP.x64.appx" -UseBasicParsing

# 覆盖安装，替换损坏的文件
Add-AppxPackage -Path "VCLibs.UWP.x64.appx" `
    -ForceApplicationShutdown -ForceUpdateFromAnyVersion

安装过程出现了部署进度条，最终——SUCCESS！

Step 4：自动验证修复效果

WorkBuddy 没有让我自己去试，而是主动跑了一遍验证：

# 检查 VCLibs 状态
Get-AppxPackage -Name 'Microsoft.VCLibs.140.00' |
    Where-Object { $_.Architecture -eq 'X64' } |
    Select-Object Name, Status

# 检查所有应用的状态
Get-AppxPackage | Where-Object { $_.Status -ne 'Ok' } |
    Select-Object Name, Status

结果：

应用	修复前	修复后
Microsoft.VCLibs.140.00 (x64)	❌ Modified, NeedsRemediation	✅ Ok
Microsoft.WindowsNotepad	❌ DependencyIssue	✅ Ok
Microsoft.WindowsCalculator	❌ DependencyIssue	✅ Ok
Microsoft.WindowsStore	❌ DependencyIssue	✅ Ok
Microsoft.Paint	❌ DependencyIssue	✅ Ok
Microsoft.Windows.Photos	❌ DependencyIssue	✅ Ok

✅ 全部修复
修复后 WorkBuddy 检查了全部 193 个应用包，状态均为 Ok。没有任何一个包还处于异常状态。所有系统自带应用恢复正常。

Step 5：自动清理临时文件

修复完成后，WorkBuddy 还自动清理了诊断过程中产生的临时文件（下载的 .appx 包、各种诊断输出 txt 等），没有留下任何垃圾。

这次排查的核心思路：当所有应用同时出问题时，不要逐个排查应用，而应该先检查共享的依赖框架包。UWP 应用的框架包就像是地基——地基裂了，上面的楼都会跟着出问题。找到并修好地基，所有问题迎刃而解。

而 WorkBuddy 做的事，就是把"找到地基 → 发现裂缝 → 找到新材料 → 修补 → 验证"这个完整链条自动化了。你只需要说一句"楼歪了"，它就能帮你查出是地基的问题，然后修好它。

用 WorkBuddy 一条龙修复 Win11 全部 UWP 应用打不开 — VCLibs 依赖损坏排查实录

一、故事起因：一句描述，全流程启动

二、WorkBuddy 的诊断过程

2.1 检查关键系统服务

2.2 检查 Appx 包状态 — 定位根因

2.3 追踪依赖链 — 找到罪魁祸首

2.4 全面排查 — 损坏范围

三、WorkBuddy 的修复过程

3.1 第一次尝试：重新注册 VCLibs 包（失败）

3.2 第二次尝试：加 Force 参数重新注册（仍失败）

3.3 第三次尝试：WorkBuddy 自动搜索方案 → 下载全新包 → 安装（成功 ✅）

Step 1：联网搜索解决方案

Step 2：获取下载链接

Step 3：下载并安装

Step 4：自动验证修复效果

Step 5：自动清理临时文件

用 WorkBuddy 一条龙修复 Win11 全部 UWP 应用打不开 — VCLibs 依赖损坏排查实录

评论交流