Visual studio is crashing when using self builded Hostfxr

[ArthurVasseur]

I cloned the repository (checked out on v9.0.0) and ran .\build.cmd to build the entire project.

In my personal project, I am dynamically loading the hostfxr library using the path: dotnet/runtime/artifacts/obj/Microsoft.NETCore.App.Bundle/Debug/net9.0/win-x64/output/host/fxr/9.0.0/hostfxr.dll

In the project settings, I configured the debugger type to Mixed (.NET Core)
However, Visual Studio crashes when the following function call is executed: hostFxrGetRuntimeDelegate(_hostfxrHandle, hdt_get_function_pointer, &function);

Faulting Application Name devenv.exe, Version: 17.11.35303.130, Timestamp: 0x66d77afb
Faulting Module Name: mscordbi.dll, Version: 42.42.42.42424, Timestamp: 0x67689277
Exception Code: 0xc0000602
Error Offset: 0x000000000017fb69
Faulting Process ID: 0x0x8E2C
Faulting Application Start Time: 0x0x1DB54C71094C641
Faulting Application Path: D:\Program Files\VisualStudio\Common7\IDE\devenv.exe
Faulting Module Path: C:\Users\arthu\AppData\Local\Temp\SymbolCache\mscordbi.dll\676890D76dc000\mscordbi.dll
Report ID: a3259212-cd2d-4817-bd8a-acbdd561e1ea
Full Faulting Package Name: 
Application ID relative to faulting package:

This is my program output:

Assert failure(PID 5892 [0x00001704], Thread: 21524 [0x5414]): HasReturnFrame(true)

CORECLR! ControllerStackInfo::GetStackInfo + 0x24E (0x00007ffb`175c44fe)
CORECLR! DebuggerStepper::Step + 0x276 (0x00007ffb`175cf246)
CORECLR! Debugger::HandleIPCEvent + 0x122F (0x00007ffb`175ff07f)
CORECLR! `HandleIPCEventWrapper'::`3'::__Body::Run + 0x66 (0x00007ffb`1764d836)
CORECLR! HandleIPCEventWrapper + 0x75 (0x00007ffb`1764b2e5)
CORECLR! DebuggerRCThread::HandleRSEA + 0x487 (0x00007ffb`1764b7f7)
CORECLR! DebuggerRCThread::MainLoop + 0x92D (0x00007ffb`1764ccfd)
CORECLR! DebuggerRCThread::ThreadProc + 0x834 (0x00007ffb`1764fb44)
CORECLR! DebuggerRCThread::ThreadProcStatic + 0x9E (0x00007ffb`1764fc9e)
KERNEL32! BaseThreadInitThunk + 0x1D (0x00007ffc`2e5c259d)
    File: E:\Documents\git\dotnet\runtime\src\coreclr\debug\ee\controller.cpp:341
    Image: E:\Documents\git\ConcertoEngine\ConcertoDotNet\build\windows\x64\debug\concerto-dotnet-sample.exe

[dotnet-policy-service]

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

[tommcdon]

Hello @ArthurVasseur! When debugging managed code, VS will load the .NET debugging services binaries ( mscordbi.dll and mscordaccore.dll) built with the coreclr that is being loaded into the debuggee process. When debugging a debug version of the runtime, any asserts that fire mscordbi.dll or mscordaccore.dll can cause the VS process to crash (due to an unhandled break instruction). My guess is that the assert that is firing on the debuggee side triggered another assert in either mscordbi.dll or mscordaccore.dll.

There are a few potential workarounds:

• Use a release build which contains no asserts - e.g. build the runtime with build clr -c release
• Or, try disabling asserts by setting DOTNET_ContinueOnAssert=1. Note this environment variable would need to be set in the VS process itself. This can be done by setting the variable from a developer command prompt, then running devenv.exe from the same prompt (causing it to inherit the environment variable).
• Or, try commenting out the assert. Note this might be an iterative process, as disabling one assert might lead to another assert later in code execution.

In addition to the above, it's possible to debug the assert occurring in VS by attaching a second instance of VS to the 1st VS that is crashing.

Hope this helps!

[ArthurVasseur]

Hello @tommcdon, thanks for your answer!

Thanks for the explanaition about mscordbi,

Setting DOTNET_ContinueOnAssert=1 turned out to be the easiest solution, and I also successfully attached a VS instance to the first VS. Interestingly, with the debugger attached, the first instance no longer seems to crash.

Happy Holidays!