能否用Visual Studio Code附加调试运行中的.NET Framework程序？遇0x8013132e错误求助

Absolutely, you can attach Visual Studio Code to a running 64-bit .NET Framework process for debugging—this is totally feasible, provided you have the right extensions, correct configuration, and resolve the common issues causing that 0x8013132e error. Let’s break down what you might be missing and how to fix it:

1. Ensure You Have the Right Extensions #

The old OmniSharp-based C# extension can work, but Microsoft’s newer C# Dev Kit (officially supported) offers far better support for .NET Framework debugging. I’d recommend installing it instead—it handles most of the setup automatically, including required debugging components. If you stick with the legacy C# extension, make sure it’s updated to the latest version.

2. Fix Your launch.json Configuration #

Your current config is missing a few critical details that often cause the 0x8013132e error. Here’s an improved version tailored for 64-bit .NET Framework processes:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to .NET Framework Process",
      "type": "clr",
      "request": "attach",
      "processId": "${command:pickProcess}", // Lets you manually select the target process (avoids name conflicts)
      "targetArchitecture": "x64", // Critical for matching your 64-bit process
      "pdbPath": "${workspaceFolder}/**/*.pdb" // Update this if your PDBs are stored in a non-default location
    }
  ]
}

Key fixes here:

• targetArchitecture: Explicitly sets the debugger to target 64-bit, which resolves architecture mismatches (a common cause of 0x8013132e).
• processId: Using ${command:pickProcess} lets you select the exact process you want, avoiding issues if multiple processes share the same name.
• pdbPath: Ensures the debugger can find your PDB files if they’re not in the same directory as the running process.

3. Verify Your PDB Files Are Matching #

The error can also pop up if your PDB files don’t exactly match the binaries running in the process. Double-check:

• The PDBs are from the same build as the exe/dll files in the running process (same GUID and timestamp).
• You haven’t modified the binaries after generating the PDBs.
  You can verify this with tools like dumpbin /headers <your-exe-file> to check the binary’s debug info, then cross-reference with the PDB’s details.

4. Use 64-bit VS Code #

Make sure you’re running the 64-bit version of Visual Studio Code. A 32-bit VS Code instance can’t attach to 64-bit .NET Framework processes—this is another frequent cause of the 0x8013132e error. You can check your VS Code architecture by going to Help > About and looking for the "Architecture" line.

5. Ensure Debugging Components Are Installed #

If you’re using the legacy C# extension (not C# Dev Kit), you might need to have the .NET Framework debugging tools installed on your system. The easiest way to get these is to install the Desktop Development with C++ workload in Visual Studio (even if you don’t use Visual Studio itself, this installs the necessary debuggers). C# Dev Kit handles this automatically, so switching to it can save you this step.

From my own experience, once you fix these items, attaching to a running .NET Framework 64-bit process in VS Code works smoothly. The 0x8013132e error almost always boils down to an architecture mismatch, missing debug components, or incorrect PDB/configuration setup.

内容的提问来源于stack exchange，提问作者Artur