Blazor Server host process terminates (exit code 0xFFFFFFFF) on file <input> selection — only when launched via F5 debug #70004

This issue has been moved from a ticket on Developer Community.

[severity:It's more difficult to complete my work]
When debugging an ASP.NET Core Blazor Web App (Interactive Server render mode) started with F5, selecting a file in any HTML file input immediately terminates the host process. The Kestrel server goes down (browser shows net::ERR_CONNECTION_REFUSED and the Blazor circuit displays "Rejoining the server…"). The process exits with code 4294967295 (0xFFFFFFFF) and no managed exception is logged. The issue does not occur when the app is started without debugging (Ctrl+F5), nor when the debugger is attached to a process that was started cleanly.

Environment:
• Visual Studio Professional 2026, version 18.9.1
• .NET SDK / runtime: .NET 10.0.11
• Project: Blazor Web App, @rendermode InteractiveServer
• MudBlazor 9.8.0 present, but not required to reproduce (see below)
• OS: Windows 11

Steps to Reproduce:

1. Create a Blazor Web App targeting .NET 10 with Interactive Server render mode.
2. Add a page containing a standard <InputFile OnChange="..." /> component (built-in; no third-party dependency needed).
3. Start the app with F5 (Start Debugging) using the https profile.
4. Navigate to the page and select any file in the file picker.
   Expected Result: The selected file's metadata is delivered to the OnChange handler and the circuit remains alive.
   Actual Result: The host process terminates immediately. Browser reports net::ERR_CONNECTION_REFUSED; the circuit attempts to reconnect and fails. Debug Output shows only module-load entries followed by: The program '[PID] BlazorApp1.exe' has exited with code 4294967295 (0xFFFFFFFF). No managed exception, first-chance exception, or Application Error (WER) event is produced (WER suppression is expected while under a debugger).
   Isolation / Diagnostics Already Performed:
   • Reproduces with the built-in <InputFile> component as well as MudBlazor's MudFileUpload — not a third-party/library issue.
   • Disabling .NET/C++ Hot Reload (Tools → Options → Debugging → .NET/C++ Hot Reload) does not fix it.
   • Disabling "Enable JavaScript debugging for ASP.NET (Chrome, Edge)" does not fix it.
   • Browser Link is disabled — does not fix it.
   • Start Without Debugging (Ctrl+F5) works correctly, and file upload succeeds.
   • Attaching the debugger (Debug → Attach to Process) to a process started via Ctrl+F5 also works correctly — file upload succeeds with the debugger attached.
   • The only failing path is a direct F5 debug launch, which differs from the working paths in that VS injects its browser/refresh tooling and startup hooks at launch (observed in Debug Output: Microsoft.AspNetCore.Watch.BrowserRefresh.dll, Microsoft.Extensions.DotNetDeltaApplier.dll, Microsoft.WebTools.BrowserLink.Net.dll).
   • Attempting to suppress the injected startup hooks via launchSettings.json environment variables (DOTNET_STARTUP_HOOKS="", ASPNETCORE_HOSTINGSTARTUPASSEMBLIES="", __ASPNETCORE_BROWSER_TOOLS="") breaks the launch entirely with: An element with the same key but a different value already exists. Key: 'Microsoft.WebTools.ProjectSystem.WebServer.SelfHostWebServer' indicating VS depends on ASPNETCORE_HOSTINGSTARTUPASSEMBLIES for its self-host web server injection, so the injected tooling cannot be opted out of via the launch profile.
   Analysis / Suspected Cause: The failure correlates exclusively with the browser/refresh tooling and startup hooks that VS injects during an F5 debug launch. Because the process exits with 0xFFFFFFFF, produces no managed exception, and generates no WER entry, the termination appears to originate below the managed layer (native crash or fast-fail) and is intercepted by the attached debugger. The clean-launch-plus-attach path (which lacks the injected tooling) is unaffected, strongly implicating the F5-time injection rather than application code, the Blazor runtime, MudBlazor, Hot Reload, JS debugging, or Browser Link.
   Impact: File upload cannot be exercised during a normal F5 debugging session, forcing a Ctrl+F5 + Attach-to-Process workaround.
   Workaround: Start with Ctrl+F5, then Debug → Attach to Process → BlazorApp1.exe.
   Attachments to include (if possible):
   • A minimal repro solution (Blazor Web App, Interactive Server, single page with <InputFile>).
   • Debug Output window log showing the 0xFFFFFFFF exit.
   • A mixed-mode dump: enable native debugging ("debugEngines": "managed,native" in the profile, already set), reproduce, and if the debugger breaks at the faulting frame, capture a dump (Debug → Save Dump As) and attach it.

Original Comments

Feedback Bot on 25/08/2026, 07:23 AM:

Based on similar issues resolved with Microsoft in the last 6 months, the following can help resolve this issue faster.

Possible workarounds

Start the app with Ctrl+F5, then use Debug → Attach to Process and attach to BlazorApp1.exe. File upload works with this clean-launch-plus-attach path.

If not already included, please provide:

Detected: OS: 10.0.26200.0; VS: 18.9.1 (18.9.12112.369); Project type: C# Blazor Web App with Interactive Server; .NET: 10.0.11

• Please attach the minimal repro solution containing the single <InputFile> page.
• Reproduce with native debugging enabled and attach a mixed-mode dump of BlazorApp1.exe captured at the failure, if the debugger breaks at a faulting frame.
• Attach the complete Debug Output log from the F5 launch through the 0xFFFFFFFF exit.
• Confirm whether the issue still reproduces on the latest available Visual Studio 2026 build.

Feedback Bot on 26/08/2026, 05:30 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.