Unable to load custom VsDbg extensions in linux/WSL using VS 17.7 Preview

[sae42]

Using VS 17.7 Preview 1, WSL/Ubuntu linux 22.04. .NET Runtime 6.0.16. VsDbg version.txt 17.6.10401.3 commit:2b6b7003009fd737853b727ff5723629d01c281d

Start WSL debugging from VS gives an immediate fail about launching the debug adapter.

Running ./vsdbg/vsdbg from the linux box gives:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.SpanHelpers.IndexOf(Char ByRef, Char, Int32)
at System.String.Ctor(Char*)
at VsDbg.EntryPoint.GetAssemblyDirectories(IntPtr)
at VsDbg.EntryPoint.Initialize(IntPtr)
Aborted

It seems that any directory specified in a .link file for VsDbg extensions (e.g. ~/.dotnet/vsdbg-extensions/any.link) will cause this fail as long as the .link file contains a valid absolute directory (the directory itself can be totally empty) so I'm not sure this issue is anything to do with the VsDbg extension itself.

Any help with diagnosing the issue appreciated!

[gregg-miskelly]

I think I see the issue. Let me get you a private build to confirm.

[gregg-miskelly]

Here are the new getvsdbg scripts to test:

https://vsdebugger.blob.core.windows.net/vsdbg-17-6-10606-1/GetVsDbg.ps1
https://vsdebugger.blob.core.windows.net/vsdbg-17-6-10606-1/GetVsDbg.sh

[sae42]

Thanks @gregg-miskelly - this fixes it for me. Out of curiosity, what was the underlying issue?

[gregg-miskelly]

We refactored an initialization code path in the native code that calls this that lead to freeing the native array before we were done processing it. Unfortunately, in our tests, we were getting "lucky" and nothing was reclaiming this memory between the free and use point, so nothing caught the bug.

[sae42]

Ah, interesting - that may explain why this problem seemed intermittent across different machines/OSs.

[gregg-miskelly]

aka.ms links have been updated. I will resolve this once it is also inserted into the VS Code C# extension.