FlClash 0.8.96 が起動しない場合の対処方法

この記事では、Windows に FlClash 0.8.96 をインストールした後、まったく起動しなくなるという最近の二種類の報告を扱います。一つ目は、MSVCP140.dll または VCRUNTIME140.dll が見つからないというダイアログが直接表示されるケースです。元の報告には VCRUNTIME_1.dll とも記載されていますが、具体的なファイル名はこの PC に表示されたダイアログを基準にしてください。

二つ目は画面を開けるものの、コアの起動に失敗して 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 の根拠がないまま、ランタイムの導入、セキュリティ機能の無効化、クライアントの再インストールを同時に行わないでください。

繰り返しダイアログを表示する FlClash をまず終了し、上書きインストールを何度も行わないでください。Windows のバージョン、システムの種類、FlClash のインストールパッケージ名、最初のダイアログまたは DesktopCoreFailure のスクリーンショットを記録します。v0.8.96 の公式 Release には Windows amd64 と arm64 のインストールパッケージおよび圧縮ファイルがあり、ファイル名から実際に導入した種類を確認できます。

それまでシステムプロキシまたは TUN を有効にしていた場合は、Windows のネットワーク設定でシステムプロキシを無効にし、通常の Web ページへ直接接続できることを確認します。クライアントを起動できない状態でローカルプロキシを有効にしたままにすると、起動不良と端末全体の通信断を混同します。Profile、サブスクリプション、アプリのデータディレクトリは削除しないでください。どちらの切り分けでも、最初にユーザー設定を消去する必要はありません。

ダイアログに 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 パッケージのアーキテクチャとランタイムのダウンロード先を一致させる方法が、最も確認しやすい手順です。

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 が原因だと判断しないでください。

Microsoft は現在、Smart App Control にはアプリごとの許可スイッチがないと説明しています。通常の Defender 除外設定も、Code Integrity の信頼判定の代わりにはなりません。3077 を確認した後は、ディレクトリの除外を繰り返し追加したり、第三者の再パッケージ配布サイトで「ロック解除済み」と称するコアを探したりしないでください。

より安全な順序は、公式インストールパッケージと、同じ ActivityID に属する 3077 および 3089 の機密情報を伏せた根拠を保存して FlClash へ報告し、検証可能な署名または明確な評価状態を持つ新しい公式ビルドがプロジェクトから提供されているか確認することです。

対応を待つ間は、この PC で以前実際に起動できた公式 FlClash バージョンへ戻すか、メンテナンスが続いており配布元を確認できる別のクライアントを一時的に利用できます。ロールバック後もブロックされる場合は、何度もダウングレードするのをやめてください。

Smart App Control 全体を無効にするとシステムレベルの保護が低下し、影響は FlClash だけに留まりません。Microsoft の FAQ では近年、再び有効にするための条件も変更されています。そのため、この記事では無効化を定型的な修復手順にはしません。どうしても必要な場合は、この PC の Windows バージョンに対応する公式説明を読み、端末全体への影響を理解したうえで判断してください。

DLL の手順を終えたら FlClash を起動し直し、元のダイアログが表示されず、画面とコアの両方を正常に読み込めることを確認します。Smart App Control の手順を終えた場合は、DesktopCoreFailure が消え、今回の起動時刻付近に FlClash コアを示す新しい 3077 がないことも確認します。ウィンドウが開くだけでは完了ではなく、コアと設定の読み込みも成功する必要があります。

最初の復旧確認では TUN をオフのままにし、元の Profile で動作確認済みのノードを一つ選び、システムプロキシを有効にして通常の HTTPS リクエストを一回完了します。これにより、「アプリがようやく起動した」ことと「ネットワーク設定も引き続き使える」ことを分けて確認できます。

ランタイムを修復しても同じ DLL ダイアログが表示される場合は、まず「インストールされているアプリ」で Microsoft Visual C++ v14 Redistributable のアーキテクチャを確認します。表示名はバージョンによって変わる可能性があります。そのうえで Repair をもう一度実行してください。

続いて FlClash v0.8.96 の公式 Release から、システムに合うインストールパッケージを再度ダウンロードします。同じアーキテクチャの公式圧縮ファイルと比較し、問題がインストール処理だけで起きるか確認することもできます。

圧縮ファイルでも同じ DLL エラーが出る場合は、FlClash の上書きを繰り返さず、ランタイムを引き続き確認します。DLL エラーが消えて DesktopCoreFailure に変わった場合は、別の分岐へ移ったため Code Integrity イベントを確認してください。Smart App Control のブロックが残っているとき、信頼状態が変わっていない同じファイルを再インストールしても、通常は異なる結果になりません。