安裝與遷移 · 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 分鐘

安裝完成後仍無法開啟，不一定能靠再次安裝解決：缺少執行階段程式庫的提示，與視窗已開啟但核心被阻止，是不同的檢查方向。要保留第一則錯誤和對應系統事件，依證據選擇處理；不要從陌生網站補檔案，也不要在未確認攔截時關閉整台裝置的保護。

DLL 缺失與 DesktopCoreFailure 的不同處理

FlClash 0.8.96 在 Windows 上啟動失敗的報告有兩種。第一種會直接彈出 MSVCP140.dll 或 VCRUNTIME140.dll 缺失；報告原文還寫有 VCRUNTIME_1.dll，具體檔案名需以本機彈窗為準。

第二種能開啟介面，但核心啟動失敗並顯示 DesktopCoreFailure。兩者看起來都像安裝損壞，實際的檢查路徑並不相同。

如果 FlClash 已經啟動、只是節點 Timeout、TUN 斷網或訂閱失敗，應轉查網路與訂閱。不要在沒有 DLL 彈窗或 Code Integrity 證據時同時安裝執行庫、關閉安全功能和重裝用戶端。

用第一則錯誤選擇分支

第一則可見錯誤更可能的階段對應處理
缺少 MSVCP140.dll / VCRUNTIME140.dll應用程式依賴的 MSVC v14 執行階段程式庫無法使用核對架構並修復 Microsoft 官方執行階段程式庫
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 時修復 Microsoft 官方 v14 執行階段程式庫

只有彈出視窗明確指出缺少 MSVCP140.dll、VCRUNTIME140.dll 或同類 v14 執行階段程式庫檔案時，才進入此分支。Microsoft 會隨 Visual C++ v14 Redistributable 發佈這些檔案。

Microsoft 官方頁面提供長期不變的 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。

用 Code Integrity 事件核對核心是否被攔截

沒有 DLL 錯誤視窗，介面卻顯示 DesktopCoreFailure 時，先開啟 Windows 安全性，查看「應用程式與瀏覽器控制」中的 Smart App Control 狀態。

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 判定，不能用防毒掃描結果取代事件證據。

被 Smart App Control 攔截後的安全選擇

Microsoft 目前說明，Smart App Control 沒有允許單一應用程式的開關；一般 Defender 排除項目也不能取代 Code Integrity 的信任判定。確認 3077 後，不要反覆加入資料夾排除項目，也不要從第三方重新封裝網站尋找所謂已解鎖的核心。

較穩妥的順序是先保留官方安裝套件、3077 與同一 ActivityID 下 3089 的去識別證據並回報給 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 官方 Release 選擇已補齊 MSVC 執行階段程式庫的 v0.8.97，或專案確認保留此處理的後續版本，並核對系統架構。先備份 Profile；也可使用同版本、同架構的官方可攜式壓縮檔比較，判斷問題是否只發生在安裝過程。

如果壓縮檔仍顯示同一個 DLL 錯誤，請繼續檢查執行階段程式庫，不要反覆覆蓋 FlClash。若 DLL 錯誤已消失，卻改成 DesktopCoreFailure，代表已進入另一個分支，應查看 Code Integrity 事件。Smart App Control 的封鎖仍存在時，重新安裝同一個信任狀態未改變的檔案，通常不會得到不同結果。

如何解讀重試後的結果

結果下一步
安裝版與壓縮版都顯示同一個 DLL 錯誤再次核對 v14 執行階段程式庫架構、Repair 結果與 Windows 安裝狀態
DLL 錯誤消失，出現 DesktopCoreFailure轉查 3077 / 3089，不要繼續複製 DLL
舊版能啟動，新版仍然失敗保留舊版與事件的對照並向專案回報，不要假稱官方已修復
所有版本都遭 3077 封鎖停止反覆重新安裝，等待可信的官方建置或使用替代用戶端

官方 issue #2370 記錄了 Windows 11 25H2 安裝 v0.8.96 後出現的 DLL 錯誤視窗；issue #2367 則記錄了 Smart App Control 封鎖核心，以及 Code Integrity 事件 3077、3089。

參考資料