Win32 Exceptions Thrown when Attaching an Application to a DLL for Native Debug

Mlee 5 Reputation points
2026-06-19T16:28:33.9833333+00:00

I have recently migrated from Win10 to Win11. Under Win10, I have routinely debugged my C++ dll module without issue by attaching to the application and all the interactive debugging features like breakpoints etc. work as expected. However, the same project solution fails to attach under Win 11 (tried both VS2019 and VS2026) by throwing Win32 exceptions while loading symbols from ntdll.dll and mshtml.dll. Any suggestions as to what I need to do to enable debugging would be very much appreciated.

Developer technologies | Visual Studio | Debugging

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Mlee 5 Reputation points
    2026-06-22T09:18:58.49+00:00

    Hello Leon,

    Many thanks for taking the time to respond to my query.

    After much trial and error, I discovered that the source of my issue was a conflict with another dll associated with my target package. When I disable this particular module, I can enter VS debugging mode as expected.

    Many thanks for your help again.

    Best regards,

    Mlee

    Was this answer helpful?

  2. Leon Tran (WICLOUD CORPORATION) 1,990 Reputation points Microsoft External Staff Moderator
    2026-06-22T04:32:25.9966667+00:00

    Hello @Mlee , 

    Thank you for sharing the details of your debugging scenario. Based on your description, the issue seems related to differences in how Windows 11 handles native debugging compared to Windows 10, particularly when attaching to applications that load DLLs. The Win32 exceptions you’re seeing during symbol loading from ntdll.dll and mshtml.dll are often tied to changes in system level debugging behavior and symbol resolution. 

    Here are a few steps you can try: 

    1. Verify symbol settings  

    This ensures that your Visual Studio symbol paths are correctly configured. Go to Tools > Options > Debugging > Symbols and confirm that the Microsoft Symbol Servers are enabled. Clear the symbol cache and reload to see if the exceptions persist. 

    1. Check debugger compatibility  

    Some debugger features behave differently on Windows 11. Try switching between the “Native Only” and “Mixed” debugging modes in your project settings to see if one avoids the exceptions. 

    1. Update Visual Studio  

    Since you tested with Visual Studio 2019 and 2026, make sure both are fully patched. Debugging improvements and fixes are often included in cumulative updates. 

    1. Test with minimal repro  

    Create a small sample DLL and attach it to a simple application. If the issue reproduces, it will help isolate whether the problem is environmental (Windows 11 + debugger) or specific to your project. 

    Hope this helps! If my answer was helpful so far, you can follow this guidance to provide some feedback. This also help another find the solution easier. 

    Was this answer helpful?

    0 comments

  3. AI answer

    2026-06-19T16:28:49.45+00:00

    To enable native debugging when attaching to a process on Windows 11, the debugger must be able to load correct symbols and (optionally) source for the binaries involved. When attaching to a running process, Visual Studio’s full debugging features (including breakpoints) only work reliably if the app and DLLs exactly match the local source and symbol (.pdb) files.

    For this scenario, check the following:

    1. Verify matching build and symbols
      • Ensure the DLL being loaded by the target application on Windows 11 comes from the same build as the one in the Visual Studio solution.
      • Confirm that the corresponding .pdb for the DLL is available and matches the DLL. The debugger must be able to load the correct symbol file for your DLL.
      • If necessary, copy the built DLL and its .pdb into the application’s folder so the debugger can find them.
    2. Configure symbol settings in Visual Studio
      • Open Tools > Options > Debugging > Symbols and verify the symbol search path includes:
        • The folder containing your DLL and its .pdb.
        • Any local symbol cache folders or symbol servers used in your environment.
      • The debugger uses this symbol search path (or the _NT_SYMBOL_PATH environment variable) to locate PDBs. It searches:
        1. The path embedded in the DLL/EXE.
        2. The same folder as the DLL/EXE.
        3. Local symbol cache folders.
        4. Network symbol servers.
        5. Internet symbol servers (for example, the Microsoft symbol server).
    3. Build a Debug configuration of the DLL
      • Make sure the DLL project is built in Debug configuration before attaching.
      • A calling app must be able to find the DLL’s .pdb file and any other required files. If the app loads a different copy of the DLL than the one built in the solution, breakpoints in that DLL will not be hit.
    4. Attach with matching source and binaries
      • When attaching to a running process, Visual Studio requires that the compiled app binaries in the process match the local binaries and symbols to use full debugging features.
      • Ensure the source code for the DLL is open in Visual Studio and that the binaries on the machine you are attaching to come from the same build as those in the solution.
    5. Use symbol tools if needed
      • If symbol loading errors persist (for example, around ntdll.dll or mshtml.dll), use symchk.exe from Debugging Tools for Windows to verify that your DLL and its PDB match and to identify missing or incorrect symbols.
      • Example usage: 
             "c:\Program Files\Debugging Tools for Windows\symchk" yourdll.dll /s .
        This checks that the DLL and PDB in the same folder match.

    If the system DLLs (ntdll.dll, mshtml.dll) themselves are throwing first-chance exceptions during attach, that is often normal for complex processes; the key is ensuring that the debugger can still load correct symbols for your own DLL and that the loaded DLL instance is the same one built in the solution.

    References:

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

    Was 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.