Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Dec 22, 2025

Description

On Windows < 11, the auxiliary backchannel service fails at startup with SocketException (10050): A socket operation encountered a dead network because "AUX" is a reserved DOS device name (along with CON, PRN, NUL, COM1-9, LPT1-9). Windows interprets aux.sock.{hash} as the \\.\aux device rather than a file path.

Changes:

  • Renamed socket files from aux.sock.{hash} to auxi.sock.{hash} in:
    • AuxiliaryBackchannelService.GetAuxiliaryBackchannelSocketPath()
    • AppHostHelper.ComputeAuxiliarySocketPath()
  • Added backward compatibility in AuxiliaryBackchannelMonitor:
    • Uses single wildcard pattern aux*.sock.* to match both auxi.sock.* (new) and aux.sock.* (old) formats
    • Extracts hash from both prefixes
    • Watches file system with single wildcard pattern for both formats
  • Added explanatory comments about Windows reserved device names
  • Added tests verifying new socket path format and backward compatibility
  • Updated test to use TestConstants.DefaultTimeoutTimeSpan for better debugging experience (disables timeout when debugger attached, provides clearer error messages with line numbers)

Checklist

  • Is this feature complete?
    • Yes. Ready to ship.
    • No. Follow-up changes expected.
  • Are you including unit tests for the changes and scenario tests if relevant?
    • Yes
    • No
  • Did you add public API?
    • Yes
    • No
  • Does the change make any security assumptions or guarantees?
    • Yes
    • No
  • Does the change require an update in our Aspire docs?
    • Yes
    • No
Original prompt

This section details on the original issue you should resolve

<issue_title>Unexpected startup error after 13.1 upgrade</issue_title>
<issue_description>### Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

I've just been testing upgrading a couple of projects from Aspire 13.0.2 -> 13.1.0

In both cases, I now get a startup error in AuxiliaryBackchannelService.
Never knowingly used this; looks to be something to do with MCP (neither project uses anything MCP related).

Doesn't seem to be breaking anything functional in my projects, but is throwing errors out at startup:

info: Aspire.Hosting.DistributedApplication[0] Aspire version: 13.1.0+8a4db1775c3fbae1c602022b636299cb04971fde info: Aspire.Hosting.DistributedApplication[0] Distributed application starting. info: Aspire.Hosting.DistributedApplication[0] Application host directory is: C:\..removed..\AppName.AppHost fail: Aspire.Hosting.Backchannel.AuxiliaryBackchannelService[0] Error in auxiliary backchannel service System.Net.Sockets.SocketException (10050): A socket operation encountered a dead network. at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName) at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at System.Net.Sockets.Socket.Bind(EndPoint localEP) at Aspire.Hosting.Backchannel.AuxiliaryBackchannelService.ExecuteAsync(CancellationToken stoppingToken) in /_/src/Aspire.Hosting/Backchannel/AuxiliaryBackchannelService.cs:line 58

Everything then carries on, but given I know nothing of this specific component, I'm unclear what the implications are. In any case, it probably shouldn't be doing that...

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

fail: Aspire.Hosting.Backchannel.AuxiliaryBackchannelService[0]
Error in auxiliary backchannel service
System.Net.Sockets.SocketException (10050): A socket operation encountered a dead network.
at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at Aspire.Hosting.Backchannel.AuxiliaryBackchannelService.ExecuteAsync(CancellationToken stoppingToken) in /_/src/Aspire.Hosting/Backchannel/AuxiliaryBackchannelService.cs:line 58

.NET Version info

10.0.101

Anything else?

No response</issue_description>

<agent_instructions>The relevant files are AppHostHelper.ComputeAuxiliarySocketPath and AuxiliaryBackchannelService.GetAuxiliaryBackchannelSocketPath, on windows < 11, the aux in the filename causes problems.

The CLI should support the older aux and the new auxi (new name for the back channel), leave a comment about windows < 10 not supporting the name aux because it is reserved.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@davidfowl What operating system ? @davidfowl Windows 10... @davidfowl At least it’s consistent (win10), do any of you have the aspire cli installed? @davidfowl Does aspire run work on these projects? @davidfowl Yes the error doesn't break anything in the core experience yet, not many parts of the system depend on it. We still need to figure out why it happens. I guess we'll need to setup a win10 environment... @davidfowl Seems like the problem is:

On Windows, these names are reserved from DOS days and can't be used as filenames:

  • CON, PRN, AUX, NUL
  • COM1-COM9, LPT1-LPT9

