Fatal error during running an app published with PublishSingleFile=true

[hoyosjs]

Fatal error. 0x80131506
   at System.Reflection.RuntimeModule.GetTypes(System.Reflection.RuntimeModule)
   at System.Reflection.RuntimeModule.GetTypes()
   at System.Reflection.Assembly.GetTypes()
   at Core.ServiceCollectionDependencyExtensions.AddDependencyServices(Microsoft.Extensions.DependencyInjection.IServiceCollection, System.Reflection.Assembly)
   at HostApp.Startup.ConfigureServices(Microsoft.Extensions.DependencyInjection.IServiceCollection)
   at System.RuntimeMethodHandle.InvokeMethod(System.Object, System.Object[], System.Signature, Boolean, Boolean)
   at System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)
   at Microsoft.AspNetCore.Hosting.ConfigureServicesBuilder.InvokeCore(System.Object, Microsoft.Extensions.DependencyInjection.IServiceCollection)
   at Microsoft.AspNetCore.Hosting.ConfigureServicesBuilder+<>c__DisplayClass9_0.<Invoke>g__Startup|0(Microsoft.Extensions.DependencyInjection.IServiceCollection)
   at Microsoft.AspNetCore.Hosting.ConfigureServicesBuilder.Invoke(System.Object, Microsoft.Extensions.DependencyInjection.IServiceCollection)
   at Microsoft.AspNetCore.Hosting.ConfigureServicesBuilder+<>c__DisplayClass8_0.<Build>b__0(Microsoft.Extensions.DependencyInjection.IServiceCollection)
   at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder.UseStartup(System.Type, Microsoft.Extensions.Hosting.HostBuilderContext, Microsoft.Extensions.DependencyInjection.IServiceCollection, System.Object)
   at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder+<>c__DisplayClass13_0.<UseStartup>b__0(Microsoft.Extensions.Hosting.HostBuilderContext, Microsoft.Extensions.DependencyInjection.IServiceCollection)
   at Microsoft.Extensions.Hosting.HostBuilder.CreateServiceProvider()
   at Microsoft.Extensions.Hosting.HostBuilder.Build()
   at HostApp.Program.Main(System.String[])

Originally posted by @xljiulang in #13590 (comment)

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[hoyosjs]

@hoyosjs Juan Sebastian Hoyos Ayala FTE
no, it happens whenPublishSingleFile at dotnet 5.0(prev8 and rc1)

Originally posted by @xljiulang in #13590 (comment)

[hoyosjs]

@xljiulang can you add some details here please? (type of application, possible steps to repro, output of dotnet --info)

Thanks!

[xljiulang]

@hoyosjs

my application type

 asp.net core

build script :

 dotnet publish -c Release -v m -o .\app -r win-x86 /p:version=%_version% /p:PublishSingleFile=true/p:PublishTrimmed=false/p:OutputBinType=WinExe

windows log

Application: 5kHostApp.exe
CoreCLR Version: 5.0.20.45114
.NET Version: 5.0.0-rc.1.20451.14
Description: The process was terminated due to an internal error in the .NET Runtime.at IP 7C789C0F (7C6E0000) with exit code 80131506.

dotnet info

.NET SDK (reflecting any global.json):
 Version:   5.0.100-rc.1.20452.10
 Commit:    473d1b592e

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.100-rc.1.20452.10\

Host (useful for support):
  Version: 5.0.0-rc.1.20451.14
  Commit:  38017c3935

.NET SDKs installed:
  2.1.801 [C:\Program Files\dotnet\sdk]
  3.1.100 [C:\Program Files\dotnet\sdk]
  3.1.201 [C:\Program Files\dotnet\sdk]
  3.1.402 [C:\Program Files\dotnet\sdk]
  5.0.100-rc.1.20452.10 [C:\Program Files\dotnet\sdk]

[ghost]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[agocke]

@xljiulang Are you sure this happens during dotnet publish, not when you run the binary after it's been published? That stack trace at the top looks like it's from the app when it's being run.

[xljiulang]

@agocke I mean whe my app use PublishSinggleFile is true mode, it happens when my app running.

[xljiulang]

@agocke
I found this code in my app, could this be an influence factor?

/// <summary>
/// 如果是在非调试状态
/// 则应用进程工作目录和ContentRoot为进程文件的目录
/// </summary>
/// <param name="hostBuilder"></param>
/// <returns></returns>
public static IHostBuilder UseBinPathEnvironment(this IHostBuilder hostBuilder)
{
    if (Debugger.IsAttached == false)
    {
        var binPath = Process.GetCurrentProcess().MainModule.FileName;
        Environment.CurrentDirectory = Path.GetDirectoryName(binPath);
        hostBuilder.UseContentRoot(Environment.CurrentDirectory);
    }

    return hostBuilder;
}

[xljiulang]

@hoyosjs
I have verified that this problem has nothing to do with Debugger.IsAttached，and i found the following windows log:

Application: 5kHostApp.exe
CoreCLR Version: 5.0.20.45114
.NET Version: 5.0.0-rc.1.20451.14
Description: The process was terminated due to an internal error in the .NET Runtime.at IP 7C789C0F (7C6E0000) with exit code 80131506.

[agocke]

Could you collect a crash dump with https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps?

[xljiulang]

@agocke
dmp file:
5kHostApp.exe.19236.dmp.zip

[hoyosjs]

Looks like in PEImage::CreateLayoutFlat(bPermitWriteableSections: FALSE) we get an invalid pFlatLayout from PEImageLayout::LoadFlat(this) and that causes an AV. The PEImage also looks like it's invalid, but going up the stack it feels like it's because the dump is missing some information. I can see the module being requested is 5kHostApp.dll with token 0x2300003a, but I don't know if the PEImage we get from it is valid.

[vitek-karas]

This could be #42402 - basically we were running out of virtual memory address space and a small bug lead to invalid pointers (instead of directly reporting OOM).
This only happens on 32bit OSes - on the bug exists on 64bit as well, but the VM space is so large that it never actually causes a failure. Given the above where the app is published for win-x86 seems like it.

Would it be possible to try the latest 5.0 build with this repro?

[agocke]

Assuming for now this was fixed in #42402