I am facing a breakpoint/debugging issue in Visual Studio 2026 with a C# application that uses C++/CLI managed layers.

Question

I am facing a breakpoint/debugging issue in Visual Studio 2026 with a C# application that uses C++/CLI managed layers.

Mourya K V 15

My application architecture is:

C# application → C++/CLI managed layer → Native C++ code

There are two C++/CLI managed layers in the solution. Breakpoints work correctly when debugging through one managed layer (Graphics managed layer), but breakpoints in the other C++/CLI managed layer are not becoming active/bound.

The application itself runs correctly, but Visual Studio does not bind the breakpoints in the affected C++/CLI project. I have already checked the debugger settings and tried the usual managed/native debugging options, but the issue remains.

I would like to determine why Visual Studio 2026 is not loading/binding the PDB/debug symbols or attaching the debugger correctly to this C++/CLI managed layer.

Environment:

Visual Studio 2026
C#
C++/CLI
Native C++
Debug configuration
Multiple C++/CLI managed projects
Third-party native libraries are also used

Please advise what diagnostic information, logs, module information, PDB information, or project settings you need to determine why the breakpoints are not binding.

0 comments

2 answers

Your answer

Answer 1

For this scenario, the most useful diagnostics are the module load state, symbol load state, source/PDB match state, and the exact code type Visual Studio is attaching for the process.

Collect this information while debugging:

Check whether the affected C++/CLI module is actually loaded
- Start debugging.
- Open Debug > Windows > Modules.
- Find the DLL for the C++/CLI managed layer whose breakpoints do not bind.
- Confirm whether the module appears at all.
What this determines:
- If the module is not loaded, the breakpoint cannot bind.
- If it is loaded, the next step is symbol status.
Check the module’s symbol status
- In the Modules window, inspect the Symbol Status column for that C++/CLI DLL.
- If symbols are not loaded, right-click the module and select Symbol Load Information....
What to capture:
- The exact Symbol Status shown for the module.
- The output from Symbol Load Information....
This is the primary diagnostic for why PDBs are not loading.
Verify Visual Studio is debugging the correct process and code type
- Open Debug > Windows > Processes.
- Confirm the debugger is attached to the correct process.
- In the same window, check what type of code the debugger is configured to debug.
What this determines:
- Whether Visual Studio is attached to the wrong process.
- Whether the debugger is configured for the appropriate code type.
Check whether the source file matches the built binary If the breakpoint tooltip says the current source differs from the built version, rebuild the project.
- Save the source again if needed.
- If Visual Studio thinks the project is up to date, do a clean build and then rebuild.
What to capture:
- The exact breakpoint tooltip text.
- Whether a rebuild changes the breakpoint from hollow to solid.
Confirm the PDB contains source information If symbols are loaded but breakpoints still do not bind, one documented cause is that the PDB does not contain source file information. Relevant checks:
- Confirm the loaded module is the current build.
- Confirm a full PDB is being used and not a stripped PDB created with /PDBSTRIPPED.
- If the PDB may be corrupted, delete it and perform a clean build.
Compare the working and non-working C++/CLI layers in Modules Since one managed layer binds correctly and the other does not, compare these side by side in Debug > Windows > Modules:
- Whether both DLLs are loaded
- Symbol Status for each
- Whether one shows symbols loaded and the other does not
For remote-style symbol issues or mixed deployments If the wrong binary is deployed or a release binary is being used, symbols may not load correctly and the module may not be treated as expected for user code. The documented guidance is to verify the debugger is using the exact matching PDB created when the app was built.

What to provide for diagnosis:

Screenshot or text from Debug > Windows > Modules for both the working and failing C++/CLI DLLs
The Symbol Status for the failing module
The full Symbol Load Information... output for the failing module
Whether the failing module appears in Modules at all
Screenshot or details from Debug > Windows > Processes showing the attached process and code type
The exact breakpoint tooltip/warning text
Whether a Clean + Rebuild changes behavior
Whether the failing project may be producing a stripped PDB
Whether the source file was recently changed without rebuilding

If the breakpoint warning is specifically:

“No Symbols have been loaded for this document”: focus on Modules and Symbol Load Information....
“the current source code is different from the version built into...”: focus on rebuild/clean and source-binary mismatch.

Visual Studio breakpoint state meanings are also useful during diagnosis:

