msbuild: MSBuild.exe spuriously dies with BadImageFormatException on BuildEnvironmentHelper.get_Instance()

Issue Description

I periodically get MSBuild failures. I previously reported a separate issue that was closed due to lack of reproducibility. However, this time, the Windows Event Log dump seems more helpful than previously. See Actual Behavior below.

Steps to Reproduce

I have no idea. Feeling a bit like Steve Martin in THE JERK right now just opening this ticket, but it needs fixing.

Expected Behavior

No Crashes

Actual Behavior

MSBuild.exe crashes. Windows Event Log has the following error messages:

Error	10/18/2021 7:28:28 PM	Application Error	1000	(100)
Faulting application name: MSBuild.exe, version: 16.10.2.30804, time stamp: 0xe420bb9d
Faulting module name: KERNELBASE.dll, version: 10.0.14393.4350, time stamp: 0x606eb12a
Exception code: 0xe0434352
Fault offset: 0x000dc602
Faulting process id: 0x4f18
Faulting application start time: 0x01d7c477dac329c3
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\MSBuild.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: e3f0efcd-1087-488f-a7be-497ecb67a096
Faulting package full name: 
Faulting package-relative application ID:

Error	10/18/2021 7:28:28 PM	.NET Runtime	1026	None
Application: MSBuild.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.BadImageFormatException
   at Microsoft.Build.Shared.BuildEnvironmentHelper.get_Instance()
   at Microsoft.Build.Utilities.Traits.get_Instance()
   at Microsoft.Build.CommandLine.MSBuildApp.Execute(System.String)
   at Microsoft.Build.CommandLine.MSBuildApp.Main()

Error	10/18/2021 7:27:58 PM	Application Error	1000	(100)
Faulting application name: MSBuild.exe, version: 16.10.2.30804, time stamp: 0xe420bb9d
Faulting module name: KERNELBASE.dll, version: 10.0.14393.4350, time stamp: 0x606eb12a
Exception code: 0xe0434352
Fault offset: 0x000dc602
Faulting process id: 0x3e60
Faulting application start time: 0x01d7c477c8e27647
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\MSBuild.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 89447d74-5d51-4095-8f31-0aeae7ea35ae
Faulting package full name: 
Faulting package-relative application ID:

Error	10/18/2021 7:27:58 PM	.NET Runtime	1026	None
Application: MSBuild.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.BadImageFormatException
   at Microsoft.Build.Shared.BuildEnvironmentHelper.get_Instance()
   at Microsoft.Build.Utilities.Traits.get_Instance()
   at Microsoft.Build.CommandLine.MSBuildApp.Execute(System.String)
   at Microsoft.Build.CommandLine.MSBuildApp.Main()

Analysis

It might be inside BuildEnvironmentHelper.Instance property. There are 5 places inside MSBuildApp that call this helper Instance property, see https://github.com/dotnet/msbuild/blob/bbb9655b007be6d079985f3a7ec14f5d82a18f64/src/MSBuild/XMake.cs

Versions & Configurations

MSBuild.exe, version: 16.10.2.30804

Attach a binlog

How do I attach a binlog if most often the process that crashes is a background process created by VS Tools? https://docs.microsoft.com/en-us/visualstudio/msbuild/obtaining-build-logs-with-msbuild?view=vs-2019 is actually not at all helpful in this regard.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (6 by maintainers)

Most upvoted comments

That explanation seems plausible. I’m assuming it was originally written that way to try to have neat code, but it would be cleaner (in my opinion) like:

BuildEnvironment env = TryFromEnvironmentVariable() ??
                           TryFromVisualStudioProcess() ??
                           TryFromMSBuildProcess() ??
                           TryFromDevConsole() ??
                           TryFromSetupApi() ??
                           TryFromAppContextBaseDirectory();

if (env is not null)
{
    return env;
}
...

If you also have get_Instance check whether it was already initialized and return if so, else Initialize(), I think it would have the added benefit of giving you a more complete call stack, which should help with figuring out what the real root of this problem is. It might be worth trying that with your repro.

Forgind on Oct 27, 2021