调试器不应该改变行为
理想情况下，无论是否附加了调试器，应用程序都会执行相同的操作。这源于非常实际的动机：
- bug通常首先出现在调试器之外（一些测试失败），然后您只想在调试器下重新运行测试来重新生成问题。如果调试器更改了行为，这将妨碍您重新编程的能力。
- 另一方面，开发人员可以在IDE下开发代码，并通过在调试器下检查代码来确保代码正常工作。如果调试器引入了隐藏缺陷的行为更改，那么开发人员将在这里忽略它。
- 如果应用程序的行为只发生在调试器下，人们会将其行为归咎于调试器。例如，如果一个应用程序只在调试器下抛出异常，那么人们会认为调试器导致了异常，或者调试器已损坏并错误地报告了异常。（我们发现了很多这样的缺陷）。这种错误的指责会阻碍真正的问题得到解决。
- 行为差异会削弱人们对调试器的信心。
- 调试时，调试器是否附加到正在运行的进程，或者调试对象是否从调试器下启动都不重要。行为上的改变会在这两种情况之间造成一个楔子。这对于只能附加的调试器场景特别重要（例如，调试ASP.Net或SQL）
那么，为什么应用程序在托管调试器下的执行方式会有所不同呢？
- 用户检查：最大的罪魁祸首：程序可以显式调用System.Diagnostics.Debugger.IsAttached以询问是否附加了托管调试器，然后行为不同。（win32 API IsDebuggerPresent（）同样检查是否附加了本机调试器。）。这是最容易引起痛苦的方法。例如，如果附加了托管调试器，WinForms将显式使用不同的“可调试”WndProc。这个可调试的wndproc在用户回调（不可调试的wndproc没有）周围有一个额外的try-catch，用于通知用户回调是否抛出异常。另一个最受欢迎的方法似乎是在附加了调试器以通知用户时抛出异常。
- CLR/JIT检查：ICorDebug允许调试器更改实时编译器的codegen选项（例如禁用优化）。这会导致从IL生成不同的本机代码，这肯定会改变行为。如果附加了调试器，v1.0和v1.1clrs中的jit实际上会自动生成可调试代码。这是个非常糟糕的主意。在v2.0中，JIT显式地不知道是否附加了调试器，尽管调试器可以显式地请求JIT生成可调试的代码。
- 操作系统检查：在极少数情况下，操作系统可能会处理不同的事情。例如，在Windows上，如果附加了本机（或互操作）调试器，则不会针对未处理的异常执行筛选器。（自己试试看）
- 利用非确定性：应用程序执行的某些部分是不确定的，例如定时问题和对机器范围内状态的任何引用（例如页面共享）。例如，在多线程应用程序中，调试器肯定会影响计时，这可能会暴露（或隐藏）现有的竞争条件。我个人觉得这比我想的要普遍得多。正因为这个原因，我不得不调试太多只会在调试器之外的优化版本上重新生成的bug。
- 调试器检查：以上所有原因都假定调试器行为良好。然而，作为API的产品，我们不能阻止API的使用者做改变debuggee行为的“愚蠢的”事情。例如：
.在托管进程下启动：应用程序通常在自己的进程中启动。有人可以编写一个调试器，在宿主进程内部启动调试对象。这是调试和非调试的区别。
.Func eval：属性求值（Func eval）的每个实例都是只在调试器下运行的代码。如果函数求值有任何副作用，则可以更改调试对象的行为。如果调试器在不提示用户的情况下执行函数求值，这一点尤其重要。
我觉得CLR调试器团队对这个问题太天真了。幸运的是，后面版本中采取了很多伟大的措施来解决这个问题：
- 已经认识到这一点很重要。VS对手帮助我们明确了这一点。
- 已经明确地消除了任何依赖于是否附加调试器的非调试器CLR行为。如前所述，JIT将不再自动生成可调试代码。我们现在还将始终跟踪jit的调试信息（jit生成的IL-->Native映射）。
- 已经尝试识别用户呼叫的常见模式调试器.IsAttached然后让ICorDebug提供其他解决方案，这些解决方案不需要调试人员有不同的行为。例如，Winforms具有可调试回调，因为它们希望在异常跨越回调和处理程序之间的边界时通知用户。如果ICorDebug只是（a）意识到这个边界是重要的，并且（b）提供了一个异常将在其上展开的通知，那么Winforms就永远不需要添加try-catch。