一般情况下，开发者都是在开发期内进行系统调试的，VS.NET提供的调试工具在这个时期可以很方便地设置断点、监视变量。但也有例外的情况，设想一个已经完成全面测试的系统，进入部署阶段，在目标机上也安装好了，一运行却发现某个功能报错，而且还是不能直接看出原因的深层错误。部署人员与开发人员联系，报告这个错误，开发人员于是在开发机上以同样操作步骤重现过程，却没碰到错误。根据经验，这种运行差异性是由不同目标机的运行环境存在区别导致的。遇到这种情况，如何用最高效的方式查找到错误所在呢？是让开发人员赶到部署现场，在目标机上安装VS.NET进行调试呢，还是干脆把目标机搬回开发环境中再做测试？显然，这两种方法都是缺乏效率的。
更有效的方法，是使用部署期调试工具。.net framework SDK提供了一个CLR调试器——DbgCLR.exe（放在SDK\V1.X\GuiDebug目录下），它的作用就是在缺乏VS.NET的时候，对使用托管代码的系统进行调试。断点、单步执行、变量监视、控制台输出，这些VS.NET具备的功能它都具备。这个工具的全部文件大小只有1兆多，十分适合部署人员随身携带。
下面说说具体的调试步骤。对于单机系统或者C/S系统，调试步骤为：
1）在目标机上运行系统程序（假定为abc.exe），并确认它是以Debug模式编译而成的
2）启动DbgCLR.exe
3）选择“文件”－“打开”，打开与发生错误所在业务流程有关的源代码文件，如*.vb、*.cs等
4）选择“工具”－“调试进程”，在可用进程中选中abc.exe，并点击“附加”，然后关闭对话框
5）在代码文件的可疑语句处设置断点，然后按照出现报错的操作流程操作abc.exe
6）之后就跟使用VS.NET一模一样咯，略～
对于B/S系统，步骤稍微有些不同：
0）设置相关页面的<% @Page Debug="True" …… %>
1）用IE请求要调试的页面，并确认程序集是以Debug模式编译而成的
2）（同C/S）
3）（同C/S）
4）选择“工具”－“调试进程”，在可用进程中选中aspnet_wp.exe（win2k中）或w3wp.exe（win2003中），并点击“附加”，然后关闭对话框
5）在代码文件的可疑语句处设置断点，然后按照出现报错的操作流程在IE中操作页面
6）（同C/S）
* 特别注意：当调试器附加到asp.net的进程后，会冻结对目标机上任何其他应用程序的请求。因此，需要适当选择调试时机，或者事先发布针对其他系统的维护通告。
本文同时发表于网易社区.Net版：
http://p5.club.163.com/viewArticleByWWW.m?boardId=net&articleId=net_104ac6c1cc93824&boardOffset=0