What to Do When Clash Verge Rev Blocks Windows Shutdown or Restart

Confirm that the Windows shutdown-blocking screen names Clash Verge Rev, then cancel shutdown and record whether the client shows a blank white screen or cannot exit normally. If an existing comparison shows normal shutdown after fully quitting from the system tray, inspect the service logs described below. Do not re-enable an old service for retesting unless it is confirmed to meet the security advisory.

Official repository issues #7725, #7755, #7794, and #7841 contain multiple similar reports covering Windows 10, Windows 11, stable v2.5.2, and later AutoBuilds. Some reports still reproduce after TUN and system proxy are disabled, so turning off TUN alone does not prove that Service has exited.

Check that Clash Verge Service is installed, diagnostics show Running Mode as Service, the app remains in the tray after closing its main window, and shutdown is blocked only while it is running. If unsaved documents, Windows Update, another VPN, or a differently named background app is blocking shutdown, investigate that process instead.

Run the comparison below only after confirming that the actual service component meets the security advisory. Keep unverified or affected services disabled; do not start them for retesting. Investigate Service further only if running the application repeatedly blocks shutdown while a full exit allows it. If both attempts are blocked, use the Windows message and Task Manager to identify the actual blocking process.

Service IPC is communication between the client and the background service. If the exit logs stop here, the stop request or the wait for completion may not have finished. Compare this with the logs from manually quitting through the tray.

After canceling shutdown, open the latest application log and read from the exit phase onward. Similar reports first save the configuration, disable TUN, and stop the core, then stall at “Stopping core through service (IPC).”

If there is no later record of a successful core stop, completed cleanup, or Application exited, but those records appear when you quit from the tray, focus on the Service stop request during system shutdown and whether the client keeps waiting for it to finish.

The reporter in issue #7794 used process dumps to conclude that the Service had returned to an idle state while the client-side IPC completion wait never returned. This is useful diagnostic evidence, but it is not an official root-cause conclusion from the maintainers.

Keep the current version, running mode, subscription name, Profile, system proxy and TUN states, and logs from blocked shutdown and full exit. When copying settings and logs, leave existing subscriptions unchanged and do not overwrite the original backup.

Do not delete the AppData configuration directory or publicly upload complete logs containing subscriptions, node passwords, controller secrets, or tokens. If you need to submit a dump, understand first that process memory may contain sensitive information.

The app may remain in the tray after its main window closes. Check the icon, GUI process, and exit logs to confirm that it has fully quit. If the wait never finishes, use the Service IPC logs described above, then proceed to disabling the service.

If full exit still hangs, or the actual service has not been verified against the security advisory, do not repeat shutdown comparisons with the service running. Turn off TUN and the system proxy, record the configuration, and restore ordinary Windows connectivity before disabling or uninstalling the service through the controls below.

Verify basic connectivity with the system proxy alone first. TUN may be unavailable without the Service or administrator privileges; this is an expected tradeoff and should not be bypassed by repeatedly toggling TUN.

The existing Windows service security advisory lists affected builds. Do not re-enable old services in that range. To restore the app, check currently supported official stable releases and the advisory for the source, complete build number, and actual service component.

Keep the current data, trusted configuration backups, and installation source records. If you cannot confirm the service is fixed, keep it disabled and TUN off, and use a verified system proxy for basic access. Do not copy service executables from old backups or re-enable old builds to test shutdown.

Do not repeatedly choose “Shut down anyway” or hold the power button. Do not delete the entire AppData configuration directory, manually remove unknown Windows services or virtual adapters, or download an AutoBuild from an unverified source for testing.

Force-ending a process can clear one block, but it may skip configuration saving and proxy cleanup. Use Task Manager to end the GUI only as a last resort to recover the current desktop after canceling shutdown, saving all work, and confirming that the client cannot exit on its own. Check the system proxy afterward.

After choosing one workaround, complete two consecutive restarts at a controlled time. Save your work before each test, record whether the blocking screen appears, and check the system proxy, subscription, Profile, and rules after signing in again.

Once shutdown is no longer blocked, also confirm that the logs record the core stopping before exit, Windows has no leftover proxy after restart, the configuration is intact when you reopen the client, and the system proxy can complete a new HTTPS request.

Reporters in issue #7725 and #7794 identified v2.5.1 as the last working version on their devices. This is a historical behavior comparison, not a safe rollback recommendation or a reason to reinstall an old Service.

As of 2026-09-01, the available evidence shows that Clash Verge Rev blocking Windows shutdown is not an isolated user report. The behavior has been reported multiple times when Service Mode is active and the GUI remains running, and an official collaborator also reproduced it in issue #7755.

However, it would be inaccurate to say that “Service IPC has been officially confirmed as the sole root cause.” Issue #7725 was closed after a maintainer requested retesting following the Service refactor; it was not an official fix announcement. Issue #7794 later reported that a post-refactor AutoBuild still reproduced the problem, and #7841 recorded the same behavior with v2.5.2 on Windows 10.

The stable release notes during the reporting period had not announced a fix. For further reports, include redacted logs, versions, Running Mode, the manual-quit comparison, and whether Service is installed. Do not publish complete process dumps, subscriptions, or node credentials.