Installation and Migration · Clash Technical Blog

How to Fix FlClash 0.8.96 Not Launching

FlClash 0.8.96 won't start? Troubleshoot by whether MSVCP140.dll or VCRUNTIME140.dll is missing, or DesktopCoreFailure appears.

Read the articleBack to blog
  • FlClash
  • Windows 11
  • MSVCP140.dll
  • DesktopCoreFailure
  • Smart App Control
On this page
Published
Updated
Estimated reading time
About 9 minutes

Reinstalling may not fix an app that still will not start after installation. A missing-runtime popup and an open window whose core is blocked call for different checks. Preserve the first error and matching system events, then act on that evidence. Do not download replacement files from unknown sites or turn off system-wide protection without confirming a block.

Different fixes for missing DLL files and DesktopCoreFailure

Reports of FlClash 0.8.96 failing to start on Windows fall into two categories. The first shows missing MSVCP140.dll or VCRUNTIME140.dll. The original report also names VCRUNTIME_1.dll; use the exact filename shown on your own device.

In the second, the interface opens, but the core fails to start and displays DesktopCoreFailure. Both can look like a broken installation, but their troubleshooting paths differ.

If FlClash has already started and only shows node Timeout, TUN disconnection, or subscription failure, investigate the network and subscription instead. Without a DLL dialog or Code Integrity evidence, do not install runtimes, disable security features, and reinstall the client all at once.

Choose a path based on the first error

First visible errorMore likely stageAction to take
MSVCP140.dll / VCRUNTIME140.dll is missingThe MSVC v14 runtime required by the app is unavailableCheck the architecture and repair the official Microsoft runtime
DesktopCoreFailure with events 3077 / 3089A Smart App Control Code Integrity decisionPreserve the event evidence; do not add a Defender exclusion first
Only a node Timeout or DNS errorThe network stage after the core has startedSwitch to connection and latency troubleshooting
The installer itself will not openDownload, architecture, or a Windows Security blockRecheck the official installer and file source

Record the installation architecture, dialog, and direct connection status

First close any repeatedly opening FlClash processes; do not keep installing over the existing copy. Record the Windows version, system type, FlClash installer filename, and a screenshot of the first pop-up or DesktopCoreFailure. The official v0.8.96 Release provides both amd64 and arm64 Windows installers and archives, so the filename can confirm which one was actually installed.

If system proxy or TUN was enabled earlier, disable the system proxy in Windows network settings and confirm ordinary webpages work over a direct connection. Leaving a local proxy enabled while the client cannot start mixes a launch failure with a system-wide network outage. Do not delete Profiles, subscriptions, or the app data directory; neither troubleshooting path requires clearing user configuration first.

Save the information needed to roll back

  1. Record the installer filename

    Confirm whether it is windows-amd64 or windows-arm64; do not use “64-bit” in place of the exact architecture.

  2. Save the first error

    Record the full DLL name; for DesktopCoreFailure, keep the time it appeared so you can find the corresponding event.

  3. Restore direct system connectivity

    Turn off FlClash's system proxy or the Windows manual proxy so traffic does not keep going to a local port with nothing listening.

  4. Keep the existing configuration

    Do not delete Profiles, overrides, or subscriptions, and do not expose tokens, node addresses, or passwords in support screenshots.

Repair the official Microsoft v14 runtime when a DLL is missing

Use this path only when the pop-up explicitly names MSVCP140.dll, VCRUNTIME140.dll, or a similar v14 runtime file. Microsoft distributes these files with the Visual C++ v14 Redistributable.

Microsoft's official page provides stable download links for x64, x86, and ARM64. Current FlClash Windows Release assets target amd64 and arm64, so first install the x64 or ARM64 runtime that matches the official asset target; consider x86 only if the official guidance or a dependency check explicitly identifies a 32-bit component.

The amd64 installer corresponds to Microsoft's x64 runtime; the arm64 installer can use the ARM64 runtime. Microsoft currently also notes that the x64 installer contains both x64 and ARM64 binaries, but the easiest approach to verify is still to match the FlClash installer architecture with the runtime download.

Install or repair the runtime

  1. Open the v14 download page on Microsoft Learn

    Use only the official permanent aka.ms links listed on the page; do not download files from third-party DLL sites.

  2. Select the matching architecture

    Use X64 for windows-amd64 and ARM64 for windows-arm64. Check the filename again after downloading.

  3. Run the official installer

    Choose Install if the runtime is not installed; if it is already installed, choose Repair first. Follow the Windows prompts and do not copy DLLs manually.

  4. Open FlClash again

    Launch it directly after installation; restart Windows only if the installer explicitly asks you to.

Use Code Integrity events to check whether the core was blocked

If there is no DLL pop-up but the interface displays DesktopCoreFailure, first open Windows Security and check the Smart App Control status under App & browser control.

An On status alone does not prove a block. You must also match the failure time to events in the Microsoft-Windows-CodeIntegrity/Operational log.

Microsoft documents event 3077 as recording a file actually blocked by an enforced policy, while event 3089 provides signature information. First use 3077 to confirm the blocked file, then use the Correlation ActivityID to find one or more 3089 events associated with the same decision.

