記記憶體條硬體損壞藍色畫面的 dump 檔案分析

lindexi發表於2024-07-10

本文記錄我的電腦的記憶體條的硬體損壞了,導致用著用著就藍色畫面,我透過啟動和故障恢復配置自動藍色畫面打 dump 的功能,在藍色畫面時建立了 dump 檔案。透過分析 dump 檔案大概猜測是記憶體的問題

以下是我用 windbg 分析的兩次藍色畫面

第一次是用著 VS 的過程藍色畫面了,我發現好多次都是使用 VS 藍色畫面的,一開始還以為是 VS 投毒了

PROCESS_NAME:  devenv.exe

TRAP_FRAME:  ffff9f8e53267420 -- (.trap 0xffff9f8e53267420)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=000010e800000006
rdx=d70dab047be00460 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8054bd520ed rsp=ffff9f8e532675b0 rbp=ffff9f8e53267820
 r8=00007ff8221127be  r9=ffffa0800f9ad7f0 r10=8040000000201039
r11=ffffadd6eb75b7f8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na pe nc
nt!MiHandleTransitionFault+0xed:
fffff805`4bd520ed 8b4138          mov     eax,dword ptr [rcx+38h] ds:000010e8`0000003e=????????
Resetting default scope

STACK_TEXT:  
ffff9f8e`532672d8 fffff805`4be2be29 : 00000000`0000000a 000010e8`0000003e 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
ffff9f8e`532672e0 fffff805`4be27289 : 0000007f`00000000 00007ff8`219ef000 00000000`00000008 03a5ce00`00000000 : nt!KiBugCheckDispatch+0x69
ffff9f8e`53267420 fffff805`4bd520ed : ffff9f8e`53267a20 1a000004`38454867 ffffa080`0d581a20 fffff805`4bccdadc : nt!KiPageFault+0x489
ffff9f8e`532675b0 fffff805`4bd517d6 : ffff9f8e`532677f8 ffffb009`d4f2cc90 ffffa080`06030ab0 00000000`00000000 : nt!MiHandleTransitionFault+0xed
ffff9f8e`53267630 fffff805`4bd51113 : ffff9f8e`53267820 ffffadd6`eb6fff00 ffffa080`06030ab0 00000000`00000000 : nt!MiResolveTransitionFault+0x156
ffff9f8e`532676f0 fffff805`4bd4abea : ffff9f8e`53267820 00000000`00000000 ffff9f8e`532677f8 00000000`00000000 : nt!MiResolveProtoPteFault+0x7a3
ffff9f8e`532677c0 fffff805`4bd47db2 : ffffd70d`b1b80700 00000000`00000000 00000000`c0000016 00000034`00000000 : nt!MiDispatchFault+0x3ca
ffff9f8e`53267900 fffff805`4be2717e : ffffd70d`ab42b080 00000154`0fe40000 00000000`020004db 00000000`00000004 : nt!MmAccessFault+0x152
ffff9f8e`53267a20 00007ff8`acf1f71d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x37e
00000034`ab1aa150 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ff8`acf1f71d

透過以上的 nt!KiPageFault 函式,即記憶體缺頁錯誤堆疊,大概可以猜測和記憶體相關

第二個 dump 分析如下

PROCESS_NAME:  svchost.exe

TRAP_FRAME:  ffff8b82b28b6d60 -- (.trap 0xffff8b82b28b6d60)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=9c8b7ed481500420 rbx=0000000000000000 rcx=0000000000000000
rdx=80400000001a47a8 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8051973eaf7 rsp=ffff8b82b28b6ef0 rbp=ffff8b82b28b6f89
 r8=0a00000000000060  r9=0000000000000000 r10=0000000000000006
r11=47a8000000030546 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!MiIdentifyPfn+0x5a7:
fffff805`1973eaf7 f00fba6e481f    lock bts dword ptr [rsi+48h],1Fh ds:00000000`00000048=????????
Resetting default scope

STACK_TEXT:  
ffff8b82`b28b6c18 fffff805`1982be29 : 00000000`0000000a 00000000`00000048 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
ffff8b82`b28b6c20 fffff805`19827289 : ffff8b82`0000018e fffff805`19735df5 ffff8b82`b28b6d90 ffff8b82`b28b6e08 : nt!KiBugCheckDispatch+0x69
ffff8b82`b28b6d60 fffff805`1973eaf7 : 00000000`000018c0 00000000`00000000 00000000`42506650 fffff805`196bf5af : nt!KiPageFault+0x489
ffff8b82`b28b6ef0 fffff805`1973c915 : 00000000`00000100 00000026`94ffa100 00000000`00000000 fffff805`19ba44c5 : nt!MiIdentifyPfn+0x5a7
ffff8b82`b28b6ff0 fffff805`19be48ca : ffff9c8b`00000000 ffff9c8b`7cfa6a50 ffff9c8b`7cf76080 ffff9c8b`7cfa78c0 : nt!MiIdentifyPfnWrapper+0x75
ffff8b82`b28b7030 fffff805`19ba41b4 : 00000000`00000000 00000000`00000001 ffff9c8b`7cfa6000 00000000`00000001 : nt!MmQueryPfnList+0x7a
ffff8b82`b28b7070 fffff805`19ba3deb : 00000000`00000000 00000000`00000000 ffffc000`08db9730 ffff9c8b`7cfa6000 : nt!PfpPfnPrioRequest+0x80
ffff8b82`b28b70e0 fffff805`19ba1dfd : 00000026`94ffa0a8 fffff805`196c3657 00000000`0000004f 00000000`00000000 : nt!PfQuerySuperfetchInformation+0xe7
ffff8b82`b28b71b0 fffff805`19ba1aad : 00000000`00000000 00000026`94ffd300 00000026`94ffa0e0 00000000`00000000 : nt!ExpQuerySystemInformation+0x2ed
ffff8b82`b28b79e0 fffff805`1982b505 : 00000026`94ff0000 00000000`00000000 00000000`00000008 00000000`00000a0a : nt!NtQuerySystemInformation+0x5d
ffff8b82`b28b7a20 00007ffc`38070664 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x25
00000026`94ff9fa8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffc`38070664

也是掛在 KiPageFault 這裡,證明應該就是記憶體相關問題。看到以上堆疊,只可以猜測是記憶體相關問題,不知道是驅動層問題,還是超頻問題,還是記憶體條硬體損壞問題

lsj 的協助下,我使用了 TestMem5 工具進行測試,測試到了是一條記憶體條硬體損壞

拆掉損壞的記憶體條就不會藍色畫面了

以上的藍色畫面 dump 檔案是透過在高階系統配置裡面,點選啟動和故障恢復裡,配置系統失敗時寫入除錯資訊

在此之前我使用 Windows 自帶的 控制皮膚\系統和安全\Windows 工具 的 Windows 記憶體診斷 工具都掃描不出來問題,這是因為此工具的記憶體壓力不夠大

這也就是為什麼經常炸在 VS 的原因,因為 VS 給記憶體的壓力足夠大。使用 TestMem5 工具進行測試能夠更好找到坑

相關文章