自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

記一次 .NET某工廠報(bào)警監(jiān)控設(shè)置崩潰分析

作者：一線碼農(nóng)聊技術(shù)
開發(fā) 前端
前些天有位朋友在微信上丟了一個(gè)崩潰的dump給我，讓我?guī)兔聪聻槭裁闯霈F(xiàn)了崩潰，在 Windows 的事件查看器上顯示的是經(jīng)典的 訪問違例 ，即 c0000005 錯(cuò)誤碼，不管怎么說有dump就可以上windbg開干了。

一、背景

1. 講故事

前些天有位朋友在微信上丟了一個(gè)崩潰的dump給我，讓我?guī)兔聪聻槭裁闯霈F(xiàn)了崩潰，在 Windows 的事件查看器上顯示的是經(jīng)典的 訪問違例 ，即 c0000005 錯(cuò)誤碼，不管怎么說有dump就可以上windbg開干了。

二、WinDbg 分析

1. 程序?yàn)檎l崩潰了

在 Windows 平臺上比較簡單，可以用 !analyze -v 命令查看，輸出結(jié)果如下：

0:120> !analyze -v
...
CONTEXT:  (.ecxr)
rax=0000000000000000 rbx=000000d5140fcf00 rcx=0000000000000000
rdx=000001d7f61cf1d8 rsi=000001d7d3635a10 rdi=000000d5140fc890
rip=00007ff80e17d233 rsp=000000d5140fc760 rbp=000000d5140fc8a0
 r8=000001d7d3308144  r9=0000000000000000 r10=0000000000000000
r11=000001d96736b620 r12=000000d5140fca08 r13=00007ff80d326528
r14=000000d5140fcf00 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
00007ff8`0e17d233 3909            cmp     dword ptr [rcx],ecx ds:00000000`00000000=????????
Resetting default scope

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ff80e17d233
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000000
Attempt to read from address 0000000000000000

ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%p            0x%p                    %s

EXCEPTION_CODE_STR:  c0000005

