CLR全面透彻解析: CLR 4中的生产诊断改进

CLR全面透彻解析: CLR 4中的生产诊断改进2011-10-30 msdn Jon Langdon在公共语言运行库（CLR）团队，我们有个小组专门提供 API 和服务，供其他人构建托管代码的诊断工具。我们所拥有（就专用的工程资源而言）的两个最大组件是托管调试和分析 API（分别是 ICorDebug* 和 ICorProfiler*）。

与其他 CLR 和框架团队类似，我们也只能通过努力开发应用程序实现我们的价值。例如，Visual Studio 团队会将这些调试和分析 API 用于他们的托管调试器和性能分析工具，还有大量第三方开发人员在使用分析 API 构建工具。

在过去 10 年中，这个领域主要关注（无论是对于 CLR 还是 Visual Studio）在开发人员的桌面系统上实现功能：在调试器中逐步运行源代码以找到代码中的错误；在性能探查器下启动应用程序来找出速度低的代码路径；使用 “编辑并继续”功能减少“编辑-构建-调试”周期所花时间等等。这些工具有助于在应用程序已经安装到用户的计算机或部署到服务器后（这两种情况以下将统称生产）查找其中的错误，我们有许多第三方供应商会以我们的工作为基础构建世界一流的生产诊断工具。

不过，客户和这些供应商也一直在向我们提供反馈，强调进一步简化应用程序整个生命周期的错误查找过程的重要性。毕竟，在应用程序生命周期中发现软件错误的时间越晚，修复代价就越高昂，这一点已成共识。

针对这类反馈意见，我们付出了大量努力，并开始将我们的诊断 API 支持的范畴向这一频谱的生产端加以扩展，CLR 4（支撑 Microsoft .NET Framework 4 的运行库）正是我们的工作成果的第一次发布。

在本文中，我将讨论我们目前认为特别棘手的一些情况、我们正在采取的解决方式以及它们提供的工具类型。具体而言，我将阐述我们如何发展了调试 API，从而对应用程序崩溃以及挂起情况进行转储调试；我还要阐述我们如何简化了对多线程问题导致的挂起进行检测的过程。

我还将说明，对已经运行的应用程序附加分析工具这项功能可如何进一步简化对这类情况进行故障排除的过程，并大大减少内存消耗过量所引发问题所需的诊断时间。

最后，我将简要说明我们如何通过消除对注册表的依赖而简化了对分析工具的部署过程。整篇文章重点都在介绍作为我们工作成果的新工具类型，不过，为了帮助您了解可如何利用我们通过 Visual Studio 发布的工作成果，我也根据情况讨论了其他一些资源。