SOS.dll (SOS debugging extension) The SOS Debugging Extension (SOS.dll) helps you debug managed programs in Visual Studio and in the Windows debugger (WinDbg.exe) by providing information about the internal Common Language Runtime (CLR) environment.

本文为 Dennis Gao 原创技术文章,发表于博客园博客,未经作者本人允许禁止任何形式的转载. 系列博文 <WinDbg 命令三部曲:(一)WinDbg 命令手册> <WinDbg 命令三部曲:(二)WinDbg SOS 扩展命令手册> <WinDbg 命令三部曲:(三)WinDbg SOSEX 扩展命令手册> 导航目录 扩展加载命令 对象审查命令 数据结构审查命令 代码堆栈审查命令 垃圾回收历史审查命令 诊断工具命令 SOS 调试命令手册 扩展加载命令 命令 描述

本文为 Dennis Gao 原创技术文章,发表于博客园博客,未经作者本人允许禁止任何形式的转载. 系列博文 <WinDbg 命令三部曲:(一)WinDbg 命令手册> <WinDbg 命令三部曲:(二)WinDbg SOS 扩展命令手册> <WinDbg 命令三部曲:(三)WinDbg SOSEX 扩展命令手册> 导航目录 扩展加载命令 SOSEX扩展命令 SOSEX 调试命令手册 扩展加载命令 命令 描述 .load .load sosex .load C:\Pro

SOS是什么? 直观来说,sos就是一个程序集文件.这个程序集的作用就是让我们在使用windbg分析.net进程时,更加方便快捷.通过sos,我们可以清晰的查看CLR运行时的各类信息,辅助我们去理解托管内存的状态和含义. 这个程序集是随.NET Framework一起安装的,一般不需要单独安装.在我本机自动安装的位置如下: C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll C:\Windows\Microsoft.NET\Framewor

在博客堂的不是我舍不得 - High CPU in GC(都是+=惹的祸,为啥不用StringBuilder呢?). 不是我舍不得 - .NET里面的Out Of Memory 看到很多人在问如何分析dump,所以就写下了这篇短文,抛砖引玉. 一.安装 DebuggingToolsforWindows: 从以下 Microsoft 网站下载 DebuggingToolsforWindows:http://www.microsoft.com/whdc/devtools/debugging/inst

在CLR的世界中,有一系列的令人Amazing的技术和架构.其中,CLR对应用程序在内存中内存分配,执行模型,程序之间的交互等一系列的技术,值得每一个致力于DotNet平台的技术人员深究. 编程人员在开发的过程中,如果把程序集的加载(Assemblies Load),反射(Reflection),寄宿(Hosting),应用程序域(AppDomain),这四种技术结合起来使用的话,不仅能更好的使用CLR这个平台提供的强大的功能,而且能够构建更安全,更健壮的应用程序代码. 这篇博文里,就是使用托管

1.打开windbg,加载dump.使用命令确定dump的clr版本:lm vm mscorwks 或者lm vm clr(!eeversion可以查看加载后的sos版本) 2.找到对应的mscorwks.dll文件,命名为:mscordacwks_AMD64_AMD64_2.0.50727.5477.dll mscordacwks_X86_X86_2.0.50727.5477.dll 3.把上面的文件放到符号目录:mscordacwks_AMD64_AMD64_2.0.50727.5477.d

http://blog.csdn.net/garyye/article/details/4788070   在使用VS进行托管应用程序的调试的时候,有的时候总感觉有些力不从心.譬如查看一个托管堆或者计算堆栈的时候,VS就不能胜任了.这个时候,Windbg+SOS扩展调试模块就为我们提供了一个很好的解决方案.我们看一段代码:class Program    {        static void Main(string[] args)        {            Program b

原文地址: http://www.cnblogs.com/Lawson/archive/2011/01/23/1942692.html 很早看到windbg+sos方面的知识,一直没仔细学习,也许因为自己做的系统还不够复杂,也没线上真实环境查看的权限,一直没学习这方面的知识,最近几天仔细找了这方面的资料,自己也写了个可能造成高CPU高内存的测试web页面,发现确实不错,即使一个生手,也可以用工具连蒙带骗的猜出哪里出了问题,当然对一些命令和内部标示更熟悉了后,可以更好的找出问题所在,非常值得学习.

dumpheap 时提示: 0:105> !dumpheap -stat The garbage collector data structures are not in a valid state for traversal. It is either in the "plan phase," where objects are being moved around, or we are at the initialization or shutdown of the gc h

