Winforms: [5.0.101] Published single file binary crashes on startup with 0x80070002 in EnableVisualStyles()

[xPaw]

• .NET Core Version:
  
  5.0.101

• Have you experienced this same bug with .NET Framework?:
  
  No

Problem description:

Publishing a single file binary produces a binary that just crashes on startup when launched from explorer. Launching cmd and then starting the exe from there, actually runs.

Not publishing for single file also works correctly.

This worked on 5.0.0 release.

System.IO.FileNotFoundException

The system cannot find the file specified. (0x80070002)

Expected behavior:
App works

Minimal repro:

1. Clone https://github.com/SteamDatabase/ValveResourceFormat
2. cd GUI && dotnet publish

We have builds on appveyor as well (GUI.zip) that are broken: https://ci.appveyor.com/project/xPaw/valveresourceformat/builds/36727211/artifacts

---

I created this issue in winforms because I suspect https://github.com/dotnet/winforms/pull/4177 could be the culprit. If not, could this be moved to runtime repo please.

[JeremyKuhne]

I'm having problems reproducing this. Can you provide a call stack for the exception?

[xPaw]

It does not give a stacktrace.

Download the zip from appveyor and click the exe. I had multiple people report this issue, and I get it myself too.

Using Windows 10.0.19042 Build 19042

[willibrandon]

I'm unable to reproduce this issue as well. I've tried both cloning, cd GUI, and dotnet publish as well as downloading the zip from appveyor and launching VRF.exe from explorer. Both result in VRF launching successfully.

Using Windows Version 20H2 (OS Build 19042.685).

[xPaw]

I don't get it. I downloaded it from appveyor again, and it did indeed run. I tried to publish locally, and it produced an error.

Is there some intermidiate issue with this, like temp folder extraction or something? How can I get it to produce a stacktrace?

Side note: on your screenshot, the winforms appear to not use modern styles, but it should have been fixed in 5.0.1?

[willibrandon]

Okay, now I am able to reproduce this issue.

I agree, it appears to be somewhat intermittent.

Application: VRF.exe
CoreCLR Version: 5.0.120.57516
.NET Version: 5.0.1
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException: The system cannot find the file specified. (0x80070002)
at System.Reflection.RuntimeModule.GetFullyQualifiedName()
at System.Reflection.RuntimeModule.get_Name()
at System.Windows.Forms.Application.EnableVisualStyles()
at GUI.Program.Main()

[xPaw]

So my assumption about #4177 appears to be correct? How did you get the stacktrace by the way?

[willibrandon]

@xPaw Your assumption could be correct. I think someone on the team will confirm. I got the stacktrace from the Event Viewer -> Application logs.

[JeremyKuhne]

Looks like there might be a race condition in the .NET runtime. Looking...

For startup crashes like this I often use WinDbg to launch existing exes. You can do it with VS as well by temporarily setting the startup for the project in the properties to be the published exe.

[JeremyKuhne]

@vitek-karas / @agocke any idea why this would happen _intermittently_ in single file?

``` C#
Module module = typeof(Application).Module;
IntPtr moduleHandle = Kernel32.GetModuleHandleW(module.Name);

CoreCLR Version: 5.0.120.57516
.NET Version: 5.0.1
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException: The system cannot find the file specified. (0x80070002)
at System.Reflection.RuntimeModule.GetFullyQualifiedName()
at System.Reflection.RuntimeModule.get_Name()
```

@xPaw Setting the IncludeAllContentForSelfExtract property to true in your project should work around this issue. Can you try this please?

[xPaw]

Setting the IncludeAllContentForSelfExtract property to true in your project should work around this issue. Can you try this please?

Appears to have helped, although it is slower because it has to extract into temp (afaik).

[JeremyKuhne]

@xPaw Another workaround you can do is remove the call to Application.EnableVisualStyles() and set via manifest instead: https://github.com/dotnet/winforms/issues/4145#issuecomment-714028387. This will allow you to use the new packaging method.

Fyi: We'll definitely root cause the problem and fix it, but I suspect it is unlikely that we'll get approval to service it for 5.0 as there are workarounds.

[xPaw]

and set via manifest instead

I put it into app.config, it got copied into bin, but I am still getting old styles.
EDIT: managed to get it to work

but I suspect it is unlikely that we'll get approval to service it for 5.0

Well 5.0.0 release worked, but failed to apply styles, 5.0.1 crashes. Does that not warrant a fix for 5.0 release?

[JeremyKuhne]

Well 5.0.0 release worked, but failed to apply styles, 5.0.1 crashes.

I double checked it myself and it does work for me- presuming your edit applies to both statements and you can get the manifest to work and not use <IncludeAllContentForSelfExtract>?

Does that not warrant a fix for 5.0 release?

The bar is pretty high, they might take it, but I wouldn't be surprised if they don't as there are multiple workarounds. Even one workaround would make it hard to get through.

[xPaw]

you can get the manifest to work and not use IncludeAllContentForSelfExtract?

Correct. https://github.com/SteamDatabase/ValveResourceFormat/commit/a7d07725cc23b9b47bd2302cfcbdc2411dc5a0a0

[vitek-karas]

This is basically a duplicate of https://github.com/dotnet/runtime/issues/40103.
(The underlying problem is that the property should return <Unknown> which is a resource string, but single-file doesn't contain resources for the runtime - trying to load that resource throws the exception).

I honestly don't see how this ever worked after https://github.com/dotnet/winforms/pull/4149 in single-file since the fact that Module.FullyQualifiedName throws in single-file has been there from the beginning of true single file - so somewhere around .NET 5 Preview 8.