Matching only by nearby timestamps can incorrectly pair a signature event from other software. In the #2367 report, both event types point to the FlClash core executable.

If the log has no matching path and ActivityID, do not automatically attribute DesktopCoreFailure to Smart App Control.

View the latest Code Integrity events in read-only mode with PowerShell
Get-WinEvent -FilterHashtable @{
  LogName = "Microsoft-Windows-CodeIntegrity/Operational"
  Id = 3077, 3089
} -MaxEvents 20 |
  Format-List TimeCreated, Id, ActivityId, Message

Event 3077 points to the FlClash core and its time matches the failure

Then use the same ActivityID to inspect all associated 3089 signature information.

Only old events appear, or the path belongs to other software

This does not match this type of block. Return to the FlClash log and find the first core error.

Smart App Control is Off or in Evaluation mode, and there is no 3077 event

Do not change security settings; inspect the installer, service, and core logs instead.

Defender reports no threats, but event 3077 still exists

This is a separate Code Integrity decision; antivirus results cannot replace event evidence.

Safe choices after Smart App Control blocks the app

Microsoft currently states that Smart App Control has no allow switch for individual apps; ordinary Defender exclusions also cannot override a Code Integrity trust decision. After confirming event 3077, do not keep adding directory exclusions or look for a supposedly unlocked core on third-party repackaging sites.

A safer sequence is to preserve redacted evidence from the official installer, event 3077, and event 3089 entries under the same ActivityID, report it to FlClash, and then check whether the project has provided a newer official build with a verifiable signature or clearly established reputation.

Turning off Smart App Control reduces system-wide protection and affects more than FlClash. Microsoft has also changed the re-enabling conditions in its FAQ in recent years, so this article does not prescribe disabling it as a fixed repair step. If you must use the app, read the official instructions for your current Windows version and understand the effect on the whole device before deciding.

Prefer reversible actions

  1. Preserve event evidence

    Record event 3077, the associated ActivityID, every corresponding 3089 event, the file path, and the signature status, removing the username and private directories.

  2. Check official project updates

    Accept only later builds from the official FlClash repository or Releases; do not download files re-signed by other people.

  3. Try a known working version

    Back up the Profile before using an official version previously confirmed to start on this device. Starting successfully does not establish lasting safety. If the older version is still blocked, stop repeatedly downgrading.

  4. Temporarily switch clients if necessary

    Choose a maintained alternative client from its official project source, then re-import your backed-up configuration.

The FlClash window, core, and configuration load normally, with no new events indicating that the core was blocked

After completing the DLL path, restart FlClash and confirm that the original pop-up no longer appears and that both the interface and core load normally. After completing the Smart App Control path, confirm both that DesktopCoreFailure is gone and that no new event 3077 near the current launch time points to the FlClash core. Seeing the window open is not enough; the core and configuration must load successfully too.

For the first recovery test, keep TUN off, select a known working node in the original Profile, enable the system proxy, and make one ordinary HTTPS request. This lets you verify “the application can finally launch” separately from “the network configuration still works.”

Launch recovery criteria

  • No MSVCP140.dll or VCRUNTIME140-family pop-up appears at launch
  • The FlClash interface opens and the core status is no longer DesktopCoreFailure
  • No new Code Integrity event 3077 near the current launch time points to the FlClash core
  • The original Profile and policy selection remain, without clearing user data first
  • With TUN off, the system proxy completes a new HTTPS request
  • Direct Windows connectivity returns immediately after exiting FlClash

What to do if runtime repair or reinstallation still fails

If the same DLL pop-up remains after repairing the runtime, first check the architecture of Microsoft Visual C++ v14 Redistributable under Installed apps; its display name may change between versions. Then run Repair again.

If reinstallation is needed, use the official FlClash Release for v0.8.97, which includes the MSVC runtime, or a later version the project confirms retains that packaging change. Check your system architecture and back up the Profile first. Compare with the official portable archive of the same version and architecture to see whether the failure is limited to installation.

If the archive reports the same DLL, continue troubleshooting the runtime instead of repeatedly installing FlClash over itself. If the DLL error disappears but becomes DesktopCoreFailure, you have entered the other path and should inspect Code Integrity events. When a Smart App Control block remains, reinstalling the same file without any change to its trust state usually produces the same result.

How to interpret the result after retrying

ResultNext step
Both the installed and archive versions report the same DLLRecheck the v14 runtime architecture, Repair result, and Windows installation state
The DLL error disappears, but DesktopCoreFailure appearsInspect events 3077 / 3089 instead; do not keep copying DLLs
An older version launches, but the new version still failsKeep a comparison between the older version and the events, report it to the project, and do not falsely claim an official fix
All versions are blocked by event 3077Stop reinstalling repeatedly; wait for a trustworthy official build or use an alternative client

Official issue #2370 documents DLL pop-ups after installing v0.8.96 on Windows 11 25H2; issue #2367 documents Smart App Control blocking the core, with Code Integrity events 3077 and 3089.

References