Fix v2rayN Startup Crashes: .NET Runtime, Antivirus Blocks, and Folder Permissions

First, identify the problem: is the window closing or the core failing to start?

v2rayN is a graphical client; proxy connections are handled by cores such as Xray and V2Fly. An exiting interface process and an exiting core subprocess are different issues. For the former, check the desktop runtime first; for the latter, check the core files, generated configuration, and listening ports. These Windows runtime steps do not apply to v2rayNG or v2flyNG on Android.

• The window disappears but the process is still running: Press Ctrl + Shift + Esc to open Task Manager, then look for v2rayN.exe under Details. Also expand the taskbar’s hidden icons to see if the app is simply minimized to the system tray.
• The main process has also exited: Note the time you double-clicked the app, then check Windows Event Viewer and any startup error messages. Check the runtime and access permissions first.
• The window stays open, but the logs keep showing errors: Save the core logs and check that the relevant core is present. Reinstalling .NET repeatedly is unlikely to help in this case.

Do not delete the original folder yet. Exit the app completely, then copy the entire folder to a backup location. If your version uses a separate user data folder, back up that location too. Subscription URLs, node credentials, and custom routing rules may be stored there, so backing up only the main app is not enough.

.NET Desktop Runtime: Match the Required Framework and Architecture

Windows WPF builds that depend on an external runtime require the matching .NET Desktop Runtime. This is different from the similarly named .NET Runtime and ASP.NET Core Runtime; installing only those may not be enough to launch the app. Self-contained builds usually do not depend on a separately installed .NET runtime, so do not assume every package needs one.

1. Check the package type

   Check whether the download page offers a WPF build or another desktop build, and whether it is marked self-contained. Do not apply the runtime requirements for a different build to the file you are using.

2. Check the framework requirements

   If the folder contains v2rayN.runtimeconfig.json, open it in Notepad and check runtimeOptions.framework or frameworks for the name and version values. If the file is not included, refer to the release notes and startup prompt for that package.

3. Check the installed runtimes

   Open PowerShell and run the command below. Builds that require the Windows Desktop framework should show a compatible version of Microsoft.WindowsDesktop.App, not just Microsoft.NETCore.App.

4. Install the matching runtime and try again

   Download the Desktop Runtime matching the required major version and architecture from Microsoft’s official .NET download page. Run the client again after installation. If prompted to restart Windows, do so before testing again.

dotnet --info
dotnet --list-runtimes

For example, a configuration requiring Microsoft.WindowsDesktop.App version 8.0.0 can usually use a .NET 8 Desktop Runtime that meets the default patch roll-forward rules. This is just an example of how to read the fields; it does not mean every v2rayN version uses .NET 8. An installed runtime with a newer major version does not automatically meet the requirement, and you should not edit runtimeconfig.json just to clear an error.

Antivirus Blocks: Check the Logs Before Restoring Files

If the app stops launching after an update or core files disappear after extraction, check the quarantine history first. In Windows Security, go to Virus & threat protection → Protection history. Find the entry matching the time of the issue and verify the full path of the affected file. If you use another security app, check its quarantine or event logs in the same way.

Do not disable real-time protection for the whole device or add the entire Downloads folder or drive to exclusions. Before restoring a quarantined file, confirm the download source, package type, and file path. If you cannot verify the file, leave it quarantined and obtain a trusted release package. Restoring just one core executable may not be enough if other files from the archive are missing too.

• In File Explorer, select View → Show → File name extensions to avoid mistaking a similarly named file for an executable.
• Right-click the archive and select Properties. If you see an Unblock checkbox, select it only after confirming the source, then extract the full archive.
• Do not run the app by double-clicking it in the archive preview. Extract the entire folder locally first.

Folder Permissions: Check Write Access Without Running as Administrator

The client may write logs, a settings database, and generated core configuration in addition to reading app files. If it is stored in C:\Program Files, a read-only network share, or a controlled folder, the window may appear briefly and then close. Check the exact path named in the error instead of granting broad permissions to the entire folder.

1. Exit the client completely and create a local test folder, for example C:\Users\Public\Downloads\v2rayN-test. Use this shared folder only for temporary troubleshooting, not for long-term storage of subscriptions or credentials.
2. Extract the complete trusted release package to the test folder. For the first launch, do not copy over old settings; run it as a standard user.
3. Try creating and deleting a text file in the directory where the app writes data. If that fails, check the current account’s permissions under Properties → Security and review Controlled folder access history in Windows Security.
4. If the app launches from the temporary folder, move it to a dedicated folder your user account can write to, then restore the backup in batches. If your version stores data in your user profile, check permissions for that location as well.

The Read-only checkbox for a folder in File Explorer does not, by itself, prove the folder is unwritable. Better evidence includes a file creation test, the access control list, and the target file path in the error. If a new folder works but the original does not, focus on differences in the environment; there is no need to immediately change nodes or recreate subscriptions.

The Window Stays Open but Connections Fail: Check the Core, Ports, and Configuration

If the main window works, first check local listening settings under Settings → Parameter Settings, then review the log area available in your version. Core and port options may be on different tabs in different versions; use the labels shown in your interface. Do not copy client settings directly into an Xray JSON configuration as if they were Xray fields.

If the log shows address already in use or Only one usage of each socket address, check whether another process is using the same address and port. The command below uses 10808 as an example; replace it with the value in Parameter Settings if your port differs. You can look up the process ID under Details in Task Manager. Do not terminate an unfamiliar system process.

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

• Incompatible core: Check whether the core in use supports the node’s protocol and transport settings. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core; this does not mean their configuration capabilities are identical.
• Incorrect node settings: Errors in VLESS or VMess settings usually appear in core startup or connection logs. If switching to another known-good configuration resolves the issue, check the original node settings instead of continuing to troubleshoot the desktop runtime.
• Incorrect custom routing: Restore a minimal working ruleset and try again. Check that routing.rules in the generated configuration matches the referenced outboundTag. See the routing configuration reference for field details.
• Only TUN startup fails: Turn off TUN and test the regular proxy first, then check elevation prompts, the virtual network adapter, and relevant core logs. TUN is not a single JSON switch shared by all cores.

Gather Evidence: Compare Event Viewer Results and a Clean Folder

If nothing appears after you double-click the app, press Win + R, enter eventvwr.msc, and open Windows Logs → Application. Look for entries from Application Error, .NET Runtime, and other sources around the time you noted. Event IDs are just clues; read the faulting application path, module name, and exception message too.

Once the app opens normally from the new folder, close it and back up this working state. Then restore subscriptions, nodes, and custom rules one at a time, testing the app after each step. If the issue returns after restoring an item, you can narrow it down to that configuration or database instead of deleting all your subscriptions. See the subscription configuration reference for details.

When reporting the issue to a maintainer or device administrator, include your operating system version, client build type, process architecture, installed runtimes, reproduction time, and exception stack trace. Redact subscription URLs, access tokens, UUIDs, passwords, and server addresses from logs first. Keep the error type, module name, and necessary path structure, but do not upload the entire user data folder.

FAQ: Updates, Old Settings, and Startup Permissions