使用Windows Debugger调试托管代码----引用自官方帮助文档

本文介绍了如何使用Windbg、CDB和NTSD等Windows调试工具来调试包含托管代码的目标应用程序。为了调试托管代码,必须加载SOS调试扩展(sos.dll)和数据访问组件(mscordacwks.dll)。文章还详细解释了不同版本的.NET Framework所对应的CLR版本及调试过程中需要注意的细节。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

以下文字引用在Windbg的帮助文档。觉得对初次调试托管代码,非常有用,故粘贴至此。

=========================================================================================================

 

Debugging Managed Code Using the Windows Debugger

You can use the windows debuggers (WinDbg, CDB, and NTSD) to debug target applications that contain managed code. To debug managed code, you must load the SOS debugger extension (sos.dll) and a data access component (mscordacwks.dll).

The windows debuggers are separate from the Visual Studio debugger. For information about the distinction between the windows debuggers and the Visual Studio debugger, see Windows Debugging.

Introduction to Managed Code

Managed code is executed together with the Microsoft .NET common language runtime (CLR). In a managed-code application, the binary code that the compiler produces is in Microsoft intermediate language (MSIL), which is platform-independent.

When managed code is run, the runtime produces native code that is platform-specific. The process of generating native code from MSIL is called just-in-time (JIT) compiling. After the JIT compiler has compiled the MSIL for a specific method, the method's native code remains in memory. Whenever this method is later called, the native code executes and the JIT compiler does not have to be involved.

You can build managed code by using several compilers that are manufactured by a variety of software producers. In particular, Microsoft Visual Studio can build managed code from several different languages including C#, Visual Basic, JScript, and C++ with managed extensions.

The CLR is not updated every time the .NET Framework is updated. For example, versions 2.0, 3.0, and 3.5 of the .NET Framework all use version 2.0 of the CLR. The following table shows the version and filename of the CLR used by each version of the .NET Framework.

.NET Framework versionCLR versionCLR filename
1.11.1mscorwks.dll
2.02.0mscorwks.dll
3.02.0mscorwks.dll
3.52.0mscorwks.dll
4.04.0clr.dll
4.54.0clr.dll

 

Debugging Managed Code

To debug managed code, the debugger must load these two components.

Note  For all versions of the .NET Framework, the filename of the DAC is mscordacwks.dll, and the filename of the SOS debugger extension is sos.dll.

Loading mscordacwks.dll and sos.dll (live debugging)

Assume that the debugger and the application being debugged are running on the same computer. Then the .NET Framework being used by the application is installed on the computer and is available to the debugger.

The debugger must load a version of the DAC that is the same as the version of the CLR that the managed-code application is using. The bitness (32-bit or 64-bit) must also match. The DAC (mscordacwks.dll) comes with the .NET Framework. To load the correct version of the DAC, attach the debugger to the managed-code application, and enter this command.

.cordll -ve -u -l

The output should be similar to this.

CLRDLL: Loaded DLL C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll
CLR DLL status: Loaded DLL C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll

To verify that the version of mscordacwks.dll matches the version of the CLR that the application is using, enter one of the following commands to display information about the loaded CLR module.

lmv mclr (for version 4.0 of the CLR)

lmv mscorwks (for version 1.0 or 2.0 of the CLR)

The output should be similar to this.

start             end                 module name
000007ff`26710000 000007ff`2706e000   clr        (deferred)             
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
...

In the preceding example, notice that the version of the CLR (clr.dll) matches the version of the DAC (mscordacwks.dll): v4.0.30319. Also notice that both components are 64-bit.

When you use .cordll to load the DAC, the SOS debugger extension (sos.dll) might get loaded automatically. If sos.dll doesn't get loaded automatically, you can use one of these commands to load it.

.loadby sos clr (for version 4.0 of the CLR)

.loadby sos mscorwks (for version 1.0 or 2.0 of the CLR)

As an alternative to using .loadby, you can use .load. For example, to load version 4.0 of the 64-bit CLR, you could enter a command similar to this.

.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll

In the preceding output, notice that the version of the SOS debugger extension (sos.dll) matches the version of the CLR and the DAC: v4.0.30319. Also notice that all three components are 64-bit.

 

Loading mscordacwks.dll and sos.dll (dump file)

Suppose you use the debugger to open a dump file (of a managed-code application) that was created on another computer.

The debugger must load a version of the DAC that is the same as the version of the CLR that the managed-code application was using on the other computer. The bitness (32-bit or 64-bit) must also match.

The DAC (mscordacwks.dll) comes with the .NET Framework, but let's assume that you do not have the correct version of the .NET Framework installed on the computer that is running the debugger. You have three options.

  • Load the DAC from a symbol server. For example, you could include Microsoft's public symbol server in your symbol path.
  • Install the correct version of the .NET Framework on the computer that is running the debugger.
  • Get the correct version of mscordacwks.dll from the person who created the dump file (on another computer) and manually copy it to the computer that is running the debugger.

Here we illustrate using Microsoft's public symbol server.

Enter these commands.

.sympath+ srv* (Add symbol server to symbol path.)

!sym noisy

.cordll -ve -u -l

The output will be similar to this.

CLRDLL: Unable to get version info for 'C:\Windows\Microsoft.NET
   \Framework64\v4.0.30319\mscordacwks.dll', Win32 error 0n87

