CLR 调试概述

利用公共语言运行时 (CLR) 调试 API，工具供应商可以编写调试器来调试运行于 CLR 环境中的应用程序。 要调试的代码可为 CLR 支持的任何代码种类。CLR 调试 API 主要是使用非托管代码实现的。 因此，调试 API 呈现为一组组件对象模型 (COM) 接口。 API 由以下各项组成：

• CLR 实现的 COM 对象和接口的集合。

• 必须由调试器实现的 COM 回调接口的集合。

CLR 调试方案

以下各部分介绍公共语言运行时调试 API 如何处理典型的调试方案。 请注意，该运行时直接支持某些方案，并且可与当前方法进行互操作来支持其他方案。

进程外调试

在进程外调试中，调试器不在所调试的进程中，而在另一个进程中（即在调试对象外部）。 此方案减少了调试器与调试对象之间的交互。 因此，它可以更准确地描述进程。

CLR 调试 API 直接支持进程外调试。 API 将处理调试器与调试对象托管部分之间的所有通信以支持托管代码调试。

虽然 CLR 调试 API 用于进程外，但某些调试逻辑（例如线程同步）却与调试对象在同一进程内。 大多数情况下，这是应该对调试器保持透明的实现详细信息。 有关线程同步的更多信息，请参见 CLR 调试体系结构。 调试 API 的缺点是在进程外使用时无法用它来检查崩溃转储。

进程内调试

在 .NET Framework 1.0 和 1.1 版本中，CLR 调试 API 支持受限的进程内调试，在受限的进程内调试中，探查器可以使用调试 API 的检查功能。 在 .NET Framework 2.0 中，进程内调试被替换为一组与分析 API 更加一致的功能。 有关这些更改的更多信息，请参见分析概述中的堆栈快照和对象检查功能。

远程进程调试

在远程进程调试中，调试器用户界面与所调试的进程不在同一计算机上。 如果调试器和调试对象在同一计算机上运行时相互影响，此方案可能很有用。 这种影响可能由下列原因引起：

• 有限资源。

• 位置依赖性。

• 影响操作系统的 Bug。

CLR 调试 API 不直接支持远程进程调试。 基于 CLR 调试 API 的调试器仍然必须存在于调试对象进程外。 因此，此解决方案需要在调试对象所在的计算机上有一个代理进程。

非托管代码调试

托管代码和非托管代码通常共存于同一进程中。 通常需要同时调试这两种代码类型。

CLR 调试 API 支持跨越托管代码和非托管代码之间的界限执行单步调试，但是不直接支持非托管代码调试。 然而，通过共享 Win32 调试功能，CLR 调试 API 可以与非托管代码调试器共存。

此外，CLR 调试 API 为调试进程提供了两种选择方案：

• “软附加”选择方案，在此选择方案中只调试进程的托管部分。 软附加到进程的调试器随后可以从该进程中分离出来。

• “硬附加”选择方案，在此选择方案中将调试进程的托管和非托管部分，并且通过调试 API 公开所有 Win32 调试事件。

混合语言环境

在组件式软件中，可以用不同的语言构建不同的组件。 调试器必须知道语言差异，以便能够用正确的格式显示数据、用正确的语法对表达式进行求值等等。

CLR 调试 API 不对混合语言环境提供任何直接支持，因为 CLR 没有源语言概念。 通过应用调试器的现有源映射功能，应该能够将给定的函数映射到实现该函数所采用的语言。

多个进程和分布式程序

组件式程序可以包括协作组件，这些组件可以在不同的进程上运行，甚至可以在整个网络中的不同计算机上运行。 调试器应该能够跟踪进程之间以及计算机之间的执行逻辑，以提供所发生事件的逻辑视图。

CLR 调试 API 不对多进程调试提供任何直接支持。 而使用 API 的调试器应该直接提供这类支持，并且用于执行此操作的现有方法应该继续有效。

API 类别

调试 API 包括以下三组接口，这三组接口通常都由 CLR 调试器使用，并均以非托管代码的形式实现：

• 支持对 CLR 应用程序进行调试的接口。

• 允许访问符号调试信息的接口，该信息通常存储在程序数据库 (PDB) 文件中。

• 支持在计算机上查询进程和应用程序域的接口。

调试 API 依赖于另外两组接口：

• 用于处理静态程序信息（比如类和方法类型信息）检查的元数据 API。

• 用于为托管代码调试器支持源级别调试的符号存储区 API。

调试接口也可以划分为下表中所示的功能类别。

标签: none