When you call File.Exists() on a path like aux.sock.xxxxx, Windows interprets it as the AUX device (\.\aux), not a file!

Works on windows 11 it seems 😬</comment_new>


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

- Changed socket filename from 'aux.sock.{hash}' to 'auxi.sock.{hash}' to avoid Windows reserved device name
- Added backward compatibility in CLI to support both 'aux.sock.*' and 'auxi.sock.*' patterns
- Added comments explaining Windows < 11 reserved name issue
- Added tests to verify the new socket path format and backward compatibility

Co-authored-by: davidfowl <95136+davidfowl@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix unexpected startup error after Aspire 13.1 upgrade Fix Windows startup error: AUX reserved device name in socket paths Dec 22, 2025
Copilot AI requested a review from davidfowl December 22, 2025 16:39
@github-actions
Copy link
Contributor

github-actions bot commented Dec 22, 2025

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 13688

Or

  • Run remotely in PowerShell:
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 13688"

@davidfowl
Copy link
Member

@copilot Implement the PR feedback

- Changed Directory.GetFiles to use "aux*.sock.*" pattern instead of separate patterns
- Changed fileProvider.Watch to use "aux*.sock.*" pattern instead of dual watchers
- Simplified code while maintaining backward compatibility

Co-authored-by: davidfowl <95136+davidfowl@users.noreply.github.com>
Copilot AI requested a review from davidfowl December 22, 2025 20:08
@davidfowl davidfowl marked this pull request as ready for review December 22, 2025 23:25
Copilot AI review requested due to automatic review settings December 22, 2025 23:25
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a critical Windows startup error where the auxiliary backchannel service crashes on Windows < 11 due to "AUX" being a reserved DOS device name. The fix renames socket files from aux.sock.{hash} to auxi.sock.{hash} while maintaining backward compatibility for older CLI versions that may still create aux.sock.* files.

Key changes:

  • Renamed socket file prefix from "aux.sock" to "auxi.sock" to avoid Windows reserved device name conflict
  • Added backward compatibility in CLI monitoring to detect both old and new socket file formats
  • Added comprehensive test coverage for new socket path format and Windows reserved name validation

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file
File Description
src/Aspire.Hosting/Backchannel/AuxiliaryBackchannelService.cs Updated socket path generation to use "auxi.sock" prefix with explanatory comment about Windows reserved names
src/Aspire.Cli/Utils/AppHostHelper.cs Updated socket path computation to use "auxi.sock" prefix matching the hosting change
src/Aspire.Cli/Backchannel/AuxiliaryBackchannelMonitor.cs Enhanced to support both "auxi.sock." and "aux.sock." patterns using wildcard matching for backward compatibility
tests/Aspire.Hosting.Tests/Backchannel/AuxiliaryBackchannelTests.cs Added test verifying new socket path uses "auxi.sock" prefix and file creation succeeds
tests/Aspire.Cli.Tests/Utils/AppHostHelperTests.cs New test file with comprehensive tests for socket path generation, hash consistency, and Windows reserved name avoidance
Comments suppressed due to low confidence (1)

src/Aspire.Cli/Backchannel/AuxiliaryBackchannelMonitor.cs:361

  • The backward compatibility logic in ExtractHashFromSocketPath lacks test coverage. This method now handles both "auxi.sock." and "aux.sock." prefixes, but there are no tests verifying that both formats are correctly parsed. Consider adding tests that verify:
  1. Hash extraction from "auxi.sock.{hash}" (new format)
  2. Hash extraction from "aux.sock.{hash}" (old format for backward compatibility)
  3. Null return for files not matching either pattern
        // Support both "auxi.sock." (new) and "aux.sock." (old) for backward compatibility
        if (fileName.StartsWith("auxi.sock.", StringComparison.Ordinal))
        {
            return fileName["auxi.sock.".Length..];
        }
        if (fileName.StartsWith("aux.sock.", StringComparison.Ordinal))
        {
            return fileName["aux.sock.".Length..];
        }
        return null;

- Replaced hardcoded TimeSpan.FromSeconds(60) with TestConstants.DefaultTimeoutTimeSpan
- Added using statement for Microsoft.AspNetCore.InternalTesting
- Provides better timeout behavior when debugging and clearer error messages

Co-authored-by: davidfowl <95136+davidfowl@users.noreply.github.com>
@astonfrancke
Copy link

Tested this on Windows NT 10.0.19045.0, works!

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.

Unexpected startup error after 13.1 upgrade

4 participants