安装与迁移 · Clash 技术博客

FlClash 0.8.96 打不开怎么修？

FlClash 0.8.96 无法启动？按 MSVCP140.dll、VCRUNTIME140.dll 缺失或 DesktopCoreFailure 分流排查。

阅读正文返回博客
  • FlClash
  • Windows 11
  • MSVCP140.dll
  • DesktopCoreFailure
  • Smart App Control
本文目录
文章作者
Clash官网
发布日期
预计阅读
约 9 分钟

先按报错把启动失败分成两类

本文处理 Windows 上 FlClash 0.8.96 安装后完全打不开的两种近期报告。第一种会直接弹出 MSVCP140.dll 或 VCRUNTIME140.dll 缺失；报告原文还写有 VCRUNTIME_1.dll，具体文件名需以本机弹窗为准。

第二种能打开界面，但核心启动失败并显示 DesktopCoreFailure。两者看起来都像安装坏了，实际排查路径不同。

官方 issue #2370 记录了 Windows 11 25H2 安装 v0.8.96 后的 DLL 弹窗；issue #2367 则记录了 Smart App Control 拦截核心，以及 Code Integrity 事件 3077、3089。

两份报告截至本文发布仍未得到维护者确认。本文只把它们作为症状证据，不把 v0.8.96 写成已经确认存在同一个安装缺陷。

如果 FlClash 已经启动、只是节点 Timeout、TUN 断网或订阅失败，不属于本文范围。不要在没有 DLL 弹窗或 Code Integrity 证据时同时安装运行库、关闭安全功能和重装客户端。

用第一条错误选择分支

第一条可见错误更可能的阶段先做什么
MSVCP140.dll / VCRUNTIME140.dll 缺失应用依赖的 MSVC v14 运行库不可用核对架构并修复微软官方运行库
DesktopCoreFailure，事件 3077 / 3089Smart App Control 的 Code Integrity 判定保留事件证据，不先改 Defender 排除项
只有节点 Timeout 或 DNS 错误核心已启动后的网络阶段转到连接与测速排查
安装程序本身打不开下载、架构或 Windows 安全拦截重新核对官方安装包与文件来源

先记录版本、架构和原始错误

先关闭反复弹出的 FlClash，不要连续覆盖安装。记录 Windows 版本、系统类型、FlClash 安装包文件名、第一条弹窗或 DesktopCoreFailure 截图。v0.8.96 官方 Release 同时提供 Windows amd64 与 arm64 安装包和压缩包，文件名可以帮助确认这次实际装了哪一种。

若此前打开过系统代理或 TUN，先在 Windows 网络设置中关闭系统代理，并确认普通网页可以直连。客户端无法启动时继续保留本地代理开关，会把启动故障和整机断网混在一起。不要删除 Profile、订阅或应用数据目录；这两条排查路径都不需要先清空用户配置。

保存一组可回退信息

  1. 记录安装包文件名

    确认是 windows-amd64 还是 windows-arm64，不用“64 位”代替具体架构。

  2. 保存第一条错误

    DLL 名称要完整；DesktopCoreFailure 要保留出现时间，方便查对应事件。

  3. 恢复系统直连

    关闭 FlClash 的系统代理或 Windows 手动代理，避免流量继续指向未运行的本地端口。

  4. 保留现有配置

    不删除 Profile、覆写和订阅，不在求助截图中公开 token、节点地址或密码。

DLL 缺失时修复微软官方 v14 运行库

只有弹窗明确点名 MSVCP140.dll、VCRUNTIME140.dll 或同类 v14 运行库文件时，才进入这个分支。Microsoft 将这些文件随 Visual C++ v14 Redistributable 分发。

微软官方页面提供长期不变的 x64、x86 与 ARM64 下载入口。FlClash 当前的 Windows Release 资产目标为 amd64 和 arm64，通常先安装与官方资产目标一致的 x64 或 ARM64 运行库；只有官方说明或依赖检查明确出现 32 位组件时，再考虑 x86。

amd64 安装包对应 Microsoft 的 x64 运行库；arm64 安装包可使用 ARM64 运行库。Microsoft 当前还说明 x64 安装包包含 x64 与 ARM64 二进制，但最容易核对的做法仍是让 FlClash 安装包架构与运行库入口一致。

安装或修复运行库

  1. 从 Microsoft Learn 打开 v14 下载页

    只使用页面列出的 aka.ms 官方永久链接，不从第三方 DLL 站下载文件。

  2. 选择匹配架构

    windows-amd64 使用 X64；windows-arm64 使用 ARM64。下载后再次核对文件名。

  3. 运行官方安装程序

    未安装时选择 Install；已经安装时优先选择 Repair。按 Windows 提示完成，不手工复制 DLL。

  4. 重新打开 FlClash

    安装完成后先直接启动；只有安装程序明确要求时才重启 Windows。

DesktopCoreFailure 要先查 Code Integrity 事件

没有 DLL 弹窗、界面却显示 DesktopCoreFailure 时，先打开 Windows 安全中心，查看“应用和浏览器控制”里的 Smart App Control 状态。

它处于开启状态并不能单独证明拦截。还要把错误时间与 Microsoft-Windows-CodeIntegrity/Operational 日志中的事件对上。

Microsoft 文档把事件 3077 用于记录强制策略真正阻止的文件，事件 3089 提供签名信息。先用 3077 确认被阻止文件，再按 Correlation ActivityID 查找同一次判断关联的一个或多个 3089。

只按时间相近可能误配其他软件的签名事件。#2367 的报告中，两类事件都指向 FlClash 核心程序。

如果日志没有对应路径与 ActivityID，就不要把 DesktopCoreFailure 自动归因于 Smart App Control。

PowerShell 只读查看最近的 Code Integrity 事件
Get-WinEvent -FilterHashtable @{
  LogName = "Microsoft-Windows-CodeIntegrity/Operational"
  Id = 3077, 3089
} -MaxEvents 20 |
  Format-List TimeCreated, Id, ActivityId, Message

3077 指向 FlClash 核心，时间与失败一致

再按同一 ActivityID 检查全部关联的 3089 签名信息。

只有旧事件或路径属于其他软件

不符合本次拦截，回到 FlClash 日志找第一条核心错误。

Smart App Control 为关闭或评估，且没有 3077

不要调整安全设置，转查安装包、服务和核心日志。

Defender 扫描无威胁，但 3077 仍存在

这是独立的 Code Integrity 判定，不能用杀毒结果替代事件证据。

确认拦截后不要把关闭安全功能当首选

Microsoft 当前说明，Smart App Control 没有针对单个应用的放行开关；普通 Defender 排除项也不能替代 Code Integrity 的信任判定。确认 3077 后，不要反复添加目录排除，也不要从第三方重新打包站寻找所谓已解锁核心。

更稳妥的顺序是先保留官方安装包、3077 与同一 ActivityID 下 3089 的脱敏证据并反馈给 FlClash，再查看项目是否已经提供新的、可验证签名或信誉状态明确的官方构建。

在等待期间，可以退回本机此前确实能启动的官方 FlClash 版本，或临时使用仍在维护、来源可核对的其他客户端。回退后仍被拦截，就应停止反复降级。

关闭整个 Smart App Control 会降低系统级保护，影响不只 FlClash。Microsoft 的 FAQ 近年还调整过重新启用条件，所以文章不把关闭它写成固定修复步骤；必须使用时，应先阅读本机当前 Windows 版本对应的官方说明，理解设备范围影响后再自行决定。

优先选择可恢复的处理

  1. 保存事件证据

    记录 3077、关联 ActivityID、全部对应 3089、文件路径和签名状态，移除用户名与私人目录。

  2. 核对官方项目更新

    只接受 FlClash 官方仓库或 Release 提供的后续构建，不下载他人重签名文件。

  3. 尝试已知可用版本

    先备份 Profile，再使用本机曾验证能启动的官方版本；不要把能启动写成永久安全结论。

  4. 必要时临时换客户端

    从项目官方来源选择仍在维护的替代客户端，重新导入已备份配置。

按所选分支验证 FlClash 能否启动

DLL 分支完成后，重新启动 FlClash，确认原弹窗不再出现、界面与核心都能正常载入。Smart App Control 分支完成后，必须同时确认 DesktopCoreFailure 消失，并检查本次启动时间附近没有新的 3077 指向 FlClash 核心。只看到窗口打开还不算完成，核心和配置也要成功加载。

首次恢复时先保持 TUN 关闭，用原 Profile 选择一个已知可用节点并开启系统代理，完成一次普通 HTTPS 请求。这样可以把“程序终于能启动”和“网络配置也仍然可用”分开验证。

启动路径恢复标准

  • 启动时不再出现 MSVCP140.dll 或 VCRUNTIME140 系列弹窗
  • FlClash 界面可以打开，核心状态不再是 DesktopCoreFailure
  • 本次启动时间附近没有新的 Code Integrity 3077 指向 FlClash 核心
  • 原 Profile 和策略选择仍在，没有先清空用户数据
  • 保持 TUN 关闭时，系统代理能完成一次新的 HTTPS 请求
  • 退出 FlClash 后 Windows 直连可以立即恢复

仍然打不开时再重装或回退

运行库修复后仍出现同一 DLL 弹窗，先在“已安装的应用”中确认 Microsoft Visual C++ v14 Redistributable 的架构；显示名称可能随版本变化，再重新执行 Repair。

随后从 FlClash v0.8.96 官方 Release 重新下载与系统匹配的安装包。也可以用同架构官方压缩包做一次对照，判断问题是否只发生在安装过程。

如果压缩包仍报同一 DLL，继续查运行库而不是重复覆盖 FlClash。若 DLL 已消失却变成 DesktopCoreFailure，则说明已经进入另一条分支，应查 Code Integrity 事件。Smart App Control 拦截仍存在时，重装同一个未改变信任状态的文件通常不会产生不同结果。

重试后的结果怎么解释

结果下一步
安装版与压缩版都报同一 DLL再次核对 v14 运行库架构、Repair 结果与 Windows 安装状态
DLL 消失，出现 DesktopCoreFailure转查 3077 / 3089，不继续复制 DLL
旧版能启动，新版仍失败保留旧版与事件对照，向项目反馈，不伪称官方已修复
所有版本都被 3077 拦截停止反复重装，等待可信官方构建或使用替代客户端

最后用七项清单确认修复

最终检查清单

  • 报错文字与处理分支一致，没有一次改动多个无关设置
  • FlClash 安装包与 Microsoft v14 运行库架构已经核对
  • 没有从第三方网站下载或手工注册单个 DLL
  • DesktopCoreFailure 已用 3077、Correlation ActivityID 和关联 3089 判断
  • 没有把 Defender 排除项当作 Smart App Control 放行方式
  • Profile、订阅与覆写保留完好，敏感信息没有出现在反馈中
  • 应用、核心、系统代理与退出后的直连都通过真实请求验证

参考资料