search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.59k stars 1.03k forks source link

MSbuild crashes when run inside terminal #38742

Open rainersigwald opened 5 months ago

rainersigwald commented 5 months ago

Issue moved from microsoft/terminal#16489

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 commented 5 months ago

Issue moved from microsoft/terminal#16489

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 commented 5 months ago

Issue moved from microsoft/terminal#16489

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 commented 5 months ago

Issue moved from microsoft/terminal#16489

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 commented 5 months ago

Issue moved from microsoft/terminal#16489

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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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 image

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 commented 4 months ago

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

KalleOlaviNiemitalo commented 4 months ago

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 (https://github.com/microsoft/terminal/issues/7204); it was ostensibly fixed but I don't know the exact version.