C#编程模式之扩展命令 前言 根据上一篇的命令模式和在工作中遇到的一些实际情况,有了本篇文章,时时都是学习的一个过程,会在这个过程中发现许多好的模式或者是一种开发方式,今天写出来的就是我工作中常用到的,自己感觉这种方式很优雅很漂亮,就自己试着实现了一下,可能原框架中不是这样的,有许多不足之处还请大家指点. 需求 我还不清楚这种方式是模式还是框架开发中用到的技术,我暂且叫它为命令控制器吧. 命令控制器的主要功能就是获取用户提供的命令,然后来执行命令. 在这里我把要执行的“命令”设计成一个函数,会对

调试dump文件,加载相匹配版本的sos/clr时,绝大多数都是可以正常使用的. 然而凡事都有例外,今天在做类似工作时,遇到了错误: CLRDLL: Consider using ".cordll -lp <path>" command to specify .NET runtime directory. Failed to load data access DLL, 0x80004005 再次指定mscordacwks.dll所在路径,问题解决. To debug a m

收到一个dump文件,运行环境的.net framework的详细版本是多少呢? dump信息与性能计数器结合分析时,想知道该dump运行的进程号是多少? dump定位到有效的堆栈信息,而对应的源码是怎么写的呢? mex扩展提供了大量节省人力搜索的命令,类似扩展可以到windbg网站了解:http://www.windbg.org/ 0:102> .time Debug session time: Wed Nov 15 10:44:19.000 2017 (UTC + 8:00) System

使用windbg 加载sos.dll时,经常碰到报The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll) failed, Win32 error 0n193这样的错误,按照提示,应该为加载的dll版本不对造成的.应该是因为在x64环境下,加载了X86的版本.指定路径加载.load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll,发现OK

windbg 查找函数:x exe!main* 条件断点打印字符:bp 7199a2b0 ".printf \"message:%ma\", poi(@esp+8);.echo;g"// 搜索内存:s -a 0000000000780000  L8000000  "This is a test2" !address,可以查看进程的堆布局,堆属性.!address my_addr,直接查看具体地址. bp  myexe+0x85d01 "

暂时不用Windbg,用VS来调试CLR. 1) Enable unmanaged debugging 2) Load sos.dll into vs. !DumpHead -type SimpleClass 获得SimpleClass对象的一个地址,0x0280b630 3) 观察0x0280b630-4=0x0280b62c 另给出一个method table的布局图: 参考文章: http://www.microsoft.com/china/MSDN/library/netFramewor

Azure ARM模板中,给虚拟机安装扩展脚本的命令 "resources": [ { "apiVersion": "[variables('apiVersion')]", "type": "Microsoft.Compute/virtualMachines/extensions", "name": "[concat(parameters('nginxVmNamePrefix'

命令浏览器窗口显示并存储调试器命令的文本结果.此窗口创建命令引用,使您可以查看特定命令的结果,而无需重新输入该命令.命令浏览器窗口还提供了对存储的命令的导航,因此您可以比使用调试器命令窗口更快地访问命令. 命令浏览器的打开 通过菜单Veiw--->Command Browser 通过快捷键Ctrl+N 通过工具栏 使用命令浏览器 用上面的方式打开的窗口如下: 在命令浏览器窗口中,可以执行以下操作: 若要输入命令时,其在命令框键入. 若要查看以前输入的命令的结果,请使用Start, Prev, 和

WinDBG提供了多种设断点的命令: bp 命令是在某个地址 下断点, 可以 bp 0x7783FEB 也可以 bp MyApp!SomeFunction . 对于后者,WinDBG 会自动找到MyApp!SomeFunction 对应的地址并设置断点. 但是使用bp的问题在于:1)当代码修改之后,函数地址改变,该断点仍然保持在相同位置,不一定继续有效: 2)WinDBG 不会把bp断点保存工作空间中 . bu 命令是针对某个符号 下断点. 比如 bu MyApp!SomeFunction .

1.dt  视图结构内容 dt + 结构名   要么 dt + 结构名 + 住址 kd> dt _object_header nt!_OBJECT_HEADER +0x000 PointerCount : Int4B +0x004 HandleCount : Int4B +0x004 NextToFree : Ptr32 Void +0x008 Type : Ptr32 _OBJECT_TYPE +0x00c NameInfoOffset : UChar +0x00d HandleInfoOff