STACK_TEXT:  
000000d5`140fc760 00007ff8`6bcc6d93     : 000001d7`d3635a10 000000d5`140fcb80 00007ff8`6bcfda57 00007ff8`695acc92 : 0x00007ff8`0e17d233
000000d5`140fc8b0 00007ff8`6bcc6c48     : 00000000`00000004 00007ff8`6be5ba73 00000000`00000000 00000000`00000000 : clr!CallDescrWorkerInternal+0x83
000000d5`140fc8f0 00007ff8`6be5bf66     : 000001d7`d3635a10 00000000`00000000 000000d5`140fcad8 00000000`00000000 : clr!CallDescrWorkerWithHandler+0x4e
000000d5`140fc930 00007ff8`6be5c41f     : 00000000`00000000 000000d5`140fca30 00000000`00000000 000000d5`140fcb60 : clr!CallDescrWorkerReflectionWrapper+0x1a
000000d5`140fc980 00007ff8`69993ee4     : 00000000`00000000 00000000`00000000 000001d7`d3635a10 00007ff8`699f9700 : clr!RuntimeMethodHandle::InvokeMethod+0x45f
000000d5`140fcf90 00007ff8`6997eeae     : 000001d7`d3376af0 00000000`00000000 00000000`0000011e 00007ff8`699f82f3 : mscorlib_ni!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal+0x104
000000d5`140fd000 00007ff8`699c3a06     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : mscorlib_ni!System.Reflection.RuntimeMethodInfo.Invoke+0x8e
000000d5`140fd080 00007ff8`0dfb7bb3     : 000001d7`d3635998 000001d7`d45e28e0 00000000`0000011c 000001d7`d3376af0 : mscorlib_ni!System.RuntimeType.InvokeMember+0x306
...
STACK_COMMAND:  ~120s; .ecxr ; kb
...

從卦中信息看崩潰的匯編語句是 dword ptr [rcx],ecx ，經(jīng)常看C#匯編代碼的朋友我相信對這條語句非常敏感，對，它就是JIT自動插入的一條 this!=null 的防御性判斷，看樣子程序有 this=null 的情況，接下來入手點(diǎn)就是RIP處 ExceptionAddress: 00007ff80e17d233，用 !U 觀察下上下文。

0:120> !U 00007ff80e17d233
Normal JIT generated code
MyScript.Process()
Begin 00007ff80e17d1c0, size 3d5
00007ff8`0e17d1c0 55              push    rbp
00007ff8`0e17d1c1 57              push    rdi
00007ff8`0e17d1c2 56              push    rsi
00007ff8`0e17d1c3 4881ec30010000  sub     rsp,130h
00007ff8`0e17d1ca c5f877          vzeroupper
...
00007ff8`0e17d220 e813c1edfe      call    00007ff8`0d059338 (xxx.GetRegion(System.String, Boolean), mdToken: 000000000600034f)
00007ff8`0e17d225 48898570ffffff  mov     qword ptr [rbp-90h],rax
00007ff8`0e17d22c 488b8d70ffffff  mov     rcx,qword ptr [rbp-90h]
>>> 00007ff8`0e17d233 3909            cmp     dword ptr [rcx],ecx
00007ff8`0e17d235 e8de87edfe      call    00007ff8`0d055a18 (xxx.get_Region(), mdToken: 0000000006000073)

從卦中的匯編代碼看邏輯非常清晰，即 xxx.GetRegion() 方法返回為null，然后在取其中的 Region 屬性時(shí)直接崩掉，說白了這是一個(gè)簡單的 空引用異常，完整的代碼截圖如下：

圖片圖片

奇怪就奇怪在這里，代碼中明明用 try catch 給包起來了，為什么程序直接崩掉了。

2. 為什么try catch 無效

尼瑪，這是我這幾年做dump分析第一次遇到這種情況，真的是無語了，接下來我們驗(yàn)證下這個(gè)異常是否到了托管層？

  • 是否有 NullReferenceException

熟悉dump分析的朋友應(yīng)該知道，如果線程拋了異常在回溯的過程中會記錄到 Thread.m_LastThrownObjectHandle 字段中，同時(shí) !t 命令可以在 Exception 列中看到此信息。

0:120> !t
ThreadCount:      48
UnstartedThread:  0
BackgroundThread: 47
PendingThread:    0
DeadThread:       0
Hosted Runtime:   no
                                                                                                        Lock  
       ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception
   0    1 29dc 000001d7d162d5d0    26020 Preemptive  000001D7D8228A00:000001D7D8228D28 000001d7d1602380 0     STA 
 ...
 159   18 22dc 000001d967906ff0  1029220 Preemptive  000001D7D834E558:000001D7D834E558 000001d7d1602380 1     MTA (GC) (Threadpool Worker) 
 ...

但從卦中數(shù)據(jù)看所有的 Exception 列都沒有異常信息，這就表示程序沒有走到 CLR 的異常處理鏈條上，至少是不完整的。

  • 是否有 AccessViolationException

參加過 C#內(nèi)功修煉訓(xùn)練營 的朋友應(yīng)該都知道，這種 c0000005 的異常在 C#層面最終會被map成兩種異常中的其一，即 NullReferenceException 和 AccessViolationException，選擇其一的邏輯就是判斷 RIP 是在托管層還是非托管層，模型圖如下：

圖片圖片

但遺憾的是在 !t 的列表中也沒有任何的 AccessViolationException 字樣，這也更加確認(rèn)了它沒有調(diào)用異常處理鏈中的 CreateThrowable 函數(shù)。。。

事出反常必有妖，在 !t 的輸出結(jié)果中可以看到此時(shí) 159號線程觸發(fā)了 GC，接下來切過去看一看。

0:120> ~159s
ntdll!NtQueryInformationThread+0x14:
00007ff8`8317ea34 c3              ret
0:159> k
 # Child-SP          RetAddr               Call Site