Solid red circle: breakpoint successfully set.
Hollow circle: breakpoint is disabled or a warning occurred while setting it.
Exclamation glyph: the debug engine handled the breakpoint but could not bind it as an error.
Question glyph: the debug engine returned a warning because another debug engine might still bind it.

References:

Answer 2

Tom Tran (WICLOUD CORPORATION) 5,785 Microsoft External Staff Moderator

Hi @Mourya K V ,

Thanks for sharing your details.

The detail that stands out to me is that breakpoints bind in one C++/CLI layer but not the other. So, I would suggest comparing the two modules directly rather than repeating the general debugger checks you have already tried.

While the affected breakpoint is unbound, could you collect the following?

In Debug > Windows > Modules, find both the affected C++/CLI DLL and the working Graphics DLL, then share the Path and Symbol Status for each. If the affected DLL is not listed, please let me know.
Right-click the affected module, select Symbol Load Information, and share the complete output.
Share the exact message shown when you hover over the unbound breakpoint.
Share the full version number from Help > About Microsoft Visual Studio.
Confirm whether the breakpoint is in the C++/CLI code itself or in the native C++ code called by that layer.

These checks follow Microsoft’s documented guidance in Troubleshoot breakpoints in the Visual Studio debugger.

This information should help narrow down whether the affected module is not being loaded, its PDB does not match, or the required debugger code type is not active.

Please remove any private paths or project information before posting.

Mourya K V 15 Reputation points

2026-09-09T11:32:12.7033333+00:00
I have collected the requested information below.

Working modules DLL(C++/CLI): Managed Layer& Graphics Managed Layer

Effected module Native C++: Coreadaptor & graphics

2.Load sysmbol information

Native C++(Graphics): D:\Mourya D Drive\MakePathVS_2026\BoostUpdate\AMMakePath\bin\x64\Debug\net10.0-windows\Graphics.pdb: Cannot find or open the PDB file. D:\Mourya D Drive\MakePathVS_2026\BoostUpdate\AMMakePath\bin\x64\Debug\net10.0-windows\Graphics.pdb: Cannot find or open the PDB file. D:\Mourya D Drive\MakePathVS_2026\BoostUpdate\x64\Debug\Graphics.pdb: Symbols loaded.

Native C++(Coreadaptor):

D:\Mourya D Drive\MakePathVS_2026\BoostUpdate\AMMakePath\bin\x64\Debug\net10.0-windows\CoreAdapter.pdb: Cannot find or open the PDB file. D:\Mourya D Drive\MakePathVS_2026\BoostUpdate\AMMakePath\bin\x64\Debug\net10.0-windows\CoreAdapter.pdb: Cannot find or open the PDB file. D:\Mourya D Drive\MakePathVS_2026\BoostUpdate\x64\Debug\CoreAdapter.pdb: Symbols loaded.

The breakpoint is shown as a solid red circle. When I hover over it, Visual Studio does not display any diagnostic/unbound-breakpoint message.

Version Details

The breakpoints in the C++/CLI code work consistently. However, breakpoints in the native C++ code called from the C++/CLI layer generally do not get hit. When a breakpoint is placed only in native C++ code, execution reaches the C++/CLI layer but does not consistently stop at the native C++ breakpoint. In some cases, the native C++ breakpoint works randomly/intermittently.
Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator

2026-09-10T03:02:54.5233333+00:00
Hi @Mourya K V ,

Sorry for the delayed response.

Thanks for the detailed information. This clears up quite a bit.

Looking at the results, the symbols do not appear to be the problem. Each module, including CoreAdapter and Graphics, ultimately shows Symbols loaded. The breakpoint also remains a solid red circle without a warning, which means Visual Studio has set it, but execution is not stopping there consistently.

So, I would focus next on how the debugger transitions from the C++/CLI layer into the native code.

While debugging, open Debug > Windows > Processes and check which code types are attached to the process. Since this is a .NET 10 application calling native code through C++/CLI, the process needs both managed and native debugging enabled.

Go to Tools > Options > Debugging > General, clear Enable Just My Code, and test the native breakpoint again.

Add __debugbreak(); directly inside the native function where the breakpoint is not being hit, then run the application again. If execution stops there, it confirms that the native code is running and that the debugger can break inside it. If it does not stop, the affected call path may not be reaching that function.

