듀얼 채널 메모리 정렬을 지키지 않은 컴퓨터의 Windows 비정상 종료 현상(Blue Screen)
이상하군요, 메모리를 128GB로 올렸는데 블루 스크린이 1주일에 서너 번씩 발생하기 시작했습니다. 그런 탓에 (내심 Radeon 그래픽 카드를 의심한 탓에 ^^;) 그래픽 카드를 GeForce로 바꾸기까지 했지만, ^^; 그 현상은 없어지지 않았습니다.
재미있는 건, WinDbg로 메모리 덤프를 분석했을 때,
1: kd> !analyze -v
Loading Kernel Symbols
...[생략]...
Loading User Symbols
PEB is paged out (Peb.Ldr = 000000eb`bdb53018). Type ".hh dbgerr001" for details
Loading unloaded module list
...[생략]...
DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
DISPATCH_LEVEL or above.
Arg2: 0000000000001e00, The watchdog period (in ticks).
Arg3: fffff80449f1c340, cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, which contains
additional information regarding the cumulative timeout
Arg4: 0000000000000000
...[생략]...
KEY_VALUES_STRING: 1
...[생략]...
BUGCHECK_CODE: 133
BUGCHECK_P1: 1
BUGCHECK_P2: 1e00
BUGCHECK_P3: fffff80449f1c340
BUGCHECK_P4: 0
FILE_IN_CAB: MEMORY.DMP
DUMP_FILE_ATTRIBUTES: 0x1800
FAULTING_THREAD: ffff850df7a1f080
DPC_TIMEOUT_TYPE: DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED
TRAP_FRAME: fffff48a2453ede0 -- (.trap 0xfffff48a2453ede0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=ffff850d00000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8044962614f rsp=fffff48a2453ef70 rbp=fffff48a2453eff0
r8=ffff850d00000000 r9=fffff48a2453f4b0 r10=ffff850dcd9be180
r11=fffff48a2453ff18 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
nt!KiPageFault+0x34f:
fffff804`4962614f 0fbaa5f800000009 bt dword ptr [rbp+0F8h],9 ss:0018:fffff48a`2453f0e8=00050286
Resetting default scope
...[생략]...
PROCESS_NAME: svchost.exe
STACK_TEXT:
ffffbc00`e8632c88 fffff804`49437a19 : 00000000`00000133 00000000`00000001 00000000`00001e00 fffff804`49f1c340 : nt!KeBugCheckEx
ffffbc00`e8632c90 fffff804`49437281 : 00034590`38a0710d ffffbc00`e8618180 00000000`016cad66 00000000`00000000 : nt!KeAccumulateTicks+0x239
ffffbc00`e8632cf0 fffff804`49435311 : 00000000`00000000 ffffbc00`e9565800 ffffbc00`e8618180 00000000`00000000 : nt!KiUpdateRunTime+0xd1
ffffbc00`e8632ea0 fffff804`49434d3a : fffff804`49e5fea0 ffffbc00`e9565830 ffffbc00`e9565830 00000000`00000002 : nt!KeClockInterruptNotify+0xc1
ffffbc00`e8632f40 fffff804`49515f8c : 00000365`9710cacd ffff850d`c5514480 ffff850d`c5514530 00000000`00000000 : nt!HalpTimerClockInterrupt+0x10a
ffffbc00`e8632f70 fffff804`4961711a : fffff48a`2453ee60 ffff850d`c5514480 fffff48a`2453f1e8 00000000`00000000 : nt!KiCallInterruptServiceRoutine+0x9c
ffffbc00`e8632fb0 fffff804`496179e7 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
fffff48a`2453ede0 fffff804`4962614f : ffff850d`cd9be180 00000000`00000050 00000000`00000002 00000000`00000000 : nt!KiInterruptDispatchNoLockNoEtw+0x37
fffff48a`2453ef70 fffff804`4961f387 : ffff850d`cd9be180 fffff804`494e3261 ffff850e`051df490 ffff850e`0639e070 : nt!KiPageFault+0x34f
fffff48a`2453f100 fffff804`494e3261 : ffff850e`051df490 ffff850e`0639e070 fffff48a`2453f170 00000000`00000000 : nt!ExpInterlockedPopEntrySListFault
fffff48a`2453f110 fffff804`4dd94e71 : 00000000`00001002 fffff48a`2453f7e8 fffff48a`2453f261 fffff804`4db6892a : nt!ExAllocateFromLookasideListEx+0x11
fffff48a`2453f150 fffff804`4dd928f4 : 00000000`00000017 ffff850d`e5fd1cc0 fffff48a`2400ff02 ffff850e`2700ff02 : tcpip!WfpAllocateFromPerProcessorLookasideList+0x39
fffff48a`2453f180 fffff804`4dd91b5a : badbadfa`badbadfa 00000000`91870032 badbadfa`badbadfa ffff850d`cd973aa0 : tcpip!WfpAleInsertRemoteEndpoint+0x97c
fffff48a`2453f650 fffff804`4dd90be0 : ffff850d`e53b20f0 fffff804`4df22bd2 fffff804`5c131c00 00000000`00000000 : tcpip!WfpAlepAuthorizeSend+0xab2
fffff48a`2453fab0 fffff804`4dd6276c : fffff48a`2453fdd8 ffff850d`ce862000 ffff850d`00000004 00000000`00000000 : tcpip!WfpAleAuthorizeSend+0x3c4
fffff48a`2453fe60 fffff804`4dd9c758 : 00000000`00000000 00000000`00000180 00000000`00000001 ffff850d`f0e067c0 : tcpip!ProcessALEForTransportPacket+0x82c
fffff48a`245400d0 fffff804`4dd7e67d : 00000000`00040246 fffff804`4948e36c ffffbc00`e9051180 ffffbc00`e9051180 : tcpip!WfpProcessOutTransportStackIndication+0x3c8
fffff48a`245403f0 fffff804`4dd7d367 : fffff804`4df4e000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IppInspectLocalDatagramsOut+0x85d
fffff48a`24540740 fffff804`4dd78e66 : ffff850d`e53b2000 00000000`00000000 fffff804`4df4e000 ffff850d`fa27acc0 : tcpip!IppSendDatagramsCommon+0x407
fffff48a`24540900 fffff804`4dd777fa : ffff850d`ceb86400 00000000`00000000 ffff850e`211e72e8 fffff804`00000000 : tcpip!UdpSendMessagesOnPath+0x10e6
fffff48a`24540d20 fffff804`4dd77505 : fffff48a`245411f0 ffff850e`211e72d0 fffff48a`245411f0 fffff48a`24541b01 : tcpip!UdpSendMessages+0x2da
fffff48a`245410e0 fffff804`49480aba : 00000000`00000000 ffff850e`211e7280 00000000`00000000 ffff850d`c54549f0 : tcpip!UdpTlProviderSendMessagesCalloutRoutine+0x15
fffff48a`24541110 fffff804`49480a2d : fffff804`4dd774f0 fffff48a`245411f0 00000000`00000000 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0x7a
fffff48a`24541180 fffff804`4ddbab1a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0x1d
fffff48a`245411c0 fffff804`4ef79728 : 00000000`00000000 fffff48a`24541b60 ffff850d`fea2dd80 fffff48a`24541b60 : tcpip!UdpTlProviderSendMessages+0x7a
fffff48a`24541230 fffff804`4ef78fa7 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : afd!AfdFastDatagramSend+0x708
fffff48a`24541470 fffff804`498c72ae : fffff48a`00000000 00000000`00000000 fffff48a`24541b60 ffffffff`f6769800 : afd!AfdFastIoDeviceControl+0x1857
fffff48a`24541810 fffff804`498c6e36 : 00000000`000000d6 00000000`00000000 00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x45e
fffff48a`24541a00 fffff804`4962a508 : 00000000`000002dc 00000000`ffffffff 00000000`00003e80 00000000`000006e8 : nt!NtDeviceIoControlFile+0x56
fffff48a`24541a70 00007ffb`87570484 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
000000eb`be27f2b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffb`87570484
...[생략]...
딱히 3rd-party 드라이버가 문제를 일으킨 것 같지는 않다는 점입니다. 위의 경우에는 그 한 사례를 든 것인데요, 저때는 tcpip.sys에서 발생한 듯 보이지만 그다음 발생한 덤프에서의 분석은 매번 다른 지점에서, 즉 아무런 연관을 찾을 수가 없었습니다.
대부분의 경우에는 "PAGE_FAULT_IN_NONPAGED_AREA" 오류가 발생했는데요, 그러다 문든 생각난 것이, 메모리를 기존 2개에서 추가로 2개를 더 장착하면서 이 현상이 더 뚜렸했었고 왠지 메모리 뱅크 정렬이 안 된 것 같다는 점이었습니다. 64GB일 때의 메모리가 2개 연속 장착돼 있었는데 사실 듀얼 채널이라면 한 칸을 건너 뛰는 식으로 장착돼 있었어야 합니다. 단지, 제가 컴퓨터 조립을 해 본지 오래돼서 근래에는 듀얼 채널의 구조가 이런 식으로 바뀌었나 싶어 무시하고 추가로 2개를 남은 슬롯에 더 장착했던 건데요, 그래서 확인을 위해 해당 메인 보드의 매뉴얼을 봤더니,
TUF GAMING B550M-PLUS (WI-FI) User’s Manual ( English Edition )
; https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM4/TUF_GAMING_B550M-PLUS_(WI-FI)/E17266_TUF_GAMING_B550M-PLUS_WI-FI_UM_v2_WEB.pdf?model=TUF%20GAMING%20B550M-PLUS%20(WI-FI)
원래의 (한 칸 띄고 장착하는) 듀얼 채널 방식이 맞았습니다.
DDR4 DIMM_A1 (64bit, 288-pin module) == B1과 쌍으로 듀얼 채널
DDR4 DIMM_A2 (64bit, 288-pin module) == B2와 쌍으로 듀얼 채널
DDR4 DIMM_B1 (64bit, 288-pin module)
DDR4 DIMM_B2 (64bit, 288-pin module)
그러니까, (A1, B1), (A2, B2)의 쌍으로 다루는 듀얼 채널의 구조에서 기존 A1, A2에 연속으로 장착됐던 64GB 메모리 상태는 성능 향상의 장점을 누리지 못했던 것이고, 그런 상태에서 다음과 같은 식으로 추가 장착했으니,
DDR4 DIMM_A1 (64bit, 288-pin module) - 기존 RAM (B1의 다른 메모리와 듀얼 채널)
DDR4 DIMM_A2 (64bit, 288-pin module) - 기존 RAM (B2의 다른 메모리와 듀얼 채널)
DDR4 DIMM_B1 (64bit, 288-pin module) - 신규 RAM
DDR4 DIMM_B2 (64bit, 288-pin module) - 신규 RAM
미세하게 다른 메모리 규격으로 인해 블루 스크린이 (무작위로) 발생한 것입니다. 결국, 다음과 같이 메모리 장착을 바꿨고,
DDR4 DIMM_A1 (64bit, 288-pin module) - 기존 RAM
DDR4 DIMM_A2 (64bit, 288-pin module) - 신규 RAM
DDR4 DIMM_B1 (64bit, 288-pin module) - 기존 RAM
DDR4 DIMM_B2 (64bit, 288-pin module) - 신규 RAM
이후부터 (거의 6개월 넘게) 정말 블루 스크린이 발생하지 않게 되었습니다. ^^;
참고로, 기존/신규 RAM 모두 삼성이었고 라벨에 적힌 정보까지도 동일했지만 생산지가 달랐습니다.
기존 RAM: 32GB 2Rx8 PC4-3200AA-UB2-11 (Made in Korea) M378A4G43AB2-CWE
SEC 031 K4AAG08 5WA BCWE
신규 RAM: 32GB 2Rx8 PC4-3200AA-UB2-11 (Made in China) M378A4G43AB2-CWE
SEC 313 K4AAG08 5WA BCWE
저 정도의 아주 미세한 차이인데도 듀얼 채널에서 블루 스크린이 뜰 정도라면, 듀얼 채널의 메모리 접근 동기화가 꽤나 높은 수준의 정확성을 요구하는 것 같습니다. ^^;
기왕 이야기가 나온 김에, 블루 스크린과 관련한 사례로 아래의 경우도 재미있습니다. ^^
Janet Jackson had the power to crash laptop computers
; https://devblogs.microsoft.com/oldnewthing/20220816-00/?p=106994
Janet Jackson had the power to crash laptop computers, follow-up
; https://devblogs.microsoft.com/oldnewthing/20220920-00/?p=107201
This Janet Jackson BASSLINE breaks laptops
; https://youtu.be/-y3RGeaxksY
특정 제조사의 랩탑 모델에서 Janet Jackson의 "Rhythm Nation" 음악을 재생하면 비정상 종료한다는 이야기입니다. 조사 과정에서 그 노래의 뮤직 비디오를 재생해도 동일한 현상이 발생한다는 것과, 심지어 그 노래를 재생하지 않은 랩탑조차도 그 음악을 재생하고 있는 랩탑 근처에만 있으면 비정상 종료한다는 점이 발견됩니다.
원인은, 해당 랩탑에 탑재된 5400 RPM 하드 디스크의 회전에서 발생한 진동과 겹치는 주파수가 그 음악에서 발생했기 때문이라고 합니다.(주파수가 공명하면서, 즉 공진으로 인해 그 세기가 강해져 아마도 하드 디스크의 헤드가 오작동하지 않았나 싶습니다.) 해결은, 랩탑 제조업체가 그 주파수에 해당하는 음이 나오면 제거하도록 audio 파이프라인에 사용자 정의 필터를 추가했다고. ^^;
시간이 지나, Windows 7에서는 APO(Audio Processing Objects) 정책에 모든 오디오 필터를 비활성화시킬 수 있는 새로운 규칙을 제공했는데요,
Protecting Windows users from Janet Jackson’s Rhythm Nation
; https://devblogs.microsoft.com/oldnewthing/20250429-42/?p=111127
문제는 "Rhythm Nation" 등의 오작동을 해결하는 오디오 필터까지 그 규칙의 대상에 포함시켰다는 점입니다. 이로 인해, 그런 하드웨어적인 문제를 모르는 사용자들은 음악에서 제공하는 풍부한 사운드를 즐기기 위해 "모든 오디오 필터를 비활성화"하는 선택을 무심코 할 수 있는 가능성이 열려버린 것입니다.
이러한 문제가 인정돼 마이크로소프트 측은 "제조사의 특별한 오디오 필터"는 "모든 오디오 필터"의 범위로부터는 제외했다고 합니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]