使用Windbg+sos+sosex从内存转储详细分析对象引用,排查.NET服务应用内存暴增

作者:V君 发布于:2018-8-22 12:37 Wednesday 分类:填坑经验

TL;DR

1) 准备:先载入转储

 如果缺少dll, 去 https://sos.debugging.wellisolutions.de/ 找

 下来放windbg旁边,然后重新载入.

2) 初始化:载入sos和sosex [.loadby sos mscorwks],[.load sosex],首次要执行[!bhi]

3) 对象统计:用sos的[!dumpheap -stat]或者sosex的[!sosex.mfrag -stat]获取结果

4) 枚举对象:用sos的[!dumpheap -type <上结果类名>]就能刷出

  sosex的[mfrag -mt:类名]如果能用就可以直接点击链接, 这次不知道为啥不工作.

5) 查找引用:用sosex的[!refs <上结果地址>]

  顺着地址链接一路跟踪就能定位内存占用的代码位置.

 

 

必须扯:

阅读全文>>

标签: 软件开发 C# 调试技术 windbg 软件故障诊断 sosex

评论(0) 引用(0) 浏览(1290)

排查ASP.NET响应迟钝.用DebugDiag分析转储,再用WinDbg+sosex查看调用参数

作者:V君 发布于:2017-6-9 17:01 Friday 分类:填坑经验

WEB应用程序出现响应很慢甚至卡死的现象,

Server Admin 通过 DebugDiag 分析转储发现有个请求特别耗时间 (一个小时以上)


于是锅放到我这里辣.


DebugDiag得出堆栈已经显示具体代码位置了, 

想知道哪些数据被操作,还需要知道传入了哪些参数,这时候必须请出WinDbg+sosex了.

 

参考其 sosex 的 readme.txt MSDN文章 得知 !mk 命令可以查看当前线程调用堆栈

要切换当前线程 使用 ~*s 命令 (更多命令参见 windbg.info文章 )


搞起! .load sosex 再 ~*s 然后 !mk 这样就可以看到刚才的堆栈了,确保没选错线程

然而参数还没出来... 别急,呔! !mdso 列出当前线程堆栈上下文对象值

这个命令支持使用参数 /t:类名 来筛选结果. 这次排查过程顺利得有些出乎意料哇 乂目.

 

标签: 软件开发 ASP.NET 调试技术 windbg

评论(0) 引用(0) 浏览(1653)

使用Debug Diagnostic Tool分析.net转储

作者:V君 发布于:2016-10-25 11:26 Tuesday 分类:填坑经验

TL;DR:

去M¥官网下载该工具, 对应其x86/x64. 安装时选择关联文件类型. 

装好之后双击要分析的dmp文件. 等一会儿. 一个可视化的mht分析报表就出来了.

注意这工具只能在Vista(NT6)以上环境运行.


转储dmp文件可以用Sysinternals出品的免费系统工具Process Explorer来做.


听我扯扯:

虽然WinDbg+sos/sosex很强大, 但是用起来很复杂, 载入符号也很慢.

于是找到了这货来帮忙, 尽管和前者比起来就差不能在内存中找对象.

但是非常方便收集异常信息以及线程堆栈.

标签: 软件开发 C# 调试技术 windbg

评论(0) 引用(0) 浏览(1831)

[更新]使用WinDbg分析转储文件 找出C#程序内存占用过大的原因

作者:V君 发布于:2015-9-15 14:37 Tuesday 分类:填坑经验

TL;DR: 

1)打开windbg载入dmp

2).loadby sos mscorwks

3)!dumpheap -stat 

你写的程序你估计就知道为啥了


扯扯:

这次不是进程崩溃, 是另一个服务进程内存占用异常的大 , 超过4GB

原因诊断十分顺利, 然并卵,

因为某个环节需要调用第三方服务接口来解析数据,

这个接口似乎承受不住请求密度, 出现严重延迟现象

进程内部队列一直堆积着, 内存就撑大了 _(:з」∠)_


参考来源 调试内存泄漏问题的一些经验 by Dawei XU

 

After.Ps:
另一种方式,使用 sosex 下载来丢windbg旁边
1).load sosex
2)!sosex.mfrag -stat

参考来源 debugging.io


继续补充:

当不是你写的程序, 然而你又看到大量String而不知所措时

先用!strings命令来刷刷内存中的字符串, 适当的时候按暂停, 不然会卡死你

然后总结一下内容,看看有没有大片有规律的字符串

使用 !gcroot 每行前面的地址查看是什么地方引用了它 (参考来源: theartofdev.com

再进一步: !mdt 出来的根对象地址, 如果是List<T> 还可以查看内容哟

顺着items进去,点击 expand first 40 items, 嗯嗯 这下真相大白啦

(我不会说之前的人真是丧心病狂, 60多万行1G以上内容,

居然直接查询出来放到内存里面去挨个处理) ‘皿’

标签: 软件开发 C# 调试技术 windbg

评论(0) 引用(0) 浏览(2573)

使用Windbg分析转储来定位高CPU占用的C#代码

作者:V君 发布于:2015-8-6 14:51 Thursday 分类:填坑经验

今天运维告诉我服务器上出现使用大量 CPU 的进程.

要想定位/调优必须知道这些 CPU 处理量都用去做啥然后才能动刀子.

生产环境不能附加调试, 只能绕点弯路.


服务器是Win2003 x64


当时马上就想起 Procexp 能查看线程的 CPU 使用量, 运气好还能看到本地映像的调用堆栈.

不过这次运气并不太好, 调用堆栈只能看到 kernel32.dll , 之后啥都,看不到..

 

于是找找看有没有专门的 .net dump / 堆栈查看工具.

找到了Managed Stack Explorer/CLR Stack Explorer

前者只能查看32位进程, 放到服务器上运行啥也刷不出

后者在工作机上能刷出所有进程,还能标出是不是64位, 然而在服务器上也是啥都刷不出...


算了还是请出高大上的 WinDbg 吧. 让运维用 Procexp 做了个 mini Dump.

在用 WinDbg 打开 dmp 文件, 载入 sosex , 呃, 提示需要完整内存转储.

好吧于是做了个了个完整内存转储 -- 1G大的dmp文件..

 

输入 ~ 回车, 对应 Procexp 线程列表占用 CPU 高的 TID 对应这边十六进制ID

然后 ~*e!mk 回车 列出所有线程堆栈, 然后, Bingo! 

完整的堆栈信息弄到了, 足足61个堆栈帧, 详细的列出函数名称, 部分还提示了源代码行号.

这样就能够精确定位占用CPU高的功能代码块了! 乂目

 

Tips.

符号路径格式以及地址: srv*C:\SymbolCache*http://msdl.microsoft.com/download/symbols

加载sosex: >.load sosex

Windbg下载方法 sosex下载地址

标签: 软件开发 C# 调试技术 windbg

评论(0) 引用(0) 浏览(4707)

Powered by emlog 去你妹的备案 sitemap