Windbg的一些简单使用命令 一.崩溃 1.  输入.ecxr;kbn得到崩溃的堆栈 其中源代码如下 2.  查看堆栈和源代码,发现第0帧导致崩溃,代码也是本地代码 输入.frame  0,切到第0帧如下 3.  输入 dv 查看当前帧的一些变量信息 发现变量p =0x00000000 二.句柄泄漏 1.  启动进程 2.  用windbg附加到进程 3.  !htrace  -enable命令开启句柄检测 4.  !htrace  –snapshot 5.  运行一段时间后 6.  !htr

在一次上线过程中iis内存飙升,随后跟运维要到站点的dump文件,使用windbg分析了clr的内存分配,找到了问题的症结,先记录如下: 使用windbg加载dump文件 1.打开windbg,File->Open Crush Dump,打开dump文件: 2.设置符号路径和站点发布文件路径 .sympath C:\MyCodesSymbols*SRV*C:\MyLocalSymbols*http://msdl.microsoft.com/download/symbols:C:\Users\Ad

在前面C++中基于Crt的内存泄漏检测一文中提到的方法已经可以解决我们的大部分内存泄露问题了,但是该方法是有前提的,那就是一定要有源代码,而且还只能是Debug版本调试模式下.实际上很多时候我们的程序会用到第三方没有源代码的模块,有些情况下我们甚至怀疑系统模块有内存泄露,但是有没有证据,我们该怎么办? 这时我们就要依靠无所不能的WinDbg了. WinDbg的!heap命令非常强大,结合AppVerifier可以对堆(heap)内存进行详细的跟踪和分析, 我们接下来对下面的代码进行内存泄漏的分析

一.背景 近期有一个项目在运行当中出现一些问题,程序顺利启动,但是观察一阵子后发现内存使用总量在很缓慢地升高, 虽然偶尔还会往下降一些,但是总体还是不断上升:内存运行6个小时候从33M上升到80M: 程序存在内存泄漏是确定无疑的了,大概出问题的方向也知道,就是程序新加入一个采集协议(BACnet协议,MSTP_DLL), 但是怎么把具体泄漏位置找出来却非常麻烦,因为这个协议是封装在一个C语言写的动态库中,想要单步调试好像不太可能, 况且源码也不再我这里: 如果到此为止,推脱给其他同事找问题,那联

一:背景 1. 讲故事 上个月有位朋友加微信求助,说他的程序跑着跑着就内存爆掉了,寻求如何解决,截图如下: 从聊天内容看,这位朋友压力还是蛮大的,话说这貌似是我分析的第三个 MES 系统了,看样子 .NET 在传统工厂是巨无霸的存在哈... 话不多说,一起用 Windbg 一探究竟吧. 二:Windbg 分析 1. 托管还是非托管 先看下进程的commit内存,用 !address -summary 即可. 0:000> !address -summary Mapping file sectio

1       问题简介 有客户反馈,打了最新补丁后,服务器的内存暴涨,一直降不下来,程序非常卡.在客户的服务器上抓了一个dump文件,开始分析. 分析问题的思路: 1.找到是那些资源占用了大量内存? 2.找到是什么原因导致内存不释放? 3.根据分析信息定位问题代码. 2       分析问题 2.1  查看GC堆的内存占用情况 Net程序大部分内存泄漏是由于没有及时垃圾回收导致的,就从GC堆开始分析. !eeheap -gc 统计一下,有8个GC堆(因为有8个CPU核),每个堆大概在1个G左右

做这个项目有点倒霉,快要验收的时候,发现微软ReportViewer控件的一个bug,导致我们的项目无法正常验收. 问题描叙:用ReportViewer本地模式做的报表,在ASP.NET页面中呈现.在asp.net服务端有一个静态页面,用户轮播报表页面.这些页面被加载到一个盒子里面,然后在电视上面显示.最终电视就可以看到我们报表轮回的切换.在推广的过程中,电视终端越来越多,暴露出一个问题,报表播放久了就会出现内存溢出的问题. 后来查资料,显示ReportViewer确实存在内存泄漏的问题,该如何

