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

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

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

d*命令 d{a|b|c|d|D|f|p|q|u|w|W} Address [/c ColumuWidth] [l Length] Address:查看address地址处的内存. ColumnWidth:Windbg每行显示的多少个数据单位.默认为16进制数字,十进制需加前缀0n Length:总共显示Address地址后的多少个数据单位. 如: db /c 0n32 06beee78 l 0n128 表示 显示06beee78之后的128个byte,每行显示32个byte, dw /c 0n

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

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

有时候我们想查看一个正在运行的程序内存中的数据,可以在任务管理器将内存状态保存为转储文件,并使用WinDBG验证,这里我们来试试: 0.安装WinDBG 1.首先写个代码用来测试 一个class public class MyClass { public int AintValue = 123; public static int BintValue = 456; public string AstringValue = "AAA"; public static string Bstr

前面我们图解了.NET里各种对象的内存布局,我们再来从调试器和clr源码的角度来看一下对象的内存布局.我写了一个测试程序来加深对.net对象内存布局的了解: using System; using System.Runtime.InteropServices; // 实际上是一个C语言里的联合体 [StructLayout(LayoutKind.Explicit)] public struct InnerStruct { [FieldOffset()] public float FloatVal

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

使用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

当我们在调试器中分析问题时, 经常需要查看不同内存块的内容以分析产生的原因, 并且在随后验证所做出的假设是否正确. 由于各个对象的状态都是保存在内存中的, 因此内存的内容也就相当于对象的状态. d命令最常见的格式就是根据指定的类型信息来显示存储在某地址中的数据. 调试器并不会去猜测这个地址上存储的是什么数据, 因为在大多数情况下猜测都是错误的. 所以需要用户显式地制定按照何种格式来解析数据. 命令格式如下: d [type] [address range] d    - 该命令按照上一个d*命令

chardet不是python自带的包需要手动安装 chardet安装命令(dos下): pip install chardet 或: pip.exe install chardet 案例: >>> import chardet>>> import urllib>>> TestData=urllib.urlopen("http://www.baidu.com/").read()>>> print chardet.d

--Count the length of string select lengthb('select * from scott.emp') as countted_by_byte, length('select * from scott.emp') as countted_by_char from dual; --For some character encoding, the length() and the lengthb() is same in english --you may us

The Universal Character Encoding Detector chardet.detect("str") 返回:{‘confidence’:1.0,'encoding':'ascii'}

命令 ========== k k命令显示的是一定数量的栈帧, 其中帧的数量是由.kframes命令来控制的, 默认值是256. kp 5 显示调用栈中前5个函数以及他们的参数. kb 5 显示调用栈中前五个函数以及他们的前三个参数. kf 5 显示在调用栈中五个函数所使用的栈的大小. 每个栈帧所占的空间使用量的计算方法是: 将当前函数的栈基指针与在函数中调用的任何一个函数栈基指针相减. 举例: 手动构造栈的实践- 如何手工构造调用栈 ============ 首先用几幅图说明一下栈的特点, 帮

命令 ========== u . u $ip 上面的两个命令是效果是一样的, 反汇编当前$ip地址上的8条命令. uf . uf $ip 上面两个命令的效果是一样的, 反汇编当前$ip地址上的整个函数. ub . ub $ip 反汇编$ip之前的8条指令. ub $ip L2a 反汇编$ip地址之前的42条指令. u $ip $ip+a 反汇编地址$ip到地址$ip+10之间的指令. 注意, 这里包括$ip, 不包括$ip+10. 举例:

MD5算法常常被用来验证网络文件传输的完整性,防止文件被人篡改.MD5 全称是报文摘要算法(Message-Digest Algorithm 5),此算法对任意长度的信息逐位进行计算,产生一个二进制长度为128位(十六进制长度就是32位)的“指纹”(或称“报文摘要”),不同的文件产生相同的报文摘要的可能性是非常非常之小的. md5sum命令采用MD5报文摘要算法(128位)计算和检查文件的校验和.一般来说,安装了Linux后,就会有md5sum这个工具,直接在命令行终端直接运行. 语法 # md

一 基础知识 在分析之前,先上一张图: 从上面可以看到,这个w3wp进程占用了376M内存,启动了54个线程. 在使用windbg查看之前,看到的进程含有 *32 字样,意思是在64位机器上已32位方式运行w3wp进程.这个可以通过查看IIS Application Pool 的高级选项进行设置: 好了,接下打开Windbg看看这个w3wp进程占用了376M内存,启动的54个线程. 1. 加载 WinDbg SOS 扩展命令 .load C:\Windows\Microsoft.NET\Fram

第一章 准备 1.1.    环境配置 _NT_DEBUGGER_EXTENSION_PATH=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 _NT_SYMBOL_PATH=SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols Path add: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 C:\Program Files\Debugging

本文为 Dennis Gao 原创技术文章,发表于博客园博客,未经作者本人允许禁止任何形式的转载. 系列博文 <WinDbg 命令三部曲:(一)WinDbg 命令手册> <WinDbg 命令三部曲:(二)WinDbg SOS 扩展命令手册> <WinDbg 命令三部曲:(三)WinDbg SOSEX 扩展命令手册> 导航目录 内置帮助命令 调试会话命令 一般信息命令 符号加载命令 模块加载命令 异常分析命令 进程信息命令 线程信息命令 堆栈信息命令 扩展帮助命令 日志扩