This is a bit unusual, so let me try and explain.

I have a go program running in vscode, it dynamically loads a dll (this is all in windows) and calls function in it. I’d like to debug the vscode go program, and then when a breakpoint in the dll is hit in the visual studio debugger, it stops on that breakpoint in visual studio.

The first thing chatgpt suggests is having visual studio attach to the running vscode child debuggee process. That doesn’t work because it says “there is already a debugger attached to that process.”

So I tried a trick I learned a long long time ago which used to work long before the advent of go and vscode.

I run vscode as the debuggee process in the visual studio debugger.

This seems to start to work, visual studio will fire up vscode and I can start debugging my go program, but the visual studio debugger doesn’t recognize the vscode process as loading my dll, and it disables all the breakpoints in the visual studio dll debugger, and while the go program runs and calls the dll functions, it’s clearly not the same instance that visual studio’s debugger had loaded and has breakpoints for.

This makes sense, as vscode itself is not loading my dll, it’s the child process of vscode that is being debugged that is loading the dll, and I’m guessing that disconnect is part of the problem.

I tried a few things like starting vscode with -r to reuse the window, but that just causes the debuggee vscode process to exit right away once it has sent focus to the existing vscode instance.

Is there any way to get this to work?
I was hoping that since the debuggee is a child process of the vscode executable being debugged by visual studio’s debugger, I thought it might inherit access or whatever it is that the visual studio debugger looks for when attaching the dll.

Any suggestions? Ideas? esoteric visual studio options I can select?

Thanks.