Break points on symbols not loaded on actions in .cs files locally

[BartPeirens]

Severity

P3 - Medium (Minor functionality affected)

Describe the Bug with repro steps

Expected behaviour:

• Run debug logic app should load breakpoints in .cs files to allow for use of the debug tool on actions when placed on the line.

Actual behaviour:

Break point symbols are not loaded in .cs files , instead they are greyed out even though they are placed

What type of Logic App Is this happening in?

Standard (Local Development)

Are you experiencing a regression?

No response

Which operating system are you using?

Windows

Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg

Yes

Workflow JSON

Screenshots or Videos

I used this page https://learn.microsoft.com/en-us/azure/logic-apps/expression-functions-reference?azure-portal=true&utm_source=chatgpt.com#functions-in-expressions and did not modified any code.

Environment

• Windows 11
• VSCode version 1.114
• Azure Logic Apps (Standard) version 5.230.15
• C# Dev kit version 3.10.4

Additional context

No response

[github-actions]

AI Triage Analysis

Component: VS Code Extension — Custom Code Debugging | Priority: P3 | SKU: Standard (Local Development)

Relevant Code

• apps/vs-code-designer/src/app/commands/debugLogicApp.ts — orchestrates attaching the debugger; spawns a separate debug session for the custom code runtime (coreclr/clr) via vscode.debug.startDebugging
• apps/vs-code-designer/src/app/commands/pickCustomCodeWorkerProcess.ts — locates the child dotnet/CustomCodeNetFxWorker process to attach to; the isCodeless flag controls the process-name regex used to find the correct PID
• apps/vs-code-designer/src/app/utils/debug.ts — getDebugSymbolDll() resolves the path to Microsoft.Azure.Workflows.BuildTasks.DebugSymbolGenerator.dll; if the bundle path or version is wrong, symbols won't load
• apps/vs-code-designer/src/app/utils/vsCodeConfig/tasks.ts — generates the tasks.json with the ${input:getDebugSymbolDll} arg used to pass the debug-symbol DLL to the host build task

Probable Root Cause

Greyed-out breakpoints in .cs files almost always indicate that the debugger session is not attached to the correct managed runtime process or that the debug symbols (PDB files) were not loaded. The extension attaches to a child dotnet process selected by pickCustomCodeWorkerChildProcess; if that process is not found (e.g., because the custom code project hasn't been built first, or the isCodeless flag routes to the wrong regex), functionLaunchConfig?.processId will be undefined and the attach step is silently skipped. Additionally, getDebugSymbolDll must resolve to a valid path — if the bundle version or path is stale, symbols cannot be loaded.

Suggested Investigation

1. Check whether functionLaunchConfig.processId is actually being set — add a breakpoint or log in debugLogicApp.ts around line 66 (if (functionLaunchConfig?.processId)) to confirm the process was found.
2. Verify the getDebugSymbolDll path resolves to an existing file on the machine and that the .pdb files are present in the bin/ subdirectory.
3. Confirm the C# project was built (dotnet build) before starting the debug session — the extension does not auto-build; if binaries are missing, the dotnet process may not spawn as expected.
4. Check the isCodeless value in the debug config: if it is true, pickCustomCodeWorkerChildProcess only matches dotnet(.exe)?, which may not match on all .NET host configurations.

---

Automated analysis by issue triage agent. May contain inaccuracies — verify before acting.
Calibration: reviewed 10 past triages (output could not be fully parsed), 0 corrections applied.

Generated by Issue Triage Agent for Azure Logic Apps UX for issue #9020 · ◷