.net-core.net-8.0

Updating from .NET 8.0.410 SDK to .NET 8.0.411 SDK causes error -2147450749 when running from UNC path

I have a self contained exe and when I publish it with .NET 8.0.410 SDK, it works as expected.

Publish

publish-8-0-410

Output:

output-8-0-410

But when I publish it with .NET 8.0.411 SDK, it doesn't return anything. Checking the error code, it returns exit code -2147450749.

Publish:

publish-8-0-411

Run (on UNC):

run-unc-8-0-411

When I copy the code locally, it does return data when I run it:

run-local-8-0-411

I'm not seeing any errors in event viewer and I'm not seeing anything useful searching google, so I'm somewhat at a loss for why this is happening and how to fix it. Is there a debugging command or something that I can run? or is this a known issue with .NET SDK 8.0.411?

I don't think it's related to my working directory, since for every example, my working directory contains the locally copied down version of the .NET SDK 8.0.411 code (since I can't really set the working directory to be an UNC path through command line)

Updates per comments:
Minimally reproducible example:
https://github.com/AlexanderBrehm-hps/stackoverflow-79686435#

program.cs:

// See https://aka.ms/new-console-template for more information
try
{
  Console.WriteLine("Hello, World!");
}
catch (Exception e)
{
  Console.WriteLine($"Exception: {e.Message}");
}

4.10 Build and Output enter image description here enter image description here 4.11 Build and Output enter image description here enter image description here

The server that I'm running the code on does not have .net installed, so there should be no dotnet installations already installed on it which could be messing with my testing. I tried to add a try catch, and it wasn't able to catch anything, screenshots above.

output from dotnet trace (running from a machine that has .net installed since dotnet-trace requires .net). The share is hosted on the machine, and the the first call in the screenshot shows it works when being ran locally. enter image description here

Solution

  • This was related to github.com/dotnet/runtime/issues/116521 and has been fixed in the latest release.