Clash Crashing on Startup in Windows? Fix WebView2, Service Mode, and Config Issues

First, identify the problem: Is the UI crashing, or is the mihomo core exiting?

If no window appears after you double-click the client, the app may not have crashed. Some clients restore the previous “minimize on startup” setting and remain in the notification area. Click the expand arrow on the right side of the taskbar, then open Task Manager → Details to see whether the client process is still running. Once you’ve ruled out a hidden window, continue with the checks below.

A Clash client includes a UI, config management, and a proxy core. The UI may open normally while the mihomo core fails to start, or the core may keep running in the background after the UI fails to render. These scenarios need different fixes, so don’t diagnose the issue based only on “it won’t open.”

Step 1: Record the version and Windows errors before reinstalling

Note the client name, full version number, Windows version, and installer architecture. The client version and mihomo core version are separate and aren’t interchangeable. If the UI opens, check About or the version information page. Otherwise, check the installer filename and the executable’s Properties → Details. File properties may not show the core version; if it’s missing, say so.

1. Press Win + R, run winver, and note your Windows version and OS build.
2. Go to Settings → System → About and check System type to determine whether your system is x64 or ARM64. Choose the build specified in the client’s release notes.
3. Press Win + R, run perfmon /rel, find the recent application failure in Reliability Monitor, and open the technical details.
4. If there’s no matching entry, run eventvwr.msc and check Windows Logs → Application for errors at the time the startup failed.

Record the “Faulting application name,” “Faulting module name,” “Exception code,” and timestamp. A system DLL in the report only shows that the crash passed through that module; it doesn’t prove the DLL is damaged. Don’t download individual DLLs from unfamiliar sites or change the runtime, service, and config all at once—you won’t know which step helped.

Step 2: For a blank screen, check whether the client uses WebView2

WebView2 isn’t a dependency shared by every Clash client. Windows clients built with Tauri typically use it to render the UI. Older Clash for Windows releases use Electron, which generally bundles its own Chromium; Flutter clients can’t be fixed by blindly applying WebView2 advice either. Check the current client’s project documentation and installation prompts before repairing the runtime.

Check and repair in this order

1. In Windows 11, open Settings → Apps → Installed apps and search for Microsoft Edge WebView2 Runtime. On Windows 10, look under Apps & features; on some systems, you can also check Control Panel → Programs and Features.
2. If the client explicitly requires WebView2 and it isn’t installed, use Microsoft’s official Evergreen Runtime installer. For offline systems, choose the standalone installer that matches your system architecture.
3. If it’s already installed, close apps that depend on it, then use the Windows repair option or the installer’s repair option. The available option depends on how the runtime was installed, so don’t waste time looking for a specific button name.
4. Restart the client when installation or repair is complete. If the installer asks you to restart Windows, do so before testing anything else.

Having Microsoft Edge installed doesn’t guarantee that the WebView2 Runtime needed by the client is intact. A blank screen also doesn’t prove WebView2 is damaged: renderer failures, corrupted UI cache, or security software blocking the app can cause similar symptoms.

If the logs point to a graphics rendering issue, update your graphics driver from the device manufacturer and check whether the client offers a hardware acceleration setting. Use a toggle or launch argument only if the documentation for your version explicitly supports it. Don’t pass Electron arguments to Tauri or Flutter apps.

Step 3: Turn off TUN and check the service and standard proxy separately

Service mode generally runs background components with the permissions they need. TUN mode routes traffic through a virtual network adapter; they’re different features. A client can install a service without enabling TUN, and a standard system proxy usually doesn’t require running the entire UI as administrator. When startup fails, test the UI, core, service, and TUN separately.

If the UI still opens

1. Turn off TUN mode first and use standard proxy mode for testing. Settings vary by client, so follow the options in your app.
2. Fully exit the client and reopen it. Check whether it reaches the main screen, loads the config, and displays core logs.
3. If standard mode works, check the service status in the client’s service management screen. If you need to install or repair the service, verify the program’s publisher in the Windows permission prompt.
4. Once the service is working, enable TUN on its own and check for errors creating the virtual adapter, setting routes, or granting permissions.

If it hangs while connecting to the service

Press Win + R, run services.msc. Service names vary by client, so don’t guess based on an online guide. Open the relevant service’s properties and check whether its executable path still points to the current installation folder. If you moved a portable app, the old service may still point to its previous location. Services left behind after uninstalling a client can also cause conflicts.

Use the current client’s service repair or reinstall option whenever possible. Don’t run service removal commands from unknown sources or copy an old client’s service executable into a new client’s folder. If the problem occurs only with TUN enabled, note any VPN, virtual machine networking software, or other TUN clients running at the same time. Exit them one at a time to test; don’t reset every network adapter.

Step 4: Find the port conflict instead of just changing 7890

Log messages such as address already in use or bind usually mean the app couldn’t start listening on a port. 7890 is a common example of a proxy port, and 9090 often appears in controller API examples, but neither is a fixed value for every client. Check the actual generated config for mixed-port, port, socks-port, and external-controller.

