.NET 9 published app fails to start (while in coreclr.dll)

[Red-K0]

Running a .NET WinForms application published using the below settings causes the application to seemingly fail to start.

<Configuration>Release</Configuration>
<Platform>Any CPU</Platform>
<PublishDir>bin\publish-framework\</PublishDir>
<PublishProtocol>FileSystem</PublishProtocol>
<_TargetId>Folder</_TargetId>
<TargetFramework>net9.0-windows10.0.19041.0</TargetFramework>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<SelfContained>false</SelfContained>
<PublishSingleFile>true</PublishSingleFile>
<PublishReadyToRun>true</PublishReadyToRun>

Running under Visual Studio's debugger, the following message is reported:

Unhandled exception at 0x00007FFD00C75152 (coreclr.dll) in Application.exe: 0xC0000602:  A fail fast exception occurred. Exception handlers will not be invoked, and the process will be terminated immediately.

At corehost.cpp, line 225:
rc = hostfxr_main_bundle_startupinfo(argc, argv, host_path_cstr, dotnet_root_cstr, app_path_cstr, bundle_header_offset);

The process then immediately exits, leaving an APPCRASH event in Event Viewer. This does not happen when the application is published as single-file or is run in standard release/debug. While the app uses WinForms, given it never gets to the application code before it crashes, submitting here instead.

[agocke]

@elinor-fung can you take a look?

[elinor-fung]

@Red-K0 would you be able to provide a dump of the crash?

Also, what version of Windows are you running on? Can you check that your OS is updated the latest patches? Some Windows versions had issues with CET (enabled by default in .NET 9) that were patched in servicing updates - see #108589, #110920

This does not happen when the application is published as single-file or is run in standard release/debug

The config snippet shows PublishSingleFile is true. Do you mean the crash does not happen when not published as single-file? By standard release/debug, are you referring to running the build output (as opposed to the publish output)?

[Red-K0]

Mistake on my end, I meant self-contained not single file. It only crashes when framework dependent. I'm running Windows 10 build 19045.5440, all updates installed. Standard release/debug is build output yes. Would you prefer a full or mini dump?

[Red-K0]

@elinor-fung (forgot to tag in reply)

[elinor-fung]

@Red-K0 full dump, please.

Could you also share the output of dotnet --info?

[Red-K0]

dotnet --info output:

.NET SDK:
 Version:           9.0.200-preview.0.24575.35
 Commit:            81b5f040be
 Workload version:  9.0.200-manifests.8206ae8f
 MSBuild version:   17.13.0-preview-24569-04+8f6b8ad0a

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.200-preview.0.24575.35\

.NET workloads installed:
 [wasm-tools]
   Installation Source: VS 17.13.35617.110
   Manifest Version:    9.0.1/9.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.current\9.0.1\WorkloadManifest.json
   Install Type:              Msi

 [aspire]
   Installation Source: VS 17.13.35617.110
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.1
  Architecture: x64
  Commit:       c8acea2262

.NET SDKs installed:
  9.0.102 [C:\Program Files\dotnet\sdk]
  9.0.200-preview.0.24575.35 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

And the full dump can be found here. I can also provide a PDB / source code if that would help.

[elinor-fung]

Thanks, @Red-K0.

The runtime is raising a fail fast trying to open an R2R image

runtime/src/coreclr/vm/nativeimage.cpp

Line 222 in 5f652c2

RaiseFailFastException(nullptr, nullptr, 0);

 	ntdll.dll!RtlRaiseNoncontinuableException()	Unknown
 	KERNELBASE.dll!RaiseFailFastException()	Unknown
>	coreclr.dll!NativeImage::Open(Module * componentModule, const char * nativeImageFileName, AssemblyBinder * pAssemblyBinder, LoaderAllocator * pLoaderAllocator, bool * isNewNativeImage) Line 226	C++
 	coreclr.dll!AssemblyBinder::LoadNativeImage(Module * componentModule, const char * nativeImageName) Line 39	C++
 	coreclr.dll!ReadyToRunInfo::Initialize(Module * pModule, AllocMemTracker * pamTracker) Line 567	C++
 	coreclr.dll!Module::Initialize(AllocMemTracker * pamTracker, const wchar_t * szName) Line 433	C++
 	coreclr.dll!Module::DoInit(AllocMemTracker * pamTracker, const wchar_t * szName) Line 153	C++
 	coreclr.dll!Module::Create(Assembly * pAssembly, PEAssembly * pPEAssembly, AllocMemTracker * pamTracker) Line 584	C++
 	coreclr.dll!Assembly::Init(AllocMemTracker * pamTracker, LoaderAllocator * pLoaderAllocator) Line 194	C++
 	coreclr.dll!Assembly::Create(PEAssembly * pPEAssembly, DebuggerAssemblyControlFlags debuggerFlags, int fIsCollectible, AllocMemTracker * pamTracker, LoaderAllocator * pLoaderAllocator) Line 343	C++
 	...

The issue is that the Honey.dll indicates it is a component of a composite R2R assembly (that is, its flags have READYTORUN_FLAG_COMPONENT set), so the runtime looks for a corresponding Honey.r2r.dll. Composite R2R is only supported for self-contained applications, so that will not and should not exist. When the runtime can't find it, it raises the fail fast.

It seems like there's something going wrong during SDK publishing of the app. Like it is using some stale Honey.dll from a previous publish for self-contained, composite R2R. Do you (or did you) have composite R2R (PublishReadyToRunComposite) enabled? When publishing, is your project set to only publish without building (NoBuild property or --no-build command line argument)?

Could you:

1. Share a binlog of the publish
2. Clean the project's build/publish/intermediate output
3. Build/publish/run the published app again

[Red-K0]

Currently can't provide a binlog (I should be able to provide one soon), but composite R2R is not enabled, and it does reproduce even after cleans. No flags are being passed to the compiler outside of what VS normally passes in publish.

[Red-K0]

I should clarify, stale publishing can be ruled out, when this bug occurred the project had never been published beforehand.

[Red-K0]

After a rebuild to attempt to extract a binlog, it seems to work now with no config changes.