Skip to content

Fix ASP.NET workloads crashing on Windows due to Linux-only process commands#731

Closed
AlexWFMS wants to merge 2 commits into
microsoft:mainfrom
AlexWFMS:users/alexwill/aspnet-windows-process-commands-fix
Closed

Fix ASP.NET workloads crashing on Windows due to Linux-only process commands#731
AlexWFMS wants to merge 2 commits into
microsoft:mainfrom
AlexWFMS:users/alexwill/aspnet-windows-process-commands-fix

Conversation

@AlexWFMS

Copy link
Copy Markdown
Contributor

Summary

AspNetServerExecutor and AspNetOrchardServerExecutor invoked Linux-only process commands unconditionally, so the ASP.NET workloads crashed on Windows even though both executors declare [SupportedPlatforms("linux-arm64,linux-x64,win-arm64,win-x64")].

  • KillServerInstancesAsync ran pkill and fuser (Unix-only). On Windows these fail to start (Win32Exception: The system cannot find the file specified), so the workload crash-loops until Virtual Client hits its restart-on-crash cap and the run fails with System.AggregateException.
  • AspNetOrchardServerExecutor.StartServerInstances additionally launched the server via nohup (Unix-only) — the same failure mode.

Fix

Make process cleanup and the Orchard server launch platform-aware:

  • KillServerInstancesAsync — keep pkill/fuser on Unix; use taskkill /F /IM <image> on Windows (killing the process also frees the listening port).
  • AspNetOrchardServerExecutor.StartServerInstances — keep nohup on Unix; launch the self-contained server executable directly on Windows.

The Unix code paths are unchanged. taskkill is consistent with the existing Windows kill path in ProcessExtensions.SafeKill. I intentionally did not switch to ProcessManager.GetProcesses(...) + SafeKill: the test InMemoryProcessManager does not override GetProcesses, so that path would call the real Process.GetProcessesByName("dotnet") during unit tests and could kill the test host's own dotnet processes.

Testing

Unit tests — updated the Windows expectations in AspNetServerExecutorTests and AspNetOrchardServerExecutorTests (Linux tests unchanged). All ASP.NET tests pass (14/14).

End-to-end on Azure VMs — self-contained build run on a Windows and a Linux VM with PERF-WEB-ASPNET-BOMBARDIER.json, telemetry shipped to Kusto:

Windows (win-x64) Linux (linux-x64)
AspNetServerExecutor Succeeded ×21 Succeeded ×10
Bombardier result ~76,198 req/s, ~3.43 ms avg latency (1.18M HTTP 200s/iteration) ~72,573 req/s, ~3.53 ms
pkill / "cannot find the file" crashes 0 0

Windows now runs the full ASP.NET Kestrel + Bombardier workload to completion. Both platforms produce near-identical benchmark results.

Documentation

Added a Platform Support section to aspnetbench.md clarifying that the Bombardier-based profile is cross-platform (Windows + Linux) while the Wrk-based profiles are Linux-only (Wrk has no Windows build).

alexwill and others added 2 commits June 19, 2026 13:07
…ommands

AspNetServerExecutor and AspNetOrchardServerExecutor unconditionally invoked the
Unix-only commands pkill and fuser (and, for Orchard, nohup). On Windows these
fail to start (''The system cannot find the file specified''), so the workload
crash-loops until VC hits its restart-on-crash cap and the experiment fails --
despite SupportedPlatforms declaring win-x64/win-arm64.

Replace them with platform-aware branches: keep pkill/fuser/nohup on Unix and use
taskkill (and a direct server-executable launch for Orchard) on Windows. Update
the Windows unit tests accordingly; the Linux tests are unchanged.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Clarify that the Bombardier-based profile runs on Windows and Linux while the
Wrk-based profiles are Linux-only (Wrk has no Windows build), which matches the
now-functional cross-platform server executors.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@AlexWFMS

Copy link
Copy Markdown
Contributor Author

Superseded by #732, which was opened from a branch on the upstream repo (the team's standard flow) instead of a personal fork. Closing this one.

@AlexWFMS AlexWFMS closed this Jun 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant