记一次 .NET某质量检测中心系统崩溃分析

net · 浏览次数 : 0

小编点评

背景：近日来，讲述故事的路上遇到了一些有趣的程序故障。这些故障都与Windows操作系统或第三方组件有关。今天，我将为大家介绍一个与IIS相关的案例，这是一起国企开发的.NET程序崩溃事件，需要进行紧急分析。 WinDbg分析：首先，我们可以通过分析dump文件来确定崩溃原因。在这个案例中，错误信息为Stack overflow - code c00000fd（第一次/第二次机会不可用）。通过运行！analyze -veax=72ae2290 ebx=00000000 ecx=72afa1c0 edx=00000000 esi=72afa1c0 edi=01cb1d7ceip=72afa1e6 esp=3e673000 ebp=3e673010 iopl=0 nv up ei pl zr na pe nccs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246iiscore+0x1a1e6:72afa1e6 ff15a064b172 call dword ptr [iiscore!GetProtocolManager+0x9370 (72b164a0)]。根据这个错误信息，我们可以看到这是一个典型的栈溢出崩溃。为了找出导致崩溃的代码，我们需要查看顶层代码。这里我们使用了k 0xffff，最终发现iiscore模块中的某个函数导致了崩溃。从进程上下文来看，问题可能出现在托管层。通过查看！clrstack，我们发现在托管层中存在一个死循环。这意味着问题的根源可能在于托管层。尽管无法直接查看iiscore的源代码，但我们可以观察到在托管层有一个死循环。因此，我们可以得出结论：问题很可能来自底层承载的bug。为了修复这个问题，建议进行以下操作： 1. 使用SFC /SCANNOW命令检修系统文件。 2. 如果条件允许，可以考虑升级操作系统和IIS的版本。总结：程序崩溃并不总是由于编写不当的代码所导致，底层承载的bug或环境中的辐射可能是更常见的原因。因此，在分析崩溃类dump时，我们需要保持一定的玄学心态。当程序出现问题时，应迅速定位问题所在，而不是将责任推卸在自己身上。

正文

一：背景

1. 讲故事

这些天有点意思，遇到的几个程序故障都是和Windows操作系统或者第三方组件有关系，真的有点无语，今天就带给大家一例 IIS 相关的与大家分享，这是一家国企的.NET程序，出现了崩溃急需分析。

二：WinDbg 分析

1. 为什么会崩溃

崩溃原因相对还是好找的，双击dump文件之后错误信息马上就列出来了，参考如下：


This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(3950.1890): Stack overflow - code c00000fd (first/second chance not available)
For analysis of this file, run !analyze -v
eax=72ae2290 ebx=00000000 ecx=72afa1c0 edx=00000000 esi=72afa1c0 edi=01cb1d7c
eip=72afa1e6 esp=3e673000 ebp=3e673010 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
iiscore+0x1a1e6:
72afa1e6 ff15a064b172    call    dword ptr [iiscore!GetProtocolManager+0x9370 (72b164a0)] ds:002b:72b164a0=72af5ab0

从卦中的 Stack overflow - code c00000fd 来看，这又是一个经典的栈溢出导致的崩溃，这里栈溢出崩溃的原理就不说了，接下来观察下是什么代码导致的，难道又是一个死循环吗？

2. 到底是谁诱导的

要想找到是谁诱导的，肯定要看下顶层代码是什么，使用 k 0xffff 即可。


2732 3e6adcc0 72afa1f0     iiscore+0x1a1f0
2733 3e6adcd8 72afa1f0     iiscore+0x1a1f0
2734 3e6adcf0 72afa1f0     iiscore+0x1a1f0
2735 3e6add08 72afa1f0     iiscore+0x1a1f0
2736 3e6add20 72afa1f0     iiscore+0x1a1f0
2737 3e6add38 72afa1f0     iiscore+0x1a1f0
...
273e 3e6ade8c 734e8a9b     webengine4!W3_MGD_HANDLER::ReadEntityBody+0x134
273f 3e6adeac 60251594     webengine4!MgdReadEntityBody+0x5b
...
2762 3e6aed0c 601fecc3     System_Web_ni+0x231941
2763 3e6aee00 601fe80f     System_Web_ni+0x1decc3
2764 3e6aee28 028fe29a     System_Web_ni+0x1de80f
2765 3e6aee48 72cbfa41     0x28fe29a
2766 3e6aeea8 72cbf972     clr!UM2MThunk_Wrapper+0x76
...
276a 3e6af024 7348ab83     webengine4!W3_MGD_HANDLER::ProcessNotification+0x62
276b 3e6af038 72b3bc52     webengine4!ProcessNotificationCallback+0x33

