Ok, I just verified I am able to step through code using this process.
I am doing this in ArcMap, but I think it should apply to ArcCatalog since the process deals with debugging DLLs and not an ESRI specific item. I confirmed this in both ArcMap 10.2.2 and ArcCatalog 10.2.2. As this is a Windows process dealing with DLLs directly, ESRI software versions shouldn't matter.
I am using Visual Studio to Attach to a Process.
I am able to step through a compiled extension (DLL) using this process when the DLL is invoked in another program.
Here is what I am doing...
In Visual Studio, open up your extension project. I built my extension in VS 2010 C# Express, but I am using VS 2013 Ultimate to do this. I am not sure if Attach to Process is an option in the 2010 Express version. I didn't see it, but it could be hidden somewhere since it was the Express version.
Open up your ESRI product and install the add-in. Now, back in VS, click on Attach to Process and select your ESRI product process. Mine was ArcMap.exe. From here, Visual Studio should attach its debugger to the program and when the DLL is executed that you have open and breakpoints set for, it will stop there. This will act like any other program you're debugging in Visual Studio. It may stretch some debugging into some of the ESRI items although the code is most likely obfuscated so not so useful.
I made sure I installed the add-in from my Release directory for my project. As far as I can tell, ESRI doesn't copy the DLL into one of its folders, but they use their Esri Assembly Registration Utility to register the DLL's location so the system knows where to find it when referenced from an ESRI product.
FYI: I use this process to debug class libraries I write in one project that are being utilized in another. The same theory there should apply ESRI add-ins as they are just class libraries (DLLs) being called into another program. Aside from Visual Studio, I believe any other Windows debugger should be able to attach to the DLL.
PLEASE post comments on this one. I have thought this would work for a while and am very curious to see how others fair with this method.
EDIT I just created a new ArcCatalog add-in, which consists of a simple button. I added a string assignment
string stophere = "debugger stopped!"; in the event handler for the button's click event. Through ArcCatalog, it stopped using the Attach to Process method. Visual Studio 2010 info on the process is here.
There are a few things on MSDN about debugging DLLs through various methods in Visual Studio and Windows Debugger. I personally find the Attach to Process better than the starting an external program method and also better than using the remote debugger.
The only downside to this method is that you lose the F5 approach where you debug directly from within Visual Studio. So that means, make changes to your code, install the update, start ArcCatalog, Attach to Process, then hit your break points. However, I find that this method is a pretty good one to know in case you run into problems like you have. This process may be a little longer, but it is a surefire method to get your results.