For example, if the config uses mixed-port: 7890 and the controller API address is 127.0.0.1:9090, use PowerShell to check whether those TCP ports are listening:

Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

In the output, OwningProcess is the process ID. Match it to the PID in Task Manager → Details, then check the process path. No output means those two TCP ports weren’t listening when you ran the query; it doesn’t rule out problems with other ports or UDP listeners. If the log reports a UDP conflict, check the specific port with Get-NetUDPEndpoint.

• Old client still running: Exit the old client from its notification area menu and check whether its background service has also stopped.
• Client launched more than once: End any leftover instances you’ve confirmed belong to that client, then launch it once.
• Another app is using the port: Confirm what the process is for, then change the port for one of the apps. Don’t end unidentified system processes.

After changing a proxy port, check that the Windows system proxy address matches. After changing the controller API, make sure the UI’s connection address matches the core config. If the controller API requires a secret, a mismatch can cause a “failed to connect to core” error even when the address is correct. Keep the controller API bound to localhost; don’t expose it on every network interface just to make the connection work.

Step 5: Isolate leftover config and keep a restorable backup

An in-place installation usually replaces program files without clearing user data. That’s why a client may start crashing after an upgrade or show a blank screen after you restore an old config: leftover settings or changes to the config format may be involved. Back up your data and test with a fresh config instead of deleting the entire folder right away.

Find the data folder

If the UI opens, use the client’s option for opening its config, data, or log folder. If it won’t open, enter %APPDATA% and %LOCALAPPDATA% in File Explorer’s address bar and use the client documentation and logs in those folders to identify the right one. Portable mode may store data beside the program. Folder names vary between clients and versions.

1. Fully exit the client and stop any background service you’ve confirmed belongs to it, so files aren’t being written during the backup.
2. Copy the confirmed data folder to a local backup location. Keep subscriptions, overrides, rules, certificates, and logs.
3. Once you’ve confirmed the backup is readable, rename the original folder—for example, append .backup-20260821 to its name. Don’t delete it yet.
4. Restart the client and let it create fresh default data. Don’t restore subscriptions or overrides yet; first check whether the window and core start reliably.
5. If it works, import one subscription, then restore custom rules, overrides, and TUN settings one at a time, testing after each change.

If a fresh data folder works but restoring a particular setting causes the failure, you’ve narrowed down the cause. Invalid YAML indentation, a reference to a nonexistent proxy group, or a field unsupported by the current core can stop the core from loading without necessarily crashing the UI. Use the logs to distinguish a parsing error from a process crash, then consult the YAML guide. Don’t assume every problem means the subscription is invalid.

Step 6: Check for security blocks, then reinstall in a controlled way

If the UI starts but reports that the core file is missing, or the same file disappears after every reinstall, open Windows Security → Virus & threat protection → Protection history. Check the block timestamp, file path, and detection name. The path and time need to match the failure; an alert in the history alone doesn’t prove it caused the current problem.

First verify the installer’s source, publisher, and the current project’s system requirements. Only consider restoring a file after you’ve confirmed it’s trustworthy and understand the alert. Don’t disable all protection or add your entire Downloads folder to exclusions. On a managed work device, ask your administrator to handle policy restrictions.

• Download a complete installer for the correct architecture from a trusted release source; don’t copy just one executable file.
• Make sure the old instance has exited and handle its service as described by the client. Keep the data backup you made in the previous step.
• Install to a stable local path. Start with the default data, then restore your subscription.
• If the issue appears only after a specific upgrade, record the full version numbers before and after. Check the project’s guidance before rolling back; don’t let an older version overwrite a newer data format.

Issues with the Electron UI in older Clash for Windows releases aren’t the same as service problems in newer mihomo-based clients. When switching clients, don’t copy the entire old data folder. Migrate subscriptions, custom rules, and overrides separately. See the client comparison to choose a client.

Verify the fix and report the issue

Getting a window to appear is only the first step. Follow the checks below to confirm the issue is resolved, not just temporarily bypassed.

1. Restart test: Exit normally and reopen the client. Confirm that both the UI and core start without repeatedly ending processes in Task Manager.
2. Standard proxy test: Test the system proxy using the actual proxy port, then check connection logs and matched rules. A successful node latency test doesn’t prove that app traffic is using the proxy.
3. TUN test: Enable TUN only if you need it, then check the service, virtual adapter, and logs. Standard proxy mode works fine with TUN left off when you don’t need it.
4. Exit test: Exit the client normally and check that the system proxy is restored as expected. Otherwise, your browser may connect to a port with no listener the next time you start Windows.

If the problem persists, include your Windows version and architecture, client and core versions, when the issue occurred, steps to reproduce it, whether service mode and TUN were enabled, a few log lines before and after the error, and the result of testing with a fresh data folder. Version details help maintainers identify relevant code changes, while step-by-step test results prevent repeated suggestions.

For more configuration help, see how to import a subscription and how to test your connection. When troubleshooting startup, change one thing at a time: get the UI working first, then the core, then the service, TUN, and custom config.