Debugger attaching too late - Unable to hit breakpoints in Startup.cs

[TroyWitthoeft]

In some situations, it looks like the VS Code debugger is unable to attach fast enough to hit specific breakpoints. For example, if we create a boilerplate C# httptriggered Azure function and add a startup.cs file those "early" breakpoints in the file are often missed. Example repo - https://github.com/TroyWitthoeft/AzureFunctionsHostStartupBug

Example of missed breakpoint

Above, why didn't we hit the first breakpoint?
Is there anything we can do to correct this? I've had quite a few dev's trying to get started with DI in C# using startup.cs and having this issue.

Note, I am posting here on the suggestion of @WardenGnaw who is assisting me in the csharp extension repo at issue 3644. He mentioned that your team might be able to assist.

Thoughts... Is it possible to change the launch.json file or the ${command:azureFunctions.pickProcess} command to correct for this? Is there someway we can signal to the debugger that we are ready for it to attach?

Environment

VSCode = 1.43.0
Azure Functions Extension = 0.21.0
csharp extension = 1.21.12
azure functions core tools = 3.0.2245

dotnet --info

.NET Core SDK (reflecting any global.json):
 Version:   3.1.102
 Commit:    573d158fea

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.102\

Host (useful for support):
  Version: 3.1.2
  Commit:  916b5cba26

.NET Core SDKs installed:
  3.1.101 [C:\Program Files\dotnet\sdk]
  3.1.102 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]`

[ejizba]

Yeah this is somewhat of a known issue. Similar issues for other languages:

• JavaScript: Debugger attaches too late to JavaScript function with "RunOnStartup" option #1492
• Python: Python timer trigger does not run locally when runonstartup is set to true #1841

We're currently blocked on this: Azure/azure-functions-host#4384

[jsacapdev]

this happens for my consistently

.NET Core SDK (reflecting any global.json):
 Version:   3.1.300
 Commit:    b2475c1295

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.300/

Host (useful for support):
  Version: 3.1.4
  Commit:  0090613580

.NET Core SDKs installed:
  3.1.300 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.4 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

vscode

Version: 1.45.1
Commit: 5763d909d5f12fe19f215cbfdd29a91c0fa9208a
Date: 2020-05-14T08:27:22.494Z
Electron: 7.2.4
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Linux x64 5.3.0-1022-azure

core tools

3.0.2534

c#

1.22.0

azure functions extension

0.22.1

[AzCode-Bot]

This issue has become stale and is at risk of being closed. The community has 60 days to upvote the issue. If it receives 5 upvotes we will keep it open and take another look. If not, we will close it. To learn more about how we handle issues, please see our documentation.\n\nHappy Coding!

[Shilp]

I am facing the same issue !

[kevinchatham]

Same here, has anyone found a fix for this?

[yutaro113]

I am also facing same issue.
Would like to know the cause/fix, or at least workaround if any!
Thanks.

[yutaro113]

@ejizba Hello, this is just a gentle reminder but is there any plan for fixing this issue? Thank you very much for the confirmation!

[channeladam]

Same. Any update?

[duyn9uyen]

I've been running in circles trying to figure this out. I'm on a Mac so I don't have an option to use Visual Studio. Anyone found a workaround to hit the breakpoints with VS Code? Adding in Thread.Sleep() didn't seem to help me either.

[mmulhearn]

@duyn9uyen VS for Mac

[nturinski]

Hi, sorry for the delayed response.

My understanding is that this PR (#2200) should have fixed this problem, but I can see that it hasn't completely 😞

What version of the Func Core Tools and Functions Extension are you using? Does the debugger just miss the breakpoint for the first time and then successfully works after that? Or does it never even attach?

[duyn9uyen]

Func Core Tools: 3.0.3477
Azure Functions (VS Code Extension): v1.6.0

The debugger will not break on startup.cs. It will attach on HTTP requests to the functions themselves. Just not on startup.cs while the app starts.

[nturinski]

Thanks for your quick response!

This sounds like it might be a timing issue between when VS Code actually attaches vs. when the process starts. This might be tricky to resolve due to the fact that we are using attach requests for debugging.

The best way to explain the difference between launch and attach is to think of a launch configuration as a recipe for how to start your app in debug mode before VS Code attaches to it, while an attach configuration is a recipe for how to connect VS Code's debugger to an app or process that's already running. - Source

Since the process is required to be running before VS Code can attach, it's most likely missing anything in the startup.cs code.

Perhaps current workarounds are hard-coding a lengthy delay before the breakpoint or configuring the task itself to launch the process.

[bnchou]

For info, I can debug Startup.cs with this configuration in launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to .NET Functions",
      "type": "coreclr",
      "request": "launch",
      "program": "func",
      "args": ["host", "start"],
      "cwd": "${workspaceFolder}/src/Function/bin/Debug/netcoreapp3.1",
     }
  ]
}

[pkamphuis]

Neither with no delay, or with long delay. I can't get the breakpoints in the configure code to hit.

[mvinicius2k]

For .NET 8 isolated, starting with func host start --dotnet-isolated-debug does the execution awaits the debugger. So delete processId from launch debugger works for me:

{
            "name": "Attach to .NET Functions",
            "type": "coreclr",
            "request": "attach",
            //"processId": "${command:azureFunctions.pickProcess}" <-- remove this
}

vid.webm