MSbuild crashes when run inside terminal

[rainersigwald]

---

Issue moved from microsoft/terminal#16489

• Please respond to @gilknyaz.

---

From @gilknyaz on Thursday, December 21, 2023 2:13:21 PM

Windows Terminal version

1.18.3181

Windows build number

10.0.22621.0

Other Software

MSBuild (VS 2022)

Steps to reproduce

1. Open the Developer Command Prompt for VS 2022 profile.
2. go to a C# solution folder
3. Run MSbuild to compile. (Or run msbuild /t:Restore to restore some nuget packages)

Expected Behavior

MSbuild to succeed

Actual Behavior

MSBuild starts working but stops very early. No error is written to the console.
In Event Viewer -> Application, the following error appears:

Faulting application name: MSBuild.exe, version: 17.8.3.51904, time stamp: 0xe31ab667
Faulting module name: combase.dll, version: 10.0.22621.2792, time stamp: 0xd9671289
Exception code: 0xc0000409
Fault offset: 0x00000000001522b2
Faulting process id: 0x0x6380
Faulting application start time: 0x0x1DA34154F6EE43B
Faulting application path: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\amd64\MSBuild.exe
Faulting module path: C:\WINDOWS\System32\combase.dll
Report Id: 4af61e29-3040-4862-b67c-0fb2c7a14aef
Faulting package full name: Microsoft.WindowsTerminal_1.18.3181.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App

[rainersigwald]

---

Issue moved from microsoft/terminal#16489

• Please respond to @zadjii-msft.

---

From @zadjii-msft on Wednesday, January 3, 2024 3:48:32 PM

@rainersigwald any ideas? Or any idea how to investigate? Does this work just fine in the vintage console/?

[rainersigwald]

---

Issue moved from microsoft/terminal#16489

• Please respond to @rainersigwald.

---

From @rainersigwald on Thursday, January 4, 2024 10:37:31 PM

I haven't heard of this before. Since you have VS installed, you might be able to get more information by setting the environment variable MSBUILDDEBUGONSTART=1 before running MSBuild, which should pop up a JIT debugger prompt. Then the crash might have a bit more actionable information?

[rainersigwald]

---

Issue moved from microsoft/terminal#16489

• Please respond to @gilknyaz.

---

From @gilknyaz on Friday, January 5, 2024 2:23:12 PM

@zadjii-msft @rainersigwald
MSBuild.001.zip
MSBuild.002.zip

I've uploaded the dump created with MSBUILDDEBUGONSTART
It's split because github doesn't allow more than 25MB per-file. Please rename them to MSBuild.zip.001 and MSBuild.zip.002 to open.

Another thing that might explain the difference - it happens to me on a Virtual Desktop machine. (VMWare VDI). Doesn't happen on a regular PC.

[rainersigwald]

---

Issue moved from microsoft/terminal#16489

• Please respond to @zadjii-msft.

---

From @zadjii-msft on Wednesday, January 10, 2024 10:25:44 PM

@rainersigwald Hey can you investigate this more on your side? Or move this to the msbuild repo? I can't imagine that this is something that is really caused by Terminal code... but if this is something that explodes in msbuild cause we're running, I think you'd be best equipped to find out why

[rainersigwald]

@gilknyaz, sorry it took us a bit to get to this. It looks like your dump was taken right after the initial breakpoint, at which time the process looks healthy. If you get a chance, can you do the same again but this time let the process run (F5) after that initial breakpoint until it crashes, then share that dump?

[gilknyaz]

MSBuild.exe.28408.003.zip
MSBuild.exe.28408.001.zip
MSBuild.exe.28408.002.zip

Hi @rainersigwald, the process crashed instead of stopping at a .net exception, but I managed to get a dump by configuring WER.

I've uploaded the new dump, please rename the files as I've explained above.

[YuliiaKovalova]

MSBuild.exe.28408.003.zip MSBuild.exe.28408.001.zip MSBuild.exe.28408.002.zip

Hi @rainersigwald, the process crashed instead of stopping at a .net exception, but I managed to get a dump by configuring WER.

I've uploaded the new dump, please rename the files as I've explained above.

Thank you for the provided dump!

According to the callstack , the crush happens because the instance of Microsoft.WindowsTerminal v 1.18.3181.0 can't be created.
The invocation of the terminal is initiated by Microsoft.DotNet.MSBuildSdkResolver.dll!Microsoft.DotNet.DotNetSdkResolver.VSSettings.VSSettings() Line 41

and fails on combase.dll!PackageFilter::PackageFilter(wil::unique_any_array_ptr<PACKAGE_INFO,PrivMemDeleter,wil::empty_deleter> && packageInfoArray) Line 189 C++
@joeloff can this topic be something you are experienced in?

[rainersigwald]

Moving to SDK based on the analysis above. I see a catch(COMException) but maybe it's insufficient?

[KalleOlaviNiemitalo]

According to the callstack , the crush happens because the instance of Microsoft.WindowsTerminal v 1.18.3181.0 can't be created.

Strange that it'd create an instance of Microsoft.WindowsTerminal. Does the PATH environment variable of the process include the Windows Terminal directory, so that the Visual Studio interop could pick up some unexpected settings from there? There was a bug that could cause that in the PATH (microsoft/terminal#7204); it was ostensibly fixed but I don't know the exact version.