00 000000d5`00c3e7d8 00007ff8`7f216e2e     ntdll!NtQueryInformationThread+0x14
01 000000d5`00c3e7e0 00007ff8`6bcea731     KERNELBASE!GetThreadPriority+0x1e
02 000000d5`00c3e850 00007ff8`6be69cc5     clr!Thread::GetThreadPriority+0x56
03 000000d5`00c3e8a0 00007ff8`6be69bc4     clr!ThreadSuspend::SuspendRuntime+0xa5
04 000000d5`00c3e990 00007ff8`6bd814e3     clr!ThreadSuspend::SuspendEE+0x128
05 000000d5`00c3ea90 00007ff8`6bd85f51     clr!WKS::GCHeap::GarbageCollectGeneration+0xb7
06 000000d5`00c3eaf0 00007ff8`6be7ee6b     clr!WKS::gc_heap::trigger_gc_for_alloc+0x2d
07 000000d5`00c3eb30 00007ff8`470e53ec     clr!JIT_New+0x4d6
08 000000d5`00c3eee0 00007ff8`470e537c     Microsoft_VisualBasic_ni!Microsoft.VisualBasic.Strings.ReplaceInternal+0x3c [f:\dd\vb\runtime\msvbalib\Strings.vb @ 761] 
09 000000d5`00c3ef80 00007ff8`0d04f81f     Microsoft_VisualBasic_ni!Microsoft.VisualBasic.Strings.Replace+0x15c [f:\dd\vb\runtime\msvbalib\Strings.vb @ 737] 
...

從卦中的線程棧來看，此時(shí)正在 SuspendEE 階段，而且還是處于早期階段，正在準(zhǔn)備給 SuspendThread 安排一個(gè)好的優(yōu)先級，主要是怕優(yōu)先級太低了，導(dǎo)致 線程饑餓 得不到調(diào)度，畢竟 GC Process 的過程一定要是快中再快，接下來我們看下程序的 framework 版本。

0:159> !eeversion
4.7.3190.0 free
Workstation mode
SOS Version: 4.7.3190.0 retail build

可以看到還是比較老的 .netframework 4.7.3，結(jié)合這么多信息，我個(gè)人覺得這可能是 CLR 的一個(gè) bug，在 SuspendEE 階段的早期（還沒有 foreach threads）剛好遇到了一個(gè)硬件異常，這個(gè) 硬件異常 CLR 在業(yè)務(wù)邏輯上沒處理好，導(dǎo)致 SEH 異常沒有引入到 托管層，或者中途的某一環(huán)斷掉了，我放一張C#內(nèi)功修煉訓(xùn)練營 中的硬件異常完整流程圖。

圖片圖片

最后給到朋友的建議比較簡單：

  • 判 null 的時(shí)候一定要加 null 判斷，避免異常邏輯。
  • 升級 framework 到最新的 4.8.1 觀察。

三：總結(jié)

這次程序崩潰的原因很簡單，就是 空引用異常 ，但詭異就詭異在明明有 trycatch 在外部，硬是沒接住，這個(gè)大概率是 CLR 的 bug，讓我這個(gè)分析多年dump的老手都嘆為觀止，開了眼界，無語了無語了...

責(zé)任編輯：武曉燕 來源： 一線碼農(nóng)聊技術(shù)
.NET微信Windows
相關(guān)推薦

2023-06-26 00:12:46

2024-12-27 13:31:18

.NETdump調(diào)試

2024-03-28 12:56:36

2023-03-26 20:24:50

ERP網(wǎng)站系統(tǒng)

2024-03-26 00:44:53

.NETCIM系統(tǒng)

2024-07-12 11:20:34

.NET崩潰視覺程序

2022-10-25 14:17:01

.NET代碼程序

2023-06-29 17:55:00

.NET日志WinDbg

2024-07-09 11:51:20

Windows線程池源碼

2024-05-31 12:56:06

.NET代碼方法

2023-04-06 10:52:18

2024-06-04 10:54:34

.NET代碼程序

2023-09-27 07:23:10

.NET監(jiān)控軟件

2023-11-01 10:46:12

.NET線程同步

2024-08-27 13:08:50

2022-10-13 18:40:05

.NETOA后端

2023-07-06 10:11:38

.NET模式dump

2024-05-20 09:39:02

.NETurl線程池

2024-07-01 13:00:24

.NET網(wǎng)絡(luò)邊緣計(jì)算

2021-10-27 07:30:32

.NETCPU論壇
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號