从卦象看，它的走势大概是 托管 -> webengine4 -> iiscore ，然后就死掉了，很显然 iiscore 是 iis 的核心组件，可以用 lmvm 观察下。


0:087> lmvm iiscore
Browse full module list
start    end        module name
72ae0000 72b1f000   iiscore    (export symbols)       iiscore.dll
    Loaded symbol image file: iiscore.dll
    Image path: C:\Windows\System32\inetsrv\iiscore.dll
    Image name: iiscore.dll
    Browse all global symbols  functions  data
    Timestamp:        Fri Sep  8 11:04:45 2023 (64FA8F4D)
    CheckSum:         00042ABA
    ImageSize:        0003F000
    File version:     8.5.9600.21613
    Product version:  8.5.9600.21613
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0000.04b0
    Information from resource tables:
        CompanyName:      Microsoft Corporation
        ProductName:      Internet Information Services
        InternalName:     iiscore.dll
        OriginalFilename: iiscore.dll
        ProductVersion:   8.5.9600.21613
        FileVersion:      8.5.9600.21613 (winblue_ltsb.230907-1700)
        FileDescription:  IIS Web Server Core
        LegalCopyright:   © Microsoft Corporation. All rights reserved.

其实到这里就有很大的好奇心，到底是什么代码这么厉害，能导致底层的 iiscore 死循环，可以使用 !clrstack 观察下托管栈。


0:087> !clrstack
OS Thread Id: 0x1890 (87)
Child SP       IP Call Site
3e6aded4 72afa1e6 [InlinedCallFrame: 3e6aded4] 
3e6aded0 60251594 DomainNeutralILStubClass.IL_STUB_PInvoke(IntPtr, Byte[], Int32, Int32, Boolean, Int32 ByRef, IntPtr ByRef)
3e6aded4 60250906 [InlinedCallFrame: 3e6aded4] System.Web.Hosting.UnsafeIISMethods.MgdReadEntityBody(IntPtr, Byte[], Int32, Int32, Boolean, Int32 ByRef, IntPtr ByRef)
3e6adf28 60250906 System.Web.Hosting.IIS7WorkerRequest.ReadEntityCoreSync(Byte[], Int32, Int32)
3e6adf64 602508b9 System.Web.Hosting.IIS7WorkerRequest.ReadEntityBody(Byte[], Int32)
3e6adf74 6020dcfc System.Web.HttpRequest.GetEntireRawContent()
3e6adfa0 6020cc50 System.Web.HttpRequest.FillInFormCollection()
3e6adfdc 6020ebb6 System.Web.HttpRequest.EnsureForm()
3e6adfec 6020eb3e System.Web.HttpRequest.get_Form()
3e6adff8 2e17391e xxx.RequestFilterModule.CheckRequest()

接下来观察托管层的 CheckRequest() 的链路，截图如下：

这简直太不可思议了，一句平常无奇的 base.Request.Form != null 代码，居然把IIS给弄崩掉了，很显然问题大概率不在托管层。

3. iiscore 在执行什么死循环

托管层这条路断了之后，接下来在回头观察 iiscore 处的汇编代码，截图如下：

由于没有 iiscore 的源代码，也没有做复原的必要，但不管怎么样，可以看到这地方确实存在着死循环，我们在用户态没法去做修补，最后看下当前系统情况。


0:087> vertarget
Windows 8.1 Version 9600 MP (8 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
Edition build lab: 6.3.9600.18217 (winblue_ltsb.160124-0053)
Debug session time: Tue Mar 19 10:00:33.000 2024 (UTC + 8:00)
System Uptime: 46 days 1:32:14.541
Process Uptime: 0 days 19:11:55.000
  Kernel time: 0 days 0:06:09.000
  User time: 0 days 0:14:38.000

可以看到当前是 Windows Server 2012 R2，跑的是 IIS 8.5 ，由于 IIS 是强绑到 Windows的，所以能给到的建议就是：

使用 SFC /SCANNOW 检修下系统文件，这是某软 CSS 的那帮人最喜欢用的命令 O(∩_∩)O
升级操作系统，提升 IIS 的版本。

三：总结

有时候程序崩溃往往不是你代码写的烂，极有可能是底层承载的bug导致的，甚至罪魁祸首是环境中的辐射，所以分析崩溃类的dump也挺玄学的，以后程序出问题第一时间不要大包大揽的往自己身上背，找出问题才是关键。
图片名称