Debug: Variable values are not shown

[skurth]

I've a problem that variable values are not shown. Debugging (stepping with F10, breakpoints) works correctly, but when I hover a variable, the value is not shown. Also the variables are not shown in "Watch" area:

launch.json:
{ "version": "0.2.0", "configurations": [ { "name": ".NET Core Launch (console)", "type": "coreclr", "request": "launch", "preLaunchTask": "build", "program": "${workspaceFolder}/bin/Debug/net10.0-windows/VBNetTestApp.exe", "args": [], "cwd": "${workspaceFolder}", "stopAtEntry": false, "console": "internalConsole", "justMyCode": false, "requireExactSource": false, "env": { "DOTNET_MODIFIABLE_ASSEMBLIES": "debug" } } ] }

tasks.json:
{ "version": "2.0.0", "tasks": [ { "label": "build", "command": "dotnet", "type": "shell", "args": [ "build", "${workspaceFolder}/VBNetTestApp.vbproj", "/p:Configuration=Debug", "/property:GenerateFullPaths=true", "/consoleloggerparameters:NoSummary" ], "group": { "kind": "build", "isDefault": true }, "presentation": { "reveal": "silent" }, "problemMatcher": "$msCompile" } ] }

Can you help me what I'm missing?

[govert]

Thanks a lot for testing the extension and for the detailed report.

One likely cause is the debug adapter type in your launch.json: it currently uses "type": "coreclr", which starts the C# debugger stack, not this extension’s debugger.

Could you try switching to "type": "vbnet" and retry? For example:

{
  "name": "VB.NET Launch",
  "type": "vbnet",
  "request": "launch",
  "projectPath": "${workspaceFolder}/VBNetTestApp.vbproj",
  "cwd": "${workspaceFolder}",
  "stopAtEntry": false
}

If variable hover/watch values are still missing with type: vbnet, please share that updated launch.json and we’ll continue from there.

Posted by Codex agent on behalf of @govert.

[skurth]

@govert

Thank you very much for your help.

When testing with a console app, everything works fine with vbnet:

In a WinForms app, after changing the type to vbnet, the app hangs as it reaches the first break-point, but break-point is not "activated" in VS Code.

launch.json (I've tried it with different configurations):

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "VB.NET Launch 2",
            "type": "vbnet",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/net10.0-windows/VBNetTestApp.exe",
            "args": [],
            "cwd": "",
            "console": "internalConsole",
            "stopAtEntry": false
        },
        {
            "name": "VB.NET Launch",
            "type": "vbnet",
            "request": "launch",
            "preLaunchTask": "build",
            "projectPath": "${workspaceFolder}/VBNetTestApp.vbproj",
            "cwd": "${workspaceFolder}",
            "stopAtEntry": false
        },
        {
            "name": ".NET Core Launch (console)",
            "type": "vbnet",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/net10.0-windows/VBNetTestApp.exe",
            "args": [],
            "cwd": "${workspaceFolder}",
            "stopAtEntry": false,
            "console": "integratedTerminal"
        },
        {
            "name": "Test coreclr",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/net10.0-windows/VBNetTestApp.exe",
            "args": [],
            "cwd": "${workspaceFolder}",
            "stopAtEntry": false,
            "console": "internalConsole",
            "justMyCode": false,
            "requireExactSource": false,
            "env": {
                "DOTNET_MODIFIABLE_ASSEMBLIES": "debug"
            }
        }
    ]
}

WinForms test app:

VBNetTestApp.zip

[govert]

Thanks for the sample and detailed update. I tried to reproduce this locally with your VBNetTestApp.zip.

I tested directly at DAP level (netcoredbg --interpreter=vscode) with a vbnet launch config equivalent to yours, and here is what I saw:

• WinForms breakpoints do bind/hit on several lines in Form1.vb (for example: 4, 7, 8, 9, 16, 17, 18).
• Breakpoints on lines 11 and 13 did not hit in my run window.
• Those lines are after MessageBox.Show(result) (line 9), so execution can appear "hung" while waiting on modal UI interaction.

So this looks like a narrower follow-up than "WinForms debugging completely broken".

Could you try these two checks:

1. Put the first breakpoint on line 8 (or 17) and see if it activates.
2. Temporarily comment out MessageBox.Show(result) and retry line 11.

If it still fails, please share:

• whether the breakpoint glyph is hollow/verified before launch,
• and a debugger engine log via:
  • setting vbnet.debugger.args to ["--engineLogging=C:\\temp\\netcoredbg.log"].

Posted by Codex agent on behalf of @govert.

[skurth]

Hi @govert,

I enabled the engine logging as requested. Here are the findings:

1. The first breakpoint at New() (Line 4) works perfectly. The log shows successful stackTrace and variables requests.
2. The second breakpoint inside GetTestString() (Line 13) triggers a stopped event in the engine, but the subsequent stackTrace request fails.

Relevant log snippet causing the issue:

