对于纯托管和纯本机调试，只能将1个调试器附加到进程。
为什么？
本机调试器从托管调试器下面窃取调试事件。这会混淆托管调试器并导致其崩溃。本机调试器无法与托管调试器协调。
执行此操作时遇到的问题：
在windows中，操作系统强制一次只能将一个本机调试器附加到调试对象（已调试进程的DebugActiveProcess将失败）。仅托管调试服务具有类似的检查，以强制一次只能将一个托管调试器附加到调试对象。仅托管调试实际上与纯本机调试是分开的。（这与使用辅助线程有关）。如果一个进程只被管理调试，操作系统不会将其视为只进行本机调试。
如果允许同时将1个托管调试器和1个本机调试器附加到应用程序。这样就可以绕过检查。更糟糕的是，我们无法完全检测到这种情况。本机调试api对托管调试一无所知，因此不能强制执行。托管调试api的进程内部分可以调用IsDebuggerPresent来检查是否附加了本机调试器，但是本机调试器可以在这些调用之间附加。即使在检测到这种情况时，托管调试器也没有一种好的响应方式。
为什么有人想这么做？
实际上有一些场景可以激励将多个调试器附加到一个应用程序上。
1） 获得更多的功能-仅本机调试器只能调试应用程序的本机部分。同样，仅托管调试器只能调试应用程序的仅托管部分。那么，如果你想调试一个同时使用托管代码和本机代码的应用程序呢？一种解决方案是附加两个调试器并同时使用它们。（我认为这是您在其他类似场景中必须做的；例如调试VB6调用本机COM对象）。我们开发了互操作调试（也称为“混合模式”）来显式地启用这个场景。它允许单个调试器调试应用程序的托管部分和本机部分。VisualStudio支持混合模式调试。
2）
正在调试服务器。一些服务器应用程序（如ASP.Net+SQL）可以代表多个用户运行代码。理想情况下，每个用户只需同时附加一个调试器并调试服务器上运行的部分代码。我们希望在未来的CLR版本中通过每appdomain调试（而不是仅仅是每个进程的调试）来支持这些场景。