GenerateBundle Task fails writing to singlefilehost.exe

[dsplaisted]

Build Information

Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=1146095
Build error leg or test failing: Microsoft.NET.Publish.Tests.dll.6.WorkItemExecution
Pull request: #50648

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "",
  "ErrorPattern": "The process cannot access the file '.*singlefilehost\\.exe' because it is being used by another process",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1146095
Error message validated: [The process cannot access the file '.*singlefilehost\.exe' because it is being used by another process]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 9/12/2025 3:27:55 PM UTC

Report

Build	Definition	Test	Pull Request
1218206	dotnet/sdk	Microsoft.NET.Publish.Tests.dll.6.WorkItemExecution	#51847
1216834	dotnet/sdk	Microsoft.NET.Publish.Tests.dll.6.WorkItemExecution	#51847
1213145	dotnet/sdk	Microsoft.NET.Publish.Tests.dll.6.WorkItemExecution	#51847

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	3

[dsplaisted]

@dotnet/illink @agocke We are seeing failures where the GenerateBundle task is failing because it cannot access the singlnefilehost.exe file. We added retry logic because we thought maybe the issues were caused by defender. I thought that helped, but now the issue is happening pretty consistently, so it may be a product issue.

Interestingly, it seems to only fail on Mac OS and Linux when bundling a Windows app. I can't remember if it was failing on Windows before we added the retry logic or not.

Can someone investigate this?

I'm also wondering whether we should merge this codeflow PR which is blocked by the failure. That's where I've seen the failure most consistently recently, so it's possible there's a code change coming in that made the problem worse.

[agocke]

@jtschuster can you take a look?

[dsplaisted]

Ping @jtschuster, any progress on this? I just noticed it in #50876

[agocke]

I'm going to load balance a bit. @sbomer can you look instead?

[jtschuster]

Still investigating, but I am able to repro locally on a mac, but only on the first run of the test. Subsequent runs use the same path for the tmp project and don't repro. It's also interesting that it's failing on a read and not a write.

[dsplaisted]

@jtschuster Any update on this? This is impacting a bunch of our CI runs.

[jtschuster]

Still investigating exactly what's going on, but my hunch is that there's an async memory map flush that keeps the apphost mapped from CreateAppHost. In particular it looks like this todo might fix the issue: https://github.com/dotnet/runtime/blob/b8c39cc4d102518f8608df70e6e3cb7a5c10d48d/src/installer/managed/Microsoft.NET.HostModel/AppHost/HostWriter.cs#L172
The ResourceUpdater.Update() maps the destination apphost back into memory, and if there's async flushing after Dispose(), we could run into issues.

As a workaround, it looks like adding --disable-build-servers to the PublishCommand.Execute() method does something to make the issue fail to repro for both me and @sbomer. I'm not sure why, though.