<- (E) {"body":{"allThreadsStopped":true,"reason":"breakpoint","threadId":14000},"event":"stopped","seq":50,"type":"event"}
-> (C) {"command":"threads","type":"request","seq":14}
<- (R) {"body":{"threads":[{"id":14000,"name":"Main Thread"}]},"command":"threads","request_seq":14,"seq":51,"success":true,"type":"response"}
-> (C) {"command":"stackTrace","arguments":{"threadId":14000,"startFrame":0,"levels":20},"type":"request","seq":15}
<- (R) {"command":"stackTrace","message":"Failed command 'stackTrace' : 0x80004002","request_seq":15,"seq":52,"success":false,"type":"response"}

It seems netcoredbg fails with 0x80004002 (E_NOINTERFACE) when trying to retrieve the stack trace at that specific location in the VB.NET code.

Full log file: netcoredbg.log

Updated test app (without async code): VBNetTestApp.zip

[govert]

Thanks, this new log was very helpful.

I reproduced this locally with your updated sample and with direct DAP runs against the bundled netcoredbg.

What I can now confirm:

• Breakpoint at Form1.New() (line 4): stopped event arrives and stackTrace succeeds.
• Breakpoints in/around Form_Loaded and GetTestString (for example lines 8/9/11/13): stopped event arrives, but stackTrace fails with 0x80004002.
• This reproduces with both:
  • program = ...exe and program = ...dll
  • justMyCode = true and justMyCode = false

So this is not a launch.json formatting issue anymore; it looks like a debugger-engine issue in this WinForms execution context.

Extra signal from local repro:

• If GetTestString() is called from the constructor path, stackTrace works there.
• The failure appears when stopped from the WinForms load-event path.

Short-term workaround: break in constructor/startup path for now.

Next step on my side: I will prepare an upstream netcoredbg bug report with a minimal VB WinForms repro and the DAP trace showing stopped followed by failing stackTrace (0x80004002).

Posted by Codex agent on behalf of @govert.

[govert]

Quick update after isolating this away from the VS Code extension stack:

• I reproduced the failure with a minimal C# WinForms repro using raw DAP (netcoredbg --interpreter=vscode), so this is not specific to VB syntax or our extension frontend.
• Pattern: second breakpoint in WinForms load path emits stopped, then stackTrace fails with 0x80004002 (E_NOINTERFACE).
• Root cause appears in netcoredbg frame walking where an ICorDebugILFrame query failure is treated as fatal.

Upstream tracking/fix:

• Issue: stackTrace fails with 0x80004002 on WinForms load-event breakpoints Samsung/netcoredbg#215
• PR (with regression test): Fix WinForms stackTrace E_NOINTERFACE by tolerating non-IL managed frames Samsung/netcoredbg#216

On our side, I have also added a defensive extension workaround for this exact engine error path so the session behaves sensibly instead of hard-failing stack expansion (temporary mitigation while upstream fix is reviewed/released).

Posted by Codex on behalf of @govert.

[govert]

Posted by Codex agent on behalf of @govert.

Quick update: the mitigation discussed above is now published in the VS Code extension as pre-release version 0.1.9.

This includes the temporary netcoredbg stackTrace 0x80004002 fallback so WinForms sessions behave sensibly while upstream netcoredbg fix tracking continues.

[skurth]

@govert Thank you so much for your help.
I have installed 0.1.9 and it shows the error now correctly (the app still hangs):

I'm looking forward to the fix in netcoredbg.

Out of curiosity: When I try it with coreclr, variable values are shown correctly in synchronous methods, and breakpoints also don’t cause the app to hang. But as soon as execution hits a breakpoint inside an Async Sub or Async Function, variable values are no longer displayed. Do you know why this works correctly in Visual Studio? Is Microsoft doing something special to make it work there?

[govert]

Thanks for the additional testing and great question.

What looks like a “hang” here is most likely a paused UI thread, not a deadlock:

• WinForms runs the message loop on the main/UI thread.
• In this failure path, netcoredbg still sends stopped with allThreadsStopped: true.
• That means the process is paused, so the form cannot repaint/respond until Continue (F5).
• Because stackTrace fails in that path (0x80004002), VS Code may not show a normal active frame highlight, which makes the pause look like an unexplained hang.

So yes, the debugger stop state is effectively halting the UI thread in that moment.

On your coreclr async question: that is a different debugger stack (coreclr != this extension’s vbnet adapter), and async locals are generally harder because async methods are rewritten into state machines. Visual Studio uses a richer, language-aware debugger/expression-evaluator pipeline (including async remapping), so it can often show values that VS Code debugger paths do not surface the same way.

Your observations are very useful and consistent with that split.

Posted by Codex agent on behalf of @govert.

[mohammadmaa500-prog]

Hi,
I know that is outside of the main issue here but could you implement an OnTypeFormattingHandler for automatic casing and auto block completion like what Visual Studio Does?

[govert]

Hi, I know that is outside of the main issue here but could you implement an OnTypeFormattingHandler for automatic casing and auto block completion like what Visual Studio Does?

I think so - I suggest you make a new issue here for that feature.