记一次 .NET某工业视觉软件 崩溃分析

守听  金牌会员 | 2024-12-27 13:48:08 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题
楼主

主题 871|帖子 871|积分 2613

一：背景

1. 讲故事

前两天给训练营里的一位学员分析了一个dump，学员因为弄了一整天也没找到祸端，被我一下子弄出来了，极度想看看我是怎么分析的？由于在微信上不能一言两语表尽，干脆写一篇文章出来具体的讲讲吧，哈哈，训练营里的学员得有求必应哈。。。话不多说，我们一起探索下这个步调的崩溃之路吧。
二：WinDbg分析

1. 为什么会崩溃

这个比较简单，因为默认会自动定位到崩溃的线程，使用 .ecxr 切到崩溃前的上下文即可，然后使用 k 观察崩溃点，参考如下：
  1. 0:044> .ecxr
  2. rax=0000000000000000 rbx=00000217a6c78f90 rcx=0000000000000000
  3. rdx=0000000000000000 rsi=000000242c46fdd0 rdi=00000217ff1594a0
  4. rip=00007ffdb35eb699 rsp=000000242c46fb40 rbp=000000242c46fc70
  5. r8=00007ffdb35eb699  r9=00000217ea61fc08 r10=00000000e0434352
  6. r11=0000000000000001 r12=00000217a6c78f90 r13=0000000000000000
  7. r14=0000000000000000 r15=0000000000000000
  8. iopl=0         nv up ei pl nz na pe nc
  9. cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
  10. KERNELBASE!RaiseException+0x69:
  11. 00007ffd`b35eb699 0f1f440000      nop     dword ptr [rax+rax]
  12. 0:044> k
  13.   *** Stack trace for last set context - .thread/.cxr resets it
  14. # Child-SP          RetAddr               Call Site
  15. 00 00000024`2c46fb40 00007ffd`51bf8c6f     KERNELBASE!RaiseException+0x69
  16. 01 00000024`2c46fc20 00007ffd`51890108     clr!UMThunkStubRareDisableWorker+0x3f
  17. 02 00000024`2c46fc50 00007ffc`dc826748     clr!UMThunkStub+0x128
  18. 03 00000024`2c46fce0 00007ffc`dc827406     MVCAMSDK_X64+0x6748
  19. 04 00000024`2c46fd80 00007ffc`dc9d21eb     MVCAMSDK_X64!CameraGrabber_GetCameraDevInfo+0xb96
  20. 05 00000024`2c46fe50 00007ffc`dc9d227f     MVCAMSDK_X64!CameraGigeEnumerateDevice+0x167f2b
  21. 06 00000024`2c46fe80 00007ffd`b5a07374     MVCAMSDK_X64!CameraGigeEnumerateDevice+0x167fbf
  22. 07 00000024`2c46feb0 00007ffd`b5ebcc91     kernel32!BaseThreadInitThunk+0x14
  23. 08 00000024`2c46fee0 00000000`00000000     ntdll!RtlUserThreadStart+0x21
复制代码
从卦中可以看到步调是在clr 的 UMThunkStubRareDisableWorker 函数中故意抛出的非常，接下来观察下该函数代码。
  1.     extern "C" VOID __stdcall UMThunkStubRareDisableWorker(Thread* pThread, UMEntryThunk* pUMEntryThunk, Frame* pFrame)
  2.     {
  3.         if (!CanRunManagedCode())
  4.         {
  5.             pThread->m_fPreemptiveGCDisabled = 0;
  6.             COMPlusThrowBoot(E_PROCESS_SHUTDOWN_REENTRY);
  7.         }
  8.     }
  10.     BOOL CanRunManagedCode(BOOL fCannotRunIsUserError, HINSTANCE hInst)
  11.     {
  12.         if (g_fForbidEnterEE == TRUE)
  13.             return FALSE;
  15.         if ((g_fEEShutDown & ShutDown_Finalize2) && !GCHeap::GetGCHeap()->IsCurrentThreadFinalizer())
  16.             return FALSE;
  18.         if (g_pPreallocatedOutOfMemoryException == NULL)
  19.             return FALSE;
  21.         return TRUE;
  22.     }
复制代码
从卦中的代码看是因为 CanRunManagedCode() 返回false导致的，到内存中观察这几个变量即可。
  1. 0:044> dp clr!g_fForbidEnterEE L1
  2. 00007ffd`5201d548  00000000`00000000
  4. 0:044> dp clr!g_fEEShutDown L1
  5. 00007ffd`520140b0  00000000`00000007
  7. 0:044> dp clr!g_pPreallocatedOutOfMemoryException L1
  8. 00007ffd`52013e08  00000217`e4f513d8
复制代码
看到卦中的几个变量大概就知道了，原来当前步调正在等候 闭幕器线程 执行完毕的 EEShutDown 状态。
2. 真的处于关闭状态吗

刚才只是通过变量观察，接下来我们观察线程栈来进一步求证，分别切到主线程和闭幕器线程观察调用栈，参考如下：
  1. 0:000> ~0s;k;~2s;k
  2. win32u!NtUserMsgWaitForMultipleObjectsEx+0x14:
  3. 00007ffd`b3dfa104 c3              ret
  4. # Child-SP          RetAddr               Call Site
  5. 00 00000024`2773f578 00007ffd`b3f40c8e     win32u!NtUserMsgWaitForMultipleObjectsEx+0x14
  6. ...
  7. 08 00000024`2773f9c0 00007ffd`518828ff     clr!CLREventBase::WaitEx+0xab
  8. 09 00000024`2773fa30 00007ffd`51882842     clr!WaitForEndOfShutdown_OneIteration+0xb3
  9. 0a 00000024`2773fac0 00007ffd`5171f703     clr!WaitForEndOfShutdown+0x1a
  10. 0b 00000024`2773faf0 00007ffd`518243f9     clr!EEShutDown+0xd3
  11. 0c 00000024`2773fb40 00007ffd`51823f34     clr!HandleExitProcessHelper+0x29
  12. 0d 00000024`2773fb70 00007ffd`51823e14     clr!_CorExeMainInternal+0xf8
  13. 0e 00000024`2773fc00 00007ffd`96d7d6ea     clr!CorExeMain+0x14
  14. 0f 00000024`2773fc40 00007ffd`96c3ac42     mscoreei!CorExeMain+0xfa
  15. 10 00000024`2773fca0 00007ffd`b5a07374     mscoree!CorExeMain_Exported+0x72
  16. 11 00000024`2773fcd0 00007ffd`b5ebcc91     kernel32!BaseThreadInitThunk+0x14
  17. 12 00000024`2773fd00 00000000`00000000     ntdll!RtlUserThreadStart+0x21
  19. paddle_inference_c!paddle::CreatePaddlePredictor<paddle::AnalysisConfig,3>+0x180be:
  20. 00007ffc`d39a1a9e 488b01          mov     rax,qword ptr [rcx] ds:00000217`89df37b0=00007ffcd7791ff0
  21. # Child-SP          RetAddr               Call Site
  22. 00 00000024`27eff080 00007ffc`d39a1a8f     paddle_inference_c!paddle::CreatePaddlePredictor<paddle::AnalysisConfig,3>+0x180be
  23. 01 00000024`27eff0b0 00007ffc`d39a1a8f     paddle_inference_c!paddle::CreatePaddlePredictor<paddle::AnalysisConfig,3>+0x180af
  24. 02 00000024`27eff0e0 00007ffc`d39a1a8f     paddle_inference_c!paddle::CreatePaddlePredictor<paddle::AnalysisConfig,3>+0x180af
  25. ...
  26. 0e 00000024`27eff3b0 00007ffc`f20cbbde     paddle_inference_c!PD_PredictorDestroy+0x39
  27. 0f 00000024`27eff3e0 00007ffc`f943796a     0x00007ffc`f20cbbde
  28. 10 00000024`27eff4b0 00007ffc`f9437930     Sdcb_PaddleInference!Sdcb.PaddleInference.PaddlePredictor.Dispose+0x1a
  29. 11 00000024`27eff4e0 00007ffd`518915e6     Sdcb_PaddleInference!Sdcb.PaddleInference.PaddlePredictor.Finalize+0x10
  30. 12 00000024`27eff510 00007ffd`5173b6c6     clr!FastCallFinalizeWorker+0x6
  31. 13 00000024`27eff540 00007ffd`5173bd73     clr!FastCallFinalize+0x5a
  32. 14 00000024`27eff580 00007ffd`5173bcae     clr!MethodTable::CallFinalizer+0xb7
  33. 15 00000024`27eff5c0 00007ffd`5173b8e7     clr!CallFinalizer+0x5e
  34. ...
  35. 1e 00000024`27effa50 00000000`00000000     ntdll!RtlUserThreadStart+0x21
复制代码
其实到这里逻辑全部清晰了，用户点击了关闭步调，但此时闭幕器线程正在执行，以是执行引擎需要等候它执行完，在这期间是禁止除闭幕器线程之外的任何线程再对托管方法的调用，一旦有就会抛出非常，画个简图如下：

3. call托管方法在那里

在错误的时间出现了一个对的人，这是一种意难平，接下来把这个对的人给找出来，即 UMThunkStubRareDisableWorker方法的第二个参数pUMEntryThunk，因为这里面的 m_pManagedTarget 即托管方法的入口点，模型如下：
  1. class UMEntryThunk
  2. {
  3.     private:
  4.     // The start of the managed code
  5.     const BYTE* m_pManagedTarget;
  7.     // This is used for profiling.
  8.     PTR_MethodDesc m_pMD;
  9. }
复制代码
那怎样挖呢？观察UMThunkStubRareDisableWorker方法汇编代码即可。
  1. 0:044> k
  2.   *** Stack trace for last set context - .thread/.cxr resets it
  3. # Child-SP          RetAddr               Call Site
  4. 00 00000024`2c46fb40 00007ffd`51bf8c6f     KERNELBASE!RaiseException+0x69
  5. 01 00000024`2c46fc20 00007ffd`51890108     clr!UMThunkStubRareDisableWorker+0x3f
  6. 02 00000024`2c46fc50 00007ffc`dc826748     clr!UMThunkStub+0x128
  7. 03 00000024`2c46fce0 00007ffc`dc827406     MVCAMSDK_X64+0x6748
  8. 04 00000024`2c46fd80 00007ffc`dc9d21eb     MVCAMSDK_X64!CameraGrabber_GetCameraDevInfo+0xb96
  9. 05 00000024`2c46fe50 00007ffc`dc9d227f     MVCAMSDK_X64!CameraGigeEnumerateDevice+0x167f2b
  10. 06 00000024`2c46fe80 00007ffd`b5a07374     MVCAMSDK_X64!CameraGigeEnumerateDevice+0x167fbf
  11. 07 00000024`2c46feb0 00007ffd`b5ebcc91     kernel32!BaseThreadInitThunk+0x14
  12. 08 00000024`2c46fee0 00000000`00000000     ntdll!RtlUserThreadStart+0x21
  14. 0:044> uf 00007ffd`51890108
  15. 00007ffd`5188ffe0 4154            push    r12
  16. 00007ffd`5188ffe2 55              push    rbp
  17. 00007ffd`5188ffe3 4883ec78        sub     rsp,78h
  18. 00007ffd`5188ffe7 488d6c2420      lea     rbp,[rsp+20h]
  19. 00007ffd`5188ffec c6454000        mov     byte ptr [rbp+40h],0
  20. 00007ffd`5188fff0 e8abe0ffff      call    clr!GetThread (00007ffd`5188e0a0)
  21. 00007ffd`5188fff5 4885c0          test    rax,rax
  22. 00007ffd`5188fff8 746f            je      clr!UMThunkStub+0x89 (00007ffd`51890069)  Branch
  23. ...
  24. 00007ffd`518900f9 4c895548        mov     qword ptr [rbp+48h],r10
  25. 00007ffd`518900fd 498bcc          mov     rcx,r12
  26. 00007ffd`51890100 498bd2          mov     rdx,r10
  27. 00007ffd`51890103 e8288b3600      call    clr!UMThunkStubRareDisableWorker (00007ffd`51bf8c30)
复制代码
根据x64调用协定，参数是放在 r10 寄存器中，而r10刚好放在 rbp+48h 中，以是挖出这个栈位置即可，简单计算为。
  1. 0:044> ? 00000024`2c46fce0-0x8-0x8-0x8-0x78+0x20
  2. Evaluate expression: 155361672304 = 00000024`2c46fc70
  4. 0:044> dp 00000024`2c46fc70+0x48 L1
  5. 00000024`2c46fcb8  00000217`ff1594a0
  7. 0:044> dp 00000217`ff1594a0 L1
  8. 00000217`ff1594a0  00007ffc`f2f49380
  10. 0:044> !U 00007ffc`f2f49380
  11. Unmanaged code
  12. 00007ffc`f2f49380 e98bbd0500      jmp     00007ffc`f2fa5110
  13. 00007ffc`f2f49385 5f              pop     rdi
  14. 00007ffc`f2f49386 0f              ???
  15. 00007ffc`f2f49387 25e8e35194      and     eax,9451E3E8h
  16. 00007ffc`f2f4938c 5e              pop     rsi
  17. 00007ffc`f2f4938d 5e              pop     rsi
  18. 00007ffc`f2f4938e 1124e8          adc     dword ptr [rax+rbp*8],esp
  19. 00007ffc`f2f49391 db5194          fist    dword ptr [rcx-6Ch]
  20. 00007ffc`f2f49394 5e              pop     rsi
  21. 00007ffc`f2f49395 5e              pop     rsi
  23. 0:044> !ip2md 00007ffc`f2fa5110
  24. MethodDesc:   00007ffcf33bd9e8
  25. Method Name:  baslerCamera.MVCam.CameraGrabberFrameCallback(IntPtr, IntPtr, baslerCamera.tSdkFrameHead ByRef, IntPtr)
  26. Class:        00007ffcf33c1c98
  27. MethodTable:  00007ffcf33be828
  28. mdToken:      0000000006000067
  29. Module:       00007ffcf2352f60
  30. IsJitted:     yes
  31. CodeAddr:     00007ffcf2fa5110
  32. Transparency: Critical
复制代码
从 baslerCamera 来看是一个工业相机，接下来赶紧寻找源代码，截图如下：

图中的 m_FrameCallback 是一个delegate函数，并通过 CameraGrabber_SetRGBCallback 方法传给了C++，以是在关闭步调的时候肯定要先释放掉这个 calllback 来和C++撇清关系，否则就会有劫难的降临。
三：总结

在我的dump分析之旅中曾遇到过一次相似的生产故障，本篇文章主要照旧对训练营里这位朋友的有求必应吧，不外说实话，多分析几个像这样的dump，会极大的提拔你的高级调试能力。


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看，没有账号？立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览
返回列表

快速回复

高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

守听

金牌会员
这个人很懒什么都没写!

楼主热帖

标签云

挺好的 服务器
微信订阅号
微信服务号
微信客服
小程序
H5
关于我们 商务合作 网站地图
©Copyright 2022-2024 杭州祥升科技有限公司 版权所有 浙ICP备20004199号
快速回复 返回顶部 返回列表