安裝與遷移 · Clash 技術部落格

FlClash 0.8.96 無法啟動怎麼修？

FlClash 0.8.96 無法啟動？依缺少 MSVCP140.dll、VCRUNTIME140.dll 或出現 DesktopCoreFailure 分流檢查。

閱讀正文回到部落格
  • FlClash
  • Windows 11
  • MSVCP140.dll
  • DesktopCoreFailure
  • Smart App Control
本文目錄
發布日期
預計閱讀
約 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 執行階段程式庫無法使用核對架構並修復 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。

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

確認遭到封鎖後，不要把關閉安全性功能當成首選

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
  • 已使用 3077、Correlation ActivityID 與關聯的 3089 判斷 DesktopCoreFailure
  • 沒有把 Defender 排除項目當成 Smart App Control 的允許方式
  • Profile、訂閱與覆寫完整保留，回報中沒有出現敏感資訊
  • 應用程式、核心、系統代理與退出後的直接連線，都已透過實際請求驗證

參考資料