中興AX5400Pro+上手體驗：再升級 雙2.5G網口+USB 3.0這次全都有
2021年11月的時候，中興先后發布了兩款路由器產品，中興AX5400和中興AX5400 Pro，從產品命名上就不難看出這是隸屬于同一系列的，但在外觀設計上這兩款產品可以說是完全沒一點關系
前些天有位朋友找到我，說他的程序每次關閉時就會自動崩潰，一直找不到原因讓我幫忙看一下怎么回事，這位朋友應該是第二次找我了，分析了下 dump 還是挺經典的，拿出來給大家分享一下吧。
找崩潰原因比較簡單，用 !analyze -v 命令觀察一下便知。
0:040> !analyze -vCONTEXT: (.ecxr)eax=0afdf5dc ebx=0698ade8 ecx=00000001 edx=00000000 esi=0698ade8 edi=7eec0000eip=7753c5af esp=0afdf5dc ebp=0afdf62c iopl=0 nv up ei pl nz na po nccs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202KERNELBASE!RaiseException+0x58:7753c5af c9 leaveResetting default scopeEXCEPTION_RECORD: (.exr -1)ExceptionAddress: 7753c5af (KERNELBASE!RaiseException+0x00000058) ExceptionCode: c0020001 ExceptionFlags: 00000001NumberParameters: 1 Parameter[0]: 8007042bPROCESS_NAME: xxx.exe從卦中數據看當前崩潰碼是 c0020001，查了下碼表說是 string綁定無效 ，截圖如下：
圖片
這看起來有點無語呀，接下來觀察下線程棧。
0:040> .ecxreax=0afdf5dc ebx=0698ade8 ecx=00000001 edx=00000000 esi=0698ade8 edi=7eec0000eip=7753c5af esp=0afdf5dc ebp=0afdf62c iopl=0 nv up ei pl nz na po nccs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202KERNELBASE!RaiseException+0x58:7753c5af c9 leave0:040> k *** Stack trace for last set context - .thread/.cxr resets it # ChildEBP RetAddr 00 0afdf62c 70e75e0b KERNELBASE!RaiseException+0x5801 0afdf648 70f63bf5 clr!COMPlusThrowBoot+0x1a02 0afdf654 70b6f1da clr!UMThunkStubRareDisableWorker+0x2503 0afdf67c 77a9571e clr!UMThunkStubRareDisable+0x904 0afdf6bc 77a80f0b ntdll!RtlpTpTimerCallback+0x7a05 0afdf6e0 77a809b1 ntdll!TppTimerpExecuteCallback+0x10f06 0afdf830 75c4344d ntdll!TppWorkerThread+0x56207 0afdf83c 77a69802 kernel32!BaseThreadInitThunk+0xe08 0afdf87c 77a697d5 ntdll!__RtlUserThreadStart+0x7009 0afdf894 00000000 ntdll!_RtlUserThreadStart+0x1b從卦中的線程棧來看，這里利用了 Windows線程池 的timer回調，回到 clr 之后主動拋了一個異常。
要想知道這個答案需要分析下clr 的源碼，簡化后如下：
// Disable from a place that is calling into managed code via a UMEntryThunk.extern "C" VOID __stdcall UMThunkStubRareDisableWorker(Thread * pThread, UMEntryThunk * pUMEntryThunk, Frame * pFrame){ // Check for ShutDown scenario. This happens only when we have initiated shutdown // and someone is trying to call in after the CLR is suspended. In that case, we // must either raise an unmanaged exception or return an HRESULT, depending on the // expectations of our caller. if (!CanRunManagedCode()) { pThread->m_fPreemptiveGCDisabled = 0; COMPlusThrowBoot(E_PROCESS_SHUTDOWN_REENTRY); }}BOOL CanRunManagedCode(BOOL fCannotRunIsUserError, HINSTANCE hInst){ // If we are shutting down the runtime, then we cannot run code. if (g_fForbidEnterEE == TRUE) return FALSE; // If we are finaling live objects or processing ExitProcess event, // we can not allow managed method to run unless the current thread // is the finalizer thread if ((g_fEEShutDown & ShutDown_Finalize2) && !GCHeap::GetGCHeap()->IsCurrentThreadFinalizer()) return FALSE; // If pre-loaded objects are not present, then no way. if (g_pPreallocatedOutOfMemoryException == NULL) return FALSE; return TRUE;}根據上面的源碼，應該就是CanRunManagedCode()函數返回false 導致的，那這個函數真的返回 false 嗎？可以用 Windbg 驗證下g_fForbidEnterEE 這個變量。
0:040> dp clr!g_fForbidEnterEE L1712a2684 00000001無語了，這個變量為true表示當前的CLR處于關閉狀態，應該是主線程調用了 Exit 方法，用 windbg 可以簡單驗證下。
0:000> k00 0028d3b0 77549cd4 ntdll!NtQueryAttributesFile+0x1201 0028d3b0 70bf560b KERNELBASE!GetFileAttributesW+0x7102 0028d3c8 710602a5 clr!CheckFileExistence+0x1a...39 0028ebc0 70d2684b clr!WaitForEndOfShutdown_OneIteration+0x813a 0028ebc8 70d300e2 clr!WaitForEndOfShutdown+0x1b3b 0028ec08 70d1329e clr!EEShutDown+0xad3c 0028ec14 70d132fb clr!HandleExitProcessHelper+0x4d3d 0028ec70 70d2ff99 clr!EEPolicy::HandleExitProcess+0x503e 0028ec70 7115af3b clr!ForceEEShutdown+0x313f 0028ec70 702a9faf clr!SystemNative::Exit+0x4f接下來研究下它要進入到什么托管方法中，這個答案就在 UMEntryThunk.m_pManagedTarget 字段里，參考源碼如下：
class UMEntryThunk{private: // The start of the managed code const BYTE* m_pManagedTarget; // This is used for profiling. PTR_MethodDesc m_pMD;}有了這些前置知識就可以用 windbg 輕松挖掘。
0:040> kb 5 # ChildEBP RetAddr Args to Child 00 0afdf62c 70e75e0b c0020001 00000001 00000001 KERNELBASE!RaiseException+0x5801 0afdf648 70f63bf5 006e0fe0 0afdf67c 70b6f1da clr!COMPlusThrowBoot+0x1a02 0afdf654 70b6f1da 0698ade8 00580a38 0698ade8 clr!UMThunkStubRareDisableWorker+0x2503 0afdf67c 77a9571e 00000000 00000001 7d723ac9 clr!UMThunkStubRareDisable+0x904 0afdf6bc 77a80f0b 0afdf71c 006e0fe0 006f6c10 ntdll!RtlpTpTimerCallback+0x7a0:040> dp 00580a38 L200580a38 00386580 008f2eb80:040> !U 00386580Unmanaged code00386580 e9ab390000 jmp 00389f30...0:040> !ip2md 00389f30MethodDesc: 0018af94Method Name: xxx._checkInput1(IntPtr, Boolean)Class: 00435a7cMethodTable: 0018afd8mdToken: 06000034Module: 0018a6a8IsJitted: yesCodeAddr: 00389f30Transparency: Critical通過一頓反解果然是一個托管回調函數，分析到這里ztm的開心哈，感覺馬上就要看到光了，仔細找了下代碼，果然是借助Windows線程池創建了一個定時事件，無語了，截圖如下：
圖片
圖片
到這里就真相大白了，退出進程的時候一定要先調用C#的Dispose()方法把非托管的Timer給關掉，否則就會出現這種偶發的崩潰異常。
這個dump的錯誤碼非常有誤導性，一個是外部的c0020001 ，一個內部的 8007042Bh，尤其是搜內部的 8007042Bh 會把你帶入到誤區里，讓你修復系統文件啥的，其實就是一個固定的死值，沒有意義的，參見匯編代碼。
0:000> ub 70f63bf5clr!UMThunkStubRareDisableWorker+0x7:70f63bd7 c9 leave70f63bd8 e8d47fc3ff call clr!CanRunManagedCode (70b9bbb1)70f63bdd 8b7508 mov esi,dword ptr [ebp+8]70f63be0 85c0 test eax,eax70f63be2 7511 jne clr!UMThunkStubRareDisableWorker+0x25 (70f63bf5)70f63be4 b92b040780 mov ecx,8007042Bh70f63be9 c7460800000000 mov dword ptr [esi+8],070f63bf0 e8f721f1ff call clr!COMPlusThrowBoot (70e75dec)所以還是多以代碼說話，少道聽途說陷入迷途不知返。
說實話這個dump分析起來還是挺有難度的，需要你對Windows線程池，clr源碼實現有一個基礎了解，否則很難構造出完整證據鏈。
本文鏈接：http://m.www897cc.com/showinfo-26-99886-0.html記一次 .NET某酒業業務系統崩潰分析
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號