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 Reputation points
2026-09-09T06:35:40.4066667+00:00

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.

Developer technologies | Visual Studio | Debugging
0 comments

2 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Tom Tran (WICLOUD CORPORATION) 5,785 Reputation points Microsoft External Staff Moderator
    2026-09-09T10:18:57.8433333+00:00

    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?

    1. 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.
    2. Right-click the affected module, select Symbol Load Information, and share the complete output.
    3. Share the exact message shown when you hover over the unbound breakpoint.
    4. Share the full version number from Help > About Microsoft Visual Studio.
    5. 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.

    Was this answer helpful?

  2. AI answer

    2026-09-09T06:36:04.37+00:00

    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:

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.
    6. 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
    7. 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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

    2 people found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.