记一次 .NET 某企业内部系统 崩溃分析

这篇具有很好参考价值的文章主要介绍了记一次 .NET 某企业内部系统 崩溃分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一:背景

1. 讲故事

前些天有位朋友找到我,说他的程序跑着跑着就崩溃了,让我看下怎么回事,其实没怎么回事,抓它的 crash dump 就好,具体怎么抓也是被问到的一个高频问题,这里再补一下链接: [.NET程序崩溃了怎么抓 Dump ? 我总结了三种方案] https://www.cnblogs.com/huangxincheng/p/14811953.html ,采用第二种 AEDebug 的形式抓取即可。

二:Windbg 分析

1. 崩溃原因是什么

如果dump中塞了异常,用 windbg 打开的时候会有一个提示 This dump file has an exception of interest stored in it,输出如下:


************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*C:\mysymbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*C:\mysymbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Debug session time: Wed Jun 14 13:34:49.000 2023 (UTC + 8:00)
System Uptime: 0 days 3:28:04.223
Process Uptime: 0 days 0:00:14.000
................................................................
................................................................
......................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(9e4.bc4): Stack overflow - code c00000fd (first/second chance not available)
For analysis of this file, run !analyze -v
clr!SlowAllocateString+0x11:
000007fe`f9236451 48c785b0fffffffeffffff mov qword ptr [rbp-50h],0FFFFFFFFFFFFFFFEh ss:00000000`123d5fd0=0000000000000000

从卦中看当前有一个 Stack overflow - code c00000fd 异常,说实话好久都没看到 栈溢出 了,甚是想念,既然说栈溢出了,那就看下异常前是个啥情况,使用 .excr 即可。


0:028> .excr;k
rax=00000000123d6048 rbx=00000000123d5d70 rcx=0000000000000001
rdx=0000000000000001 rsi=0000000000000000 rdi=00000000123d5880
rip=000007fef9236451 rsp=00000000123d5fb0 rbp=00000000123d6020
 r8=00000000ffffffff  r9=0000000000000000 r10=00000000123d618e
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000001
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010200
clr!SlowAllocateString+0x11:
000007fe`f9236451 48c785b0fffffffeffffff mov qword ptr [rbp-50h],0FFFFFFFFFFFFFFFEh ss:00000000`123d5fd0=0000000000000000
  *** Stack trace for last set context - .thread/.cxr resets it
 # Child-SP          RetAddr               Call Site