For the native projects, confirm that Optimization is set to Disabled (/Od) and Inline Function Expansion is set to Disabled (/Ob0). This is worth checking because the native breakpoint works intermittently.

The Modules window shows ManagedLayer.dll and GraphicsManagedLayer.dll more than once. Please check whether the duplicate entries point to the same file path.

Microsoft covers the relevant checks under the section for breakpoints that are set but not hit in Troubleshoot breakpoints in the Visual Studio debugger.

Please let me know what you see in the Processes window and whether __debugbreak() stops execution.
Mourya K V 15 Reputation points

2026-09-10T09:37:24.6533333+00:00
Hi @Tom Tran (WICLOUD CORPORATION)

Thanks for the additional suggestions. I tested the requested items and found the following:

1. Managed and native debugging

I checked the debugging configuration and confirmed that both managed and native debugging are enabled for the process. I also tested the native breakpoint again, but the issue still persists.

2. Just My Code

I disabled Enable Just My Code under:

Tools → Options → Debugging → General

and tested again. There was no change; the native C++ breakpoint still does not work consistently.

3. __debugbreak() test

I added __debugbreak(); directly inside the affected native C++ function.

In this case, Visual Studio does stop execution and shows the "Breakpoint Instruction Executed" notification, as shown in the attached screenshot:

This confirms that the native function can be reached and that the debugger is capable of breaking when an explicit breakpoint instruction is executed.

However, the normal source-level breakpoint placed on the native C++ code does not work consistently.

4. Native compiler optimization

I checked the native projects and tested with:

Optimization: Disabled (/Od)

Inline Function Expansion: Disabled (/Ob0)

The issue still persists.

5. Duplicate ManagedLayer.dll / GraphicsManagedLayer.dll entries

I have not yet been able to determine why ManagedLayer.dll and GraphicsManagedLayer.dll appear twice in the Modules window. I checked the entries, but I am not able to identify the reason for the duplicate entries.

However, I observed another important behavior during testing:

When debugging with native debugging only, the native C++ breakpoints work correctly. However, when managed/C# debugging is enabled, the C# breakpoints do not work correctly.

This seems to indicate that the issue may be related to the interaction between the managed (.NET/C#) and native C++/CLI debugging engines, rather than the native symbols themselves.

Could you please advise whether there are any known issues or additional debugger settings related to mixed-mode debugging for a .NET 10 application using C++/CLI and native C++ code in Visual Studio 2026 version 18.9.2?

I have attached the screenshot showing the result of the __debugbreak() test.
Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator

2026-09-10T10:50:08.1466667+00:00
Hi @Mourya K V ,

Thanks for working through all of those, the results are really useful.

Between the symbols loading, __debugbreak() stopping inside the function, and /Od, /Ob0 and Just My Code making no difference, the usual causes are off the table. What is left is that things behave correctly in a native-only session and only go wrong once managed and native debugging run together, which points at the mixed-mode side rather than anything in your project or symbols.

I did go looking for related reports. Here is what I managed to find:

C# Native Debugging in .NET Core fails to step into native code

Mixed-code DLL debugging skips native breakpoints with "No executable code"

Both are with the Visual Studio debugger team as under consideration. The symptoms are close but not the same as yours, so I cannot tell you if they share a cause.

Given that, I would highly recommend raising this on Developer Community. This is the appropriate place to report Visual Studio product issues, and it will give the team the information needed to evaluate your specific setup with .NET 10, C++/CLI, and Visual Studio 2026 version 18.9.2.

If you decide to create one, please let me know.
Mourya K V 15 Reputation points

2026-09-10T11:30:50.8333333+00:00

Hi,

Thanks for the investigation and for finding the related reports.

Yes, I will create a Developer Community issue with the details of my setup and the debugging behavior. I will include the information collected so far, including the Modules window, symbol information, __debugbreak() result, Visual Studio version, and the difference between native-only and mixed-mode debugging.

I will share the Developer Community link here once I have created the issue.

Thanks for your help.
Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator

2026-09-11T08:42:04.4+00:00

Hi Mourya K V,

Thanks for the update, and I appreciate you taking the time to put all the findings together.

Please feel free to share the Developer Community link here once it is available, so others experiencing the same behavior can upvote the report and add their feedback.