写个demo来玩一玩linux平台下使用lldb加载sos来调试netcore应用. 当然,在真实的产线环境中需要分析的数据和难度远远高于demo所示,所以demo的作用也仅仅只能起到介绍工具的作用. 通常正常情况下,分析个几天才能得出一个结论的的结果都还是比较令人开心的!,很多时候分析来分析去也搞不出个所以然,也是很正常的(当然,也是自己学艺不精(^_^)) 在linux平台下的sos调试远没有在windows下面用windbg来得舒服,该有的命令很多都没有. 微软爸爸还要加油努力啊!如果能做

Webservice WCF WebApi   注明:改编加组合 在.net平台下,有大量的技术让你创建一个HTTP服务,像Web Service,WCF,现在又出了Web API.在.net平台下,你有很多的选择来构建一个HTTP Services.我分享一下我对Web Service.WCF以及Web API的看法. Web Service 1.它是基于SOAP协议的,数据格式是XML 2.只支持HTTP协议 3.它不是开源的,但可以被任意一个了解XML的人使用 4.它只能部署在IIS上 W

一:背景 1. 讲故事 这段时间项目延期,加班比较厉害,博客就稍微停了停,不过还是得持续的技术输出呀! 园子里最近挺热闹的,精致码农大佬分享了三篇文章: 为什么要小心使用 Task.Run [https://www.cnblogs.com/willick/p/14078259.html] 小心使用 Task.Run 续篇 [https://www.cnblogs.com/willick/p/14100973.html] 小心使用 Task.Run 终篇解惑 [https://mp.weixin.

一:背景 1. 讲故事 前天那位 his 老哥又来找我了,上次因为CPU爆高的问题我给解决了,看样子对我挺信任的,这次另一个程序又遇到内存泄漏,希望我帮忙诊断下. 其实这位老哥技术还是很不错的,他既然能给我dump,那真的是遇到很棘手的疑难杂症了,我得做好心理准备,沟通下来大概就是程序的内存会缓慢膨胀,直到自毁,问题就是这么一个问题,接下来祭出我的看家工具 windbg. 二: windbg 分析 1. 到底哪里泄漏了? 我在之前很多篇文章中都说过,遇到这种内存泄漏,首先就要排查到底是 托管堆

一:背景 1. 讲故事 上周四有位朋友加wx咨询他的程序内存存在一定程度的泄漏,并且无法被GC回收,最终机器内存耗尽,很尴尬. 沟通下来,这位朋友能力还是很不错的,也已经做了初步的dump分析,发现了托管堆上有 10w+ 的 byte[] 数组,并占用了大概 1.1G 的内存,在抽取几个 byte[] 的 gcroot 后发现没有引用,接下来就排查不下去了,虽然知道问题可能在 byte[],但苦于找不到证据. 那既然这么信任的找到我,我得要做一个相对全面的输出报告,不能辜负大家的信任哈,还是老规

一:背景 1. 讲故事 七月底的时候有位朋友在wx上找到我,说他的程序内存占用8G,托管才占用1.5G,询问剩下的内存哪里去了?截图如下: 从求助内容看,这位朋友真的太客气了,动不动就谈钱,真伤感情,如果有朋友一直关注我的分享,应该知道我一直都是免费分析dump,当然我的知识和经验也是有边界的,有些dump我也搞不定,不过我还是尽自己最大努力去寻找答案. 在这里我有必要说一下职场,在我的潜意识或者在我的团队中,这些很难搞的问题当然由技术领导去搞定,但我发现有好几起却不是这样的,技术经理搞不定转包

一:背景 1. 讲故事 说实话,这篇dump我本来是不准备上一篇文章来解读的,但它有两点深深的感动了我. 无数次的听说用 Unity 可做游戏开发,但百闻不如一见. 游戏中有很多金庸武侠小说才有的名字,太赏心悦目了. 000000df315978a8 0 3 玉骨扇 000000df31597cd8 0 3 云龙枪 000000df31596d88 0 3 阴风爪 000000df315967a8 0 4 雪魂丝链 000000df31596ad0 0 4 乙木神剑 000000df315960

一:背景 1. 讲故事 上个月中旬,星球里的一位朋友在微信找我,说他的程序跑着跑着内存会不断的缓慢增长并无法释放,寻求如何解决 ? 得,看样子星球还得好好弄!!! 不管怎么说,先上 windbg 说话. 二:Windbg 分析 1. 经验推理 从朋友的截图看,有大量的 8216 字节的 byte[],这表示什么呢? 追随本系列的朋友应该知道,有一篇 某三甲医院 的内存暴涨的dump中,也同样有此 size= (8216-24=8192) 的 byte[] 数组, 他的问题是 Oracle 中读取

一:背景 1. 讲故事 上个月有位朋友找到我,说他的程序出现了内存泄漏,不知道如何进一步分析,截图如下: 朋友这段话已经说的非常言简意赅了,那就上 windbg 说话吧. 二:Windbg 分析 1. 到底是哪一方面的泄漏 根据朋友描述,程序运行一段时间后,内存就炸了,应该没造成人员伤亡,不然也不会跟我wx聊天了,这里可以用 .time 看看当前的 process 跑了多久. 0:000> .time Debug session time: Thu Oct 21 14:54:39.000 202

一:背景 1. 讲故事 去年十月份有位朋友从微信找到我,说他的程序内存要炸掉了...截图如下: 时间有点久,图片都被清理了,不过有点讽刺的是,自己的程序本身就是做监控的,结果自己出了问题,太尴尬了 二:Windbg 分析 1. 托管还是非托管 这个是甄别内存问题的第一步,通过 !address -summary 和 !eeheap -gc 两个命令基本就可以断定. 0:000> !address -summary Mapping file section regions... Mapping m

一:背景 上一篇我们聊到了如何用 PerfView 去侦察 NTHeap 的内存泄漏,这种内存泄漏往往是用 C 的 malloc 或者 C++ 的 new 分配而不释放所造成的,这一篇我们来聊一下由 VirtualAlloc 方法造成的泄漏如何去甄别? 了解 VirtualAlloc 的朋友肯定说, C# 这种高层语言怎么可能会用 VirtualAlloc 呢?即便是 C++ 大概率也不会用这个,其实这么说还是世面见少了,经历的案例太少,接下来我们就来简要聊一聊. 二: C# 中真的会用 Vir

一:背景 前几篇我们聊的都是 非托管内存泄漏,这一篇我们再看下如何用 PerfView 来排查 托管内存泄漏 ,其实 托管内存泄漏 比较好排查,尤其是用 WinDbg,毕竟C#是带有丰富的元数据,不像C++下去就是二进制. 二:如何分析 PerfView 用的是权重占比来寻找可疑的问题函数,为了方便讲述,我们先上一段问题代码. internal class Program { static void Main(string[] args) { Task.Run(Alloc1); Task.Run

一:背景 这篇我们来聊一下 PerfView 在协助 WinDbg 分析 Dump 过程中的两个超实用技巧,可能会帮助我们快速定位最后的问题,主要有如下两块: 洞察内存泄漏中的静态大集合变量名. 验证当前程序的 GC 模式. 这里就把经验分享一下,希望让大家少走弯路. 二:如何洞察 1. 查看静态变量名 如果有过 dump 分析经验的朋友应该知道,当你历经千辛万苦在 内存泄漏 的dump文件中找到了那个内存泄漏最大的集合,但遗憾的是,你不知道这个 集合 的变量名叫什么? 为了方便讲述,先上一段测