00 00000000`123d5fb0 000007fe`f920a5bd     clr!SlowAllocateString+0x11
01 00000000`123d6050 000007fe`f920a9c7     clr!StringObject::NewString+0x25
02 00000000`123d6080 000007fe`f920a80d     clr!Int32ToDecStr+0xdf
03 00000000`123d6320 000007fe`9ab3bb72     clr!COMNumber::FormatInt32+0x10d
04 00000000`123d65f0 000007fe`9ab33e04     0x000007fe`9ab3bb72
05 00000000`123d6630 000007fe`9ab3be52     0x000007fe`9ab33e04
06 00000000`123d6720 000007fe`9ab3bd2a     0x000007fe`9ab3be52
07 00000000`123d6790 000007fe`9ab33e35     0x000007fe`9ab3bd2a
08 00000000`123d67f0 000007fe`9ab3be52     0x000007fe`9ab33e35
09 00000000`123d68e0 000007fe`9ab3bd2a     0x000007fe`9ab3be52
...
ff 00000000`123df860 000007fe`9ab3bd2a     0x000007fe`9ab3be52

从卦中看,当前默认的 255 个栈帧全部被打满,看样子是无限死循环了,为了能看到托管部分我们改用 !clrstack 命令。


0:028> !clrstack
OS Thread Id: 0xbc4 (28)
        Child SP               IP Call Site
00000000123d63b8 000007fef9236451 [HelperMethodFrame_PROTECTOBJ: 00000000123d63b8] System.Number.FormatInt32(Int32, System.String, System.Globalization.NumberFormatInfo)
00000000123d65f0 000007fe9ab3bb72 xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[])
00000000123d6630 000007fe9ab33e04 xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Int64, Int64, Boolean)
00000000123d6720 000007fe9ab3be52 xxx_symbol01.xxx_symbol09.xxx_symbol00(Int32, Int32)
00000000123d6790 000007fe9ab3bd2a xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Boolean)
00000000123d67f0 000007fe9ab33e35 xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Int64, Int64, Boolean)
00000000123d68e0 000007fe9ab3be52 xxx_symbol01.xxx_symbol09.xxx_symbol00(Int32, Int32)
00000000123d6950 000007fe9ab3bd2a xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Boolean)
00000000123d69b0 000007fe9ab33e35 xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Int64, Int64, Boolean)
00000000123d6aa0 000007fe9ab3be52 xxx_symbol01.xxx_symbol09.xxx_symbol00(Int32, Int32)
00000000123d6b10 000007fe9ab3bd2a xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Boolean)
00000000123d6b70 000007fe9ab33e35 xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Int64, Int64, Boolean)
00000000123d6c60 000007fe9ab3be52 xxx_symbol01.xxx_symbol09.xxx_symbol00(Int32, Int32)
00000000123d6cd0 000007fe9ab3bd2a xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Boolean)
00000000123d6d30 000007fe9ab33e35 xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Int64, Int64, Boolean)
00000000123d6e20 000007fe9ab3be52 xxx_symbol01.xxx_symbol09.xxx_symbol00(Int32, Int32)
00000000123d6e90 000007fe9ab3bd2a xxx_symbol01.xxx_symbol09.xxx_symbol00(Byte[], Boolean)
....
000000001244db60 000007fe9ab31f0e xxx.PDFFile.xxx_symbol00(System.String, System.IO.Stream, Byte[])
000000001244dbc0 000007fe9ab318e5 xxx.xxx.Convertxxxx(System.IO.Stream, Int32, Int32, System.Drawing.Imaging.ImageFormat, Int32)

从卦中信息看,是代码用 Convertxxxx 调用了一个第三方库,在这个库中出现了死递归。

按理说不管外界给了什么参数下去,都不应该用死递归的方式来呈现,所以这类问题可以归于 SDK 的bug,接下来我们的研究方向就是看下这个 SDK 是何方神圣?


[assembly: AssemblyCopyright("© 2008 O2 Solutions")]
[assembly: AssemblyProduct("PDFxxx4NET")]
[assembly: AssemblyCompany("O2 Solutions (http://www.xxx.com/)")]
[assembly: AssemblyTrademark("PDFxxx4NET is a trademark of O2 Solutions")]
[assembly: AllowPartiallyTrustedCallers]
[assembly: AssemblyTitle("Print and convert PDF files to images.")]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)]
[assembly: AssemblyDescription("Component for rendering pdf files on .NET platform")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyInformationalVersion("2.0.1")]
[assembly: AssemblyKeyName("")]
[assembly: AssemblyDelaySign(false)]
[assembly: CompilationRelaxations(8)]
[assembly: AssemblyVersion("2.0.1.0")]

从卦中看还是 2008 年写的 2.0.1 版本,而官网早已出了 2023 年版本,也就是说 15年都没有更新,也是厉害,截图如下:

记一次 .NET 某企业内部系统 崩溃分析

到这里就可以给到朋友答案了,让他看下能否把 PDFRender4NET 升级到最新版本,按理说应该就没有问题了。

2. 为什么会栈溢出

心细的朋友可能会有一个疑问,既然都栈溢出了,按理说异常码应该是 c0000005 (访问违例),怎么会是 c00000fd 呢?

这是一个非常好的问题,要理解为什么是 c00000fd 而不是 c0000005,需要你对栈的布局有一个比较清晰的理解,为了方便讲述,以当前的 w3wp 来绘制一张图。

记一次 .NET 某企业内部系统 崩溃分析

画完这张图肯定有朋友会提几个反对意见:

1) 线程栈不是 1M 吗? 怎么会是 512k 呢?

这里要说的是 1M 并不是什么公理,可以在 PE 头上随便设定的,截图如下:

记一次 .NET 某企业内部系统 崩溃分析

2)PAGE_GUARD 不是 1个内存页吗?

很多教科书都是按 1个内存页 讲述的,但这也不是定死的,也可能是多个内存页,比如 2个,5个,要想验证很简单,用 !address -f:Stack 观察下便知。


0:121> !address -f:Stack

        BaseAddress      EndAddress+1        RegionSize     Type       State                 Protect             Usage
--------------------------------------------------------------------------------------------------------------------------
       0`001f0000        0`00266000        0`00076000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~0; 9e4.e30]
       0`00266000        0`00268000        0`00002000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~0; 9e4.e30]
       0`00268000        0`00270000        0`00008000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~0; 9e4.e30]
       ...
       0`15710000        0`15788000        0`00078000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~139; 9e4.14ac]
       0`15788000        0`1578d000        0`00005000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~139; 9e4.14ac]
       0`1578d000        0`15790000        0`00003000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~139; 9e4.14ac]

接下来我们聊一下什么是 PAGE_GUARD,从名字上看就是 哨兵页,说白一点就是 Windows 做 栈伸展 的一种系统机制,当 rsp 访问到这个区域时会引发系统的 页中断 进而 COMMIT 更多内存页,新的 Commit 页会被 哨兵 侵占,同时也会让渡 RSP 所占的内存页给程序使用,这是一种良性机制,一旦 哨兵 无法侵占更多新的 COMMIT 页时,也就表示栈空间已经到位了,这时候会将自身的 PAGE_GUARD 标签去掉,表示它的使命已完成,如果此时 RSP 访问到了这个弥留的 哨兵区 ,就会抛出 c00000fd 异常,这种异常只是表示 RSP 进入了 哨兵区,不代表栈空间 真的用完了,所以这就是不抛 c0000005 的真正原因,画个简图如下:

记一次 .NET 某企业内部系统 崩溃分析

说了这么说,如何去验证呢?非常简单,我们提取出 StackLimit, StackBase, RSP 即可。


0:028> r rsp
rsp=00000000123d5fb0

0:028> !teb
TEB at 000007fffff70000
    ExceptionList:        0000000000000000
    StackBase:            0000000012450000
    StackLimit:           00000000123d1000

0:028> !address -f:Stack

        BaseAddress      EndAddress+1        RegionSize     Type       State                 Protect             Usage
--------------------------------------------------------------------------------------------------------------------------
       0`123d0000        0`123d1000        0`00001000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~28; 9e4.bc4]
       0`123d1000        0`12450000        0`0007f000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~28; 9e4.bc4]

从卦中看,当前 哨兵区 = StackLimit ~ StackLimit+0x5000 = 00000000123d1000 ~ 00000000123d6000,然后看下 rsp=00000000123d5fb0 果然是在这个范围内,在一些低级语言中还可以继续放任 栈溢出 异常,继续让程序跑,当代码跑到图中的 MEM_RESERVE 区时这就是货真价实的 c0000005 访问违例。

三:总结

这次崩溃事故主要还是第三方的SDK代码不健壮导致的 死递归 拖累程序崩溃,解决办法很简单,升级升级再升级,如果还有问题建议提交官方或者使用其他替代品,如果官方解决问题不活跃,你还敢用吗?文章来源地址https://www.toymoban.com/news/detail-499333.html

记一次 .NET 某企业内部系统 崩溃分析

到了这里,关于记一次 .NET 某企业内部系统 崩溃分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 记一次 .NET某炉膛锅炉检测系统 崩溃分析

    上个月有个朋友在微信上找到我,说他们的软件在客户那边隔几天就要崩溃一次,一直都没有找到原因,让我帮忙看下怎么回事,确实工控类的软件环境复杂难搞,朋友手上有一个崩溃的dump,刚好丢给我来分析一下。 windbg 有一个厉害之处在于双击之后可以帮你自动定位到崩

    2024年04月17日
    浏览(31)
  • 记一次 .NET 某旅行社审批系统 崩溃分析

    前些天有位朋友找到我,说他的程序跑着跑着就崩溃了,让我看下怎么回事,其实没怎么回事,抓它的 crash dump 就好,具体怎么抓也是被问到的一个高频问题,这里再补一下链接: [.NET程序崩溃了怎么抓 Dump ? 我总结了三种方案] https://www.cnblogs.com/huangxincheng/p/14811953.html ,采用

    2024年02月09日
    浏览(34)
  • 记一次 .NET某新能源检测系统 崩溃分析

    前几天有位朋友微信上找到我,说他的程序会偶发性崩溃,一直找不到原因,让我帮忙看一下怎么回事,对于这种崩溃类的程序,最好的办法就是丢dump过来看一下便知,话不多说,上windbg说话。 对于一个崩溃类的dump,寻找崩溃点非常重要,常用的命令就是 !analyze -v ,输出如

    2024年02月08日
    浏览(30)
  • 记一次 .NET 某新能源材料检测系统 崩溃分析

    上周有位朋友找到我,说他的程序经常会偶发性崩溃,一直没找到原因,自己也抓了dump 也没分析出个所以然,让我帮忙看下怎么回事,那既然有 dump,那就开始分析呗。 一直跟踪我这个系列的朋友应该知道分析崩溃第一个命令就是 !analyze -v ,让windbg帮我们自动化异常分析。

    2024年02月05日
    浏览(41)
  • 记一次 .NET某股票交易软件 灵异崩溃分析

    在dump分析的旅程中也会碰到一些让我无法解释的灵异现象,追过这个系列的朋友应该知道,上一篇我聊过 宇宙射线 导致的程序崩溃,后来我又发现了一例,而这一例恰恰是高铁的 列控连锁一体化 程序,所以更加让我确定这是由于 电离辐射 干扰了计算机的 数字信号 导致程

    2024年02月04日
    浏览(30)
  • 记一次 .NET某工控 宇宙射线 导致程序崩溃分析

    为什么要提 宇宙射线 , 太阳耀斑 导致的程序崩溃呢?主要是昨天在知乎上看了这篇文章:莫非我遇到了传说中的bug? ,由于 rip 中的0x41变成了0x61出现了bit位翻转导致程序崩溃,截图如下: 下面的评论大多是说由于 宇宙射线 ,这个太玄乎了,说实话看到这个 传说bug 的提法

    2024年02月04日
    浏览(29)
  • 记一次 腾讯会议 的意外崩溃分析

    前段时间在用 腾讯会议 直播的时候,居然意外崩溃了,还好不是在训练营上课,不然又得重录了,崩完之后发现 腾讯会议 的 bugreport 组件会自动生成一个 minidump,截图如下: 作为一个.NET高级调试的技术博主,非 .NET 的程序也得要研究研究哈😄😄😄,有了这个好奇心,也

    2023年04月20日
    浏览(65)
  • 记一次 .NET 某工控视觉系统 卡死分析

    前段时间有位朋友找到我,说他们的工业视觉软件僵死了,让我帮忙看下到底是什么情况,哈哈,其实卡死的问题相对好定位,无非就是看主线程栈嘛,然后就是具体问题具体分析,当然难度大小就看运气了。 前几天看一篇文章说现在的 .NET程序员 不需要学习 WinDbg ,理由就

    2024年02月12日
    浏览(34)
  • 记一次 .NET某报关系统 非托管泄露分析

    前段时间有位朋友找到我,说他的程序内存会出现暴涨,让我看下是怎么事情?而且还告诉我是在 Linux 环境下,说实话在Linux上分析.NET程序难度会很大,难度大的原因在于Linux上的各种开源工具主要是针对 C/C++, 和 .NET 一毛钱关系都没有,说到底微软在 Linux 上的调试领域支持

    2024年02月14日
    浏览(36)
  • 记一次 .NET 某电力系统 内存暴涨分析

    前些天有位朋友找到我,说他生产上的程序有内存暴涨情况,让我帮忙看下怎么回事,最简单粗暴的方法就是让朋友在内存暴涨的时候抓一个dump下来,看一看大概就知道咋回事了。 这个问题说的再多也不为过,一定要看清楚这个程序是如何个性化发展的,可以使用 !address

    2024年02月08日
    浏览(33)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包