Debugger not attaching to process

Question

I have an MMC snap-in that I am trying to debug. Currently, the following code, placed in the snap-in's constructor, works in terms of attaching the debugger to it:

public MySnapIn()
{
#if DEBUG
    if (!Debugger.IsAttached)
    {
        Debugger.Launch();
    }
#endif
    ...
}

But its really annoying to always have to attach a debugger to Visual Studio. I want to automate this process. Ideally, I would just have to hit F5 and it automatically attaches the debugger. I have tried the following:

• Project Properties -> Start external program -> typed in "C:\Windows\System32\mmc.exe"
• Project Properties -> Command line arguments -> Gave it a path to a .msc file (stores snap-in layout so it makes it easier to load it every time, so that you don't always have to File -> Add/Remove Snap-in).

This didn't work. The debugger won't attach automatically. How can I automate this process, or what's blocking the debugger from attaching automatically?

Goldsmith

+1 simply for teaching me how to request for a debugger to be attached (Debugger.Launch()). I didn't know that was possible. – Newsom

@stakx It works most of the time. If you have a Windows Service for example, or some other type of application that isn't supposed to have a GUI (according to soft micro), it doesn't work: #12042554 You may also be interested to learn about WER as a debugging tool (generates crash dumps for you; with crash dumps, you can load them into Visual Studio and re-hook the debugger at the point of failure and see the state of all your application's objects). – Goldsmith

@stakx WER just requires a registry key change (msdn.microsoft.com/en-us/library/windows/desktop/…) and PDB files to be present. You can also generate dumps from Task Manager (CTRL+SHIFT+ESC -> right click an app -> Generate dump file) – Goldsmith

WER sounds interesting. I won't be able to use it where I would like to (at work) due to a lack of admin permission on the target machines, but I'll look into it, anyway. – Newsom

@stakx Also, sometimes, if you're working with C++ (native) and C# (managed) apps, when you attach the debugger (Debug -> Attach to process) you may need to change the way it attaches. The "Attach to:" has a Select... button, and I've had to enable all these 3: native, managed, and managed compatability mode in order to debug some native apps that load/call managed DLLs on runtime in order to be able to debug that. The debugging support in Windows is phenomenal, but documentation is always so bad... – Goldsmith

Answer 1

Just got it. As it turns out, you have to use the 32-bit MMC launcher on a 64-bit system (which I am on), and then add the -32 flag to the "Command line arguments" to force it to stay in 32-bit mode:

• Made sure my snap-in project targeted Any CPU in Configuration Manager.
• Project Properties -> Start external program -> typed in "C:\Windows\ SysWOW64 \mmc.exe"
• Project Properties -> Command line arguments -> Gave it a path to a .msc file, and also the -32 flag (stores snap-in layout so it makes it easier to load it every time, so that you don't always have to File -> Add/Remove Snap-in).

Goldsmith

"C:\Windows\SysWOW64\mmc.exe" although the name has 64 in the title, that folder is actually where the 32 bit versions of programs live, so you are running the 32 bit launcher, not the 64 bit. The 64 bit versions live in C:\Windows\System32 if you are running a 64 bit app or C:\Windows\sysnative if you are running a 32 bit app (System32 will redirect to SysWOW64 if you are running a 32 bit app) – Cookery

@ScottChamberlain That is so crazily counter-intuitive, but thanks, I will update my answer. – Goldsmith

If you want to learn more about these kind of redirections see this MSDN page on the File System Redirector – Cookery

And if anyone else cares, WoW64 is supposed to be short for, "Windows 32-bit on Windows 64-bit": en.wikipedia.org/wiki/WoW64 – Goldsmith