Share via

Debugger not working for Debugging Extensions in Visual Studio 2026

Devesh Ketan Patel 0 Reputation points
2026-03-20T06:41:35.1233333+00:00
  • I am not able to debug my Extensions since I have moved to Visual Studio 2026.
  • When I start debugging and check the Symbol File that is being currently loaded for my Extension, it is coming from the Release path, i.e., it is loading the release .dll which hinders the debugging experience.
  • I have attached the source.extension.vsixmanifest and TWVSSCM.csproj as txt files and the screenshot for which Symbol File is getting picked up.

source.extension.vsixmanifest.txt

Symbol_File_Screenshot.png

TWVSSCM.csproj.txt

Developer technologies | Visual Studio | Debugging
0 comments No comments

2 answers

Sort by: Most helpful
  1. Adiba Khan 2,345 Reputation points Microsoft External Staff
    2026-03-20T10:07:19.52+00:00

    Thanks for reaching out. based on what you have described, the issue is that your VSIX extension is loading symbols from the Release output path instead of the Debug build, which prevents proper debugging in Visual Studio 2026.

    For you module window, the .dll is loaded from installed extension location (program files) and symbols are loaded from release path (obj/Release/...). This indicates Visual Studio is running the installed VSIX, not the experimental instance with Debug build.

    Resolution Steps

    1. Ensure Debug configuration is active
      1. Set the solution configuration to Debug
      2. Rebuild the solution
    2. Run Correct Startup Project(VSIX)
      1. Right-click your VSIX project -> Set as Startup project
      2. Press F5 This should launch the Experimental instance of Visual Studio, not the main installed one. if its not opening Experimental Instance:
      3. Check .csproj
              <StartAction>Program</StartAction>
              <StartProgram>$(DevEnvDir)devenv.exe</StartProgram>
              <StartArguments>/rootsuffix Exp</StartArguments>
        
    3. Remove installed VSIX (important) Currently your extension is being picked from installed location.
      1. Go to:
              Extensions -> Manage Extensions -> Installed
        
      2. Uninstall your extension
      3. Restart Visual Studio
    4. Verify VSIX manifest assets your manifest currently includes:
         Asset Type =" Microsoft.VisualStudio.VsPackage"
         
      
      Ensure:
      1. Output path is not hardcoded to Release
      2. No prebuilt binaries are referenced
    5. Disable "Optimize code" for debug in .csproj:
         <Optimize>false</Optimize>
         <DebugType>full</DebugType>
      
    6. Clear experimental Instance Cache Run:
         devenv /rootsuffix Exp /resetuserdata
         
         
      
      This ensures no stale extension cache is used.
    7. Confirm Symbols Load from Debug Path After F5:
      1. go to debug -> Windows -> Modules
      2. Verify:
        1. Path -> bin\Debug..
        2. Symbols -> Loaded from debug .pdb

    if the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment"


  2. Q&A Assist
    2026-03-20T06:41:53.4066667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    In Visual Studio 2026, debugging an extension still relies on the same core mechanisms: the experimental instance, correct build configuration (Debug), and correct symbol (.pdb) and source loading. The behavior described—symbols loading from the Release output—indicates that the debugger is attaching to a different DLL than the one built by the active Debug configuration, or that symbol search paths are resolving to the Release build first.

    Use the following steps to force the debugger to load the correct Debug symbols and DLL for the extension.

    1. Start debugging the extension in the experimental instance
    • Open the extension project.
    • Set a breakpoint in the extension code (for example, in the InitializeServices method of the main Extension-derived class).
    • Start debugging with Debug > Start Debugging (F5). This launches the Visual Studio Experimental Instance where the extension is loaded.
    • Perform the actions in the experimental instance that activate the extension so the module is actually loaded.
    1. Verify and correct symbol loading while debugging
    • In the main (debugger) Visual Studio instance, open the Modules window:
      • Debug > Windows > Modules (or Ctrl+Alt+U).
    • Locate the module (DLL) for the extension in the list.
    • Check the Path column to confirm whether the loaded DLL is coming from the Debug or Release output folder.
    • Check the Symbol Status and Symbol File columns to see which .pdb is loaded.
    • Right‑click the module and use:
      • Symbol Load Information to see exactly where the debugger searched for symbols and which .pdb it loaded.
      • Load Symbols to force reloading from the configured symbol locations.
      • If the wrong .pdb is loaded, use Load Symbols and then browse to the Debug output folder for the extension and select the correct .pdb.
      • After loading the correct .pdb, right‑click again and choose Always Load Automatically so future sessions use this symbol file automatically.
    1. Fix symbol search paths so Debug is preferred
    • Open Tools > Options.
    • Go to All Settings > Debugging > Symbols.
    • Under Symbol file (.pdb) locations:
      • Remove or disable any paths that point to Release output folders for the extension.
      • Add the Debug output folder of the extension project (for example, the bin\Debug path) as a symbol location.
      • Ensure the Debug folder entry is higher in the list than any Release or shared symbol locations so it is searched first.
    • Select Save.
    1. Confirm source file search paths If the debugger still does not step into the expected source files, ensure the source search paths are correct:
    • In Solution Explorer, select the solution and open Properties (Alt+Enter).
    • Go to Debug Source Files.
    • Under Directories containing source code, add the extension project’s source directory if it is not already listed.
    • Ensure only the intended source directories are listed and that no Release-only paths are masking the Debug sources.
    • Select OK or Apply.
    1. Use the No Symbols Loaded page when hitting breakpoints If the debugger breaks into code and shows a No Symbols Loaded page for the extension module:
    • Use the options on that page to:
      • Select New Path and add the Debug output folder for the extension, then select Load.
      • Or select Browse and find <executable-name> and manually choose the correct .pdb in the Debug folder.
    • After the correct .pdb is found and loaded, the debugger will use the matching Debug symbols and source.
    1. Ensure the project is actually building Debug for the experimental instance
    • Confirm the active configuration is Debug (not Release) in the toolbar when starting F5.
    • Rebuild the solution in Debug before starting the experimental instance.
    • If multiple configurations or output paths are defined in the project file, verify that the experimental instance is loading the DLL from the Debug output path (as seen in the Modules window). If it is loading from a Release path, adjust the project’s build output or VSIX packaging so the VSIX used by the experimental instance contains the Debug build.

    Following these steps ensures that the experimental instance loads the Debug build of the extension and that the debugger resolves symbols and source from the Debug output, restoring full debugging capabilities.


    References:


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.