SYMSRV:  C:\ProgramData\dbg\sym\mscordacwks_AMD64_AMD64_4.0.30319.18010.dll
   \5038768C95e000\mscordacwks_AMD64_AMD64_4.0.30319.18010.dll not found

SYMSRV:  mscordacwks_AMD64_AMD64_4.0.30319.18010.dll from 
   http://msdl.microsoft.com/download/symbols: 570542 bytes - copied         
...
SYMSRV:  C:\ProgramData\dbg\sym\SOS_AMD64_AMD64_4.0.30319.18010.dll
   \5038768C95e000\SOS_AMD64_AMD64_4.0.30319.18010.dll not found

SYMSRV:  SOS_AMD64_AMD64_4.0.30319.18010.dll from 
   http://msdl.microsoft.com/download/symbols: 297048 bytes - copied         
...
Automatically loaded SOS Extension
...

In the preceding output, you can see that the debugger first looked for mscordacwks.dll and sos.dll on the local computer in C:\Windows\Microsoft.NET and in the symbol cache (C:\ProgramData\dbg\sym). When the debugger did not find the correct versions of the files on the local computer, it retrieved them from the public symbol server.

To verify that the version of mscordacwks.dll matches the version of the CLR that the application was using, enter one of the following commands to display information about the loaded CLR module.

lmv -mclr (for version 4.0 of the CLR)

lmv -mscorwks (for version 1.0 or 2.0 of the CLR)

The output should be similar to this.

start             end                 module name
000007ff`26710000 000007ff`2706e000   clr        (deferred)             
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
...

In the preceding example, notice that the version of the CLR (clr.dll) matches the version of the DAC (mscordacwks.dll): v4.0.30319. Also notice that both components are 64-bit.

Using the SOS Debugger Extension

To verify that the SOS debugger extension loaded correctly, enter the .chain command.

0:000> .chain
Extension DLL search Path:
...
Extension DLL chain:
    C:\ProgramData\dbg\sym\SOS_AMD64_AMD64_4.0.30319.18010.dll\...
        ...
    dbghelp: image 6.13.0014.1665, API 6.2.6, built Wed Dec 12 03:02:43 2012
...

To test the SOS debugger extension, enter !sos.help. Then try one of the command provided by the SOS debugger extension. For example, you could try !sos.DumpDomain or the !sos.Threads command.

Notes

Sometimes a managed-code application loads more than one version of the CLR. In that case, you must specify which version of the DAC to load. For more information, see .cordll.

The Windows 8 Debugging Tools for Windows package does not include any version of sos.dll. For version 1.x of the .NET Framework, sos.dll is not included in the .NET Framework installation. To get sos.dll for .NET Framework 1.x, download the Windows 7 Debugging Tools for Windows package. For later versions of .NET Framework , sos.dll is included in the .NET Framework installation.

 

 

 

Send comments about this topic to Microsoft

Build date: 7/8/2013

© 2013 Microsoft. All rights reserved.

 

转载于:https://www.cnblogs.com/wigis/p/8182601.html

这是一个windows脚本调试器程序。 绿色:只需复制文件到同一目录下就可以了。 纯净:基本不使用注册表,只是在注册文件类型图标和文件关联时才使用了注册表。 无毒:绝对没有任何恶意代码,但是由于程序会自动产生临时的批处理文件,可能会被杀毒软件误报。 注意:如果不能启动,下载vcredist_x86.exe安装VC运行库,然后再试。 已经实现的功能: 设置断点; 在断点命中时在代码编辑器指示哪个断点被命中。 在断点命中时可以观察现场状态【变量、ErrorLevel、当前目录】; 如果批处理没有调用Exit退出,那么可以观察到批处理执行完的现场状态; 调试暂停时会自动打开/切换文件并滚动代码窗口,使当前断点可见; 可以预设批处理执行前的环境变量和当前目录。 工程管理,也就是管理批处理文件、断点、观察变量、初始环境变量、初始当前目录、批处理入口文件、批处理文件命令行参数的信息。 支持用户自定义界面,使用标签多文档界面和停靠栏。 双击.bdc文件,会启动windows脚本调试器。 附带使用手册和批处理指南。 准备实现的功能: 在断点命中时修改环境变量或者当前目录; 语法分析【代码着色、语法检查的基础】; 语法检查; 代码着色; 内置命令帮助; 不打算实现的功能: 我感觉批处理编程并不能提供多少智能提示,所以就不做了。 局限性: 代码编辑器暂时不支持中文,这个是最大的限制了,我会在下个版本解决这个问题; 只可以在批处理语句之前加断点,不可以在空行、标签行和右括号)开头的行加断点,不可以在非批处理代码处加断点; 不支持单步调试; 必须在调试之前加断点,在调试之后加的断点,只能在以后的调试会话中起作用。 启动批处理脚本只能接受10个参数,这个限制好像问题不大。 目前可能还有bug。 注意: 不要调试本程序所在目录下的那三个批处理程序,否则会出现无法预料的行为。为了保险,请把他们设为只读隐藏文件。 可以把halt.exe也设为只读隐藏文件。 我会持续改进本程序。 email: cdp97531@sina.com blog: http://hi.baidu.com/chendeping/home
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值