Breakpoints disappeared after starting a debugging session

[cateyes99]

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.301
 Commit:    7feb845744

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.301\

Host (useful for support):
  Version: 3.1.5
  Commit:  65cd789777

.NET Core SDKs installed:
  2.2.402 [C:\Program Files\dotnet\sdk]
  3.1.301 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.19 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

VS Code version: 1.47.2 C# Extension version: 1.22.1

Description

Here is a very weird debugger behaviour I encountered today. Recently I upgraded OmniSharp C# extension from 1.21.18 to 1.22.1. Today it was the 1st time I used this newly upgraded version to carry out a debugging session. I have a .NET Core 3.1 Web API project. The breakpoints disappear right after either launching it or attaching to a process! But during debugging, it stops at the statements where breakpoints were set up even they disappeared visually. No current statement indicator show up either like the below one. When hovering the mouse on a local variable, only type info shows up but no run time value info, like the below one. All the thing just looks like it isn't in a debugging session at all. But the call stack does show up properly, so I know the execution pauses. Further if double clicking any call in the call stack, it does take me to that call, and the current statement indicator shows up as normal like the below one. If hovering the mouse on a local variable in that call, its run time value info does show up properly as normal! (like the below one).

I uninstalled and re-install the 1.22.1 version a few times and ended in no difference. So i downgraded this OmniSharp C# extension to 1.21.18, and found that 1.21.18 worked perfectly! Thus I created a simple .NET Core 3.1 Web API project, found that the latest 1.22.1 version worked fine with this simple project! Thus I compared the two projects' .csproj files. Found some difference I thought it might matter, so I commented out some line in my problematic project's .csproj file to make them the same:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <!-- <LangVersion>8.0</LangVersion>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
    <UserSecretsId>6ef70598-840f-490b-9d0e-09e9d09956fb</UserSecretsId> -->
  </PropertyGroup>

During debugging, the OmniSharp C# extension's behaviors are normal now. So I thought at least one of those 3 commented out lines caused the issue. To find out which one, I uncommented each line one by one to see what happened. At the end all 3 lines were uncommented i.e., rolled back completely actually, and the debugger still worked fine. In other words, the ISSUE just disappeared without ANY real changes. The debugger works fine since! Very confused why the debugger has such a weird behaviour.

[gregg-miskelly]

Do you still have a way of producing the problem? If so, can you grab a debugger log? (see instructions here)

[cateyes99]

@gregg-miskelly so far haven't yet 👀

[cateyes99]

This issue came back! I think it might because I restarted my laptop. The VScode version i'm using now is 1.47.3. The bug behaves slightly different & worse. This time, even jumping to one of the call in the call stack, it won't show the current statement indicator anymore. In the screenshot below, There is a breakpoint at Line 64 which is the current statement where the execution paused at. A debugger's log file has been attached at your instruction. @gregg-miskelly VSCodeDebuggerBreakpointsIssueLog.txt

[gregg-miskelly]

To make sure, does this path match up with the file name opened in the editor (probably worth comparing the casing also, in case that has anything to do with this): "C:\AAA.Core\src\AAA.TokenExchange.Api\TokenExchangeV2.API\src\AAA.TokenExchange.WebApi\Controllers\IdentityController.cs"

We probably need to move this issue to VS Code.

[cateyes99]

Yes, it does match up with the file's path opened in the editor including casing. Yesterday the issue came back. But today, I'm debugging it right now, and the issue disappeared again 😕 without any changes to the project files, apart from some lines in the source logic. (maybe the rebuilding source after those changes made some difference to it, like last time after making some changes to the project file I also rebuilt the source certainly.) Next time when this issue appears again, i'll check out if any source change and rebuilding will make it work.

[cateyes99]

@gregg-miskelly I'm having this issue right now. It happened to all the 3 different projects i'm debugging ATM. I think last time i was wrong after checking the casing carefully this time. In some places that path's casing does not match. All source files are located under the fold c:\Aaa.Core\src. Last time when i did the text substitution in the previous debugger log file, some casing had been messed up, so it is hard to tell. I've uploaded a new one for the debugger's logging with casing preserved. There are 2 breakpoints one is at Line 18 in BobTokenMappingStrategy.cs which is working fine ATM, the other is at Line 61 in IdentityController.cs which isn't. You can see in the logging file, the one not working has C:\AAA.Core\src\AAA.TokenExchange.Api\TokenExchangeV2.API\src\AAA.TokenExchange.WebApi\Controllers\IdentityController.cs (Line 32 in the loggging file) which should be C:\Aaa.Core\src\AAA.TokenExchange.Api\TokenExchangeV2.API\src\AAA.TokenExchange.WebApi\Controllers\IdentityController.cs, meanwhile in Line 13 it's c:\Aaa.Core\src\AAA.TokenExchange.Api\.... The drive is in both upper and lower cases at the same time, i.e., C: & c:.

Interestingly the one working fine in BobTokenMappingStrategy.cs has both upper and lower casing for the drive too, c:\Aaa.Core\src\AAA.TokenExchange.Api\... (Line 11 in the logging file), and C:\Aaa.Core\src\AAA.TokenExchange.Api\... (Line 285 in the loggging file). Maybe the drive's casing doesn't matter?

Confused, i wonder where AAA.Core comes from. BTW as i've experienced, without essential changes, sometimes it just works ... VSCodeDebuggerBreakpointsIssueLog2.txt