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

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:

• Attach to running processes with the Visual Studio debugger (programming-language-all)
• Debug DLLs in Visual Studio (C#, C++, Visual Basic, F#)
• Debugging with Symbols