Windows 11에서 프로그램이 갑자기 종료될 때 — 안정성 모니터·이벤트 뷰어·WER 로그로 원인 찾기

Windows 11에서 사용하던 프로그램이 아무런 안내 없이 갑자기 종료되거나 특정 작업을 할 때마다 반복해서 꺼지는 경우가 있습니다.

이런 문제가 발생하면 프로그램을 바로 삭제하고 다시 설치하거나 sfc /scannow부터 실행하기 쉽습니다.

하지만 애플리케이션 충돌은 프로그램 자체의 버그뿐 아니라 플러그인, 드라이버, 보안 프로그램, 런타임 구성 요소, Windows 시스템 파일 등 다양한 원인으로 발생할 수 있습니다.

따라서 먼저 언제 어떤 프로세스가 어떤 모듈에서 종료됐는지 기록을 확인하는 것이 중요합니다.

Windows에는 별도의 프로그램을 설치하지 않아도 다음 도구가 기본적으로 제공됩니다.

안정성 모니터
→ 오류가 발생한 시점과 반복 패턴 확인

이벤트 뷰어
→ 실제 Application Error와 Event ID 확인

Windows Error Reporting(WER)
→ 충돌 보고서 및 필요할 경우 Dump 수집

이 글에서는 프로그램을 무작정 재설치하기 전에 이 세 정보를 연결해 원인을 좁히는 방법을 정리합니다.

먼저 확인할 내용

확인 기준 환경

OS: Windows 11 25H2
기본 도구: 안정성 모니터, 이벤트 뷰어, Windows Error Reporting
명령 환경: PowerShell 또는 관리자 권한 명령 프롬프트
분석 대상: 일반적인 사용자 모드 애플리케이션 충돌

Windows 11 25H2는 이 글의 확인 기준 OS이며, 아래의 모든 Application Crash 유형을 같은 환경에서 직접 재현했다는 의미는 아닙니다.

공식 문서 확인일: 2026-08-25

대표 증상

다음과 같은 상황을 대상으로 합니다.

프로그램이 실행 직후 종료됨
특정 메뉴나 기능을 사용할 때 프로그램이 꺼짐
별도의 오류 창 없이 프로그램이 사라짐
같은 프로그램이 하루에 여러 번 충돌함
업데이트 이후 특정 프로그램이 자주 종료됨
여러 프로그램이 비슷한 시점부터 충돌함
이벤트 뷰어에서 Application Error가 반복됨
Event ID 1000이 기록됨
ntdll.dll, KERNELBASE.dll 등이 Faulting Module로 표시됨
0xc0000005 같은 Exception Code가 기록됨

결론

진단 순서는 다음과 같이 가져가는 것이 좋습니다.

충돌 발생 시간 기록
↓
안정성 모니터에서 반복 패턴 확인
↓
이벤트 뷰어 Application 로그 확인
↓
Event ID 1000 세부 정보 확인
↓
Faulting Application / Module / Exception Code 확인
↓
동일 시간대 WER 이벤트 확인
↓
특정 프로그램 문제인지 Windows 공통 문제인지 분리
↓
필요한 부분만 업데이트·복구
↓
반복될 경우 Dump 수집
↓
동일 작업으로 재검증

1. 가장 먼저 충돌 시간을 기록하기

프로그램이 갑자기 종료됐다면 가장 먼저 시간을 기록합니다.

예를 들어:

2026-08-25 14:32경

처럼 분 단위까지 확인하는 것이 좋습니다.

이벤트 뷰어에는 정상적인 정보·경고·오류 이벤트가 상당히 많이 기록됩니다.

오류가 있다는 이유만으로 모든 이벤트를 분석하면 실제 프로그램 충돌과 관계없는 로그까지 확인하게 됩니다.

따라서:

프로그램이 종료된 시각

과:

Windows 로그의 이벤트 발생 시각

을 연결하는 것이 첫 번째 단계입니다.

가능하다면 다음 정보도 함께 기록합니다.

프로그램 이름
수행 중이던 작업
오류 메시지
업데이트 직후인지 여부
같은 동작에서 재현되는지 여부

2. 안정성 모니터로 전체 흐름부터 확인

개별 Event Log를 보기 전에 안정성 모니터를 사용하면 문제 발생 시점을 빠르게 찾을 수 있습니다.

Win + R을 누른 뒤 다음 명령을 실행합니다.

perfmon /rel

Windows 공식 perfmon 명령에는 /rel 옵션이 있으며 안정성 모니터를 실행합니다.

안정성 모니터가 열리면 날짜별로 시스템 상태를 확인할 수 있습니다.

주로 다음 항목을 확인합니다.

응용 프로그램 오류
Windows 오류
기타 오류
소프트웨어 설치
Windows Update
드라이버 또는 애플리케이션 변경 시점

특정 날짜에 빨간색 오류 표시가 집중되어 있다면 해당 시점을 선택합니다.

3. 한 프로그램만 충돌하는지 여러 프로그램이 충돌하는지 확인

이 구분이 중요합니다.

특정 프로그램만 반복해서 종료

예를 들어:

ExampleApp.exe만 계속 종료
다른 프로그램은 모두 정상
같은 기능을 사용할 때 재현

이라면 우선 해당 애플리케이션과 관련된 영역을 확인합니다.

대표적으로:

프로그램 업데이트
플러그인
확장 기능
설정 파일
관련 런타임
그래픽 드라이버
프로그램 자체 버그

등입니다.

여러 프로그램에서 충돌 발생

서로 다른 프로그램이 비슷한 시기부터 동시에 불안정하다면 공통 구성 요소도 확인해야 합니다.

예를 들어:

Windows Update
그래픽 또는 장치 드라이버
보안 프로그램
시스템 파일
메모리 또는 시스템 안정성

등으로 범위를 넓힐 수 있습니다.

다만 여러 프로그램이 충돌한다는 이유만으로 하드웨어 문제라고 바로 단정해서는 안 됩니다.

먼저 실제 Event Log를 확인합니다.

4. 이벤트 뷰어 열기

Win + R을 누르고 다음을 입력합니다.

eventvwr.msc

이벤트 뷰어가 열리면 다음으로 이동합니다.

Windows 로그 → 응용 프로그램

영문 환경이라면:

Windows Logs → Application

입니다.

여기에는 Windows와 설치된 프로그램에서 생성하는 Application 관련 이벤트가 기록됩니다.

충돌 시간과 가까운 오류(Error) 이벤트부터 확인합니다.

5. Application Error의 Event ID 1000 확인

Microsoft의 애플리케이션 충돌 Troubleshooting 문서에서는 Application Error Source의 Event ID 1000을 실제 Application Crash 이벤트로 설명합니다.

대표적으로 다음과 같은 정보가 기록됩니다.

Faulting application name
Faulting application version
Faulting module name
Faulting module version
Exception code
Fault offset
Process ID
Application path
Module path
Report ID

예를 들어 Event ID 1000을 발견했다면 단순히:

이벤트 1000 오류

라고 기록하지 말고 세부 항목을 확인하는 것이 중요합니다.

6. 가장 먼저 Faulting application name 확인

다음 항목을 확인합니다.

Faulting application name

이 값은 실제로 충돌한 실행 파일을 보여줍니다.

예를 들어:

ExampleApp.exe

라고 되어 있다면 현재 분석해야 할 프로세스를 명확하게 특정할 수 있습니다.

다음으로:

Faulting application path

도 확인합니다.

같은 이름의 실행 파일이 여러 위치에 존재할 수 있기 때문입니다.

예를 들어:

C:\Program Files\Example\ExampleApp.exe

와 같이 실제 실행 경로까지 기록해두는 것이 좋습니다.

7. Faulting module name 확인

다음으로 확인할 값은:

Faulting module name

입니다.

예를 들어:

ExamplePlugin.dll

처럼 특정 프로그램 전용 DLL이 반복적으로 나타난다면 해당 Module을 중심으로 조사 범위를 좁힐 수 있습니다.

하지만 다음과 같은 Windows DLL이 표시되는 경우도 많습니다.

ntdll.dll
KERNELBASE.dll
kernel32.dll

여기서 중요한 점이 있습니다.

Faulting Module에 Windows DLL이 표시됐다고 해당 DLL 자체가 손상됐다고 바로 판단하면 안 됩니다.

Microsoft 공식 Application Crash Troubleshooting 문서에서도 ntdll.dll, kernel32.dll, kernelbase.dll처럼 여러 Process가 공통으로 사용하는 Windows Module이 Faulting Module로 표시될 수 있으며, 실제로는 앞서 잘못 동작한 다른 Module의 영향을 받아 예외가 발생한 지점일 수도 있다고 설명합니다.

따라서:

ntdll.dll 오류 → ntdll.dll 교체

와 같은 방식으로 접근해서는 안 됩니다.

8. Exception Code 확인

Event ID 1000에는 Exception code가 포함될 수 있습니다.

Microsoft 공식 문서에서 대표적으로 설명하는 값은 다음과 같습니다.

Exception Code	의미
`0xc0000005`	Access Violation
`0xc0000022`	Access Denied
`0xc0000374`	Heap Corruption

Exception Code는 원인을 확정하는 값은 아니지만 문제 유형을 구분하는 중요한 단서가 됩니다.

예를 들어 0xc0000005가 반복된다면 Process가 유효하지 않은 메모리 영역에 접근한 상황을 확인하게 됩니다.

하지만 이것만으로:

RAM이 고장났다.

또는:

Windows가 손상됐다.

라고 바로 결론내릴 수는 없습니다.

애플리케이션 버그, Module 충돌, Driver 또는 다른 Component의 영향도 고려해야 합니다.

9. 같은 Faulting Module이 반복되는지 확인

한 번 발생한 Event만으로 원인을 확정하기보다 반복 패턴을 확인합니다.

예를 들어 최근 세 번의 충돌에서 모두:

ExampleApp.exe

ExamplePlugin.dll

이 같이 표시된다면 중요한 단서가 됩니다.

반대로 매번 Faulting Module이 다르다면 조사 범위를 더 넓힐 필요가 있습니다.

확인할 때는 다음 항목을 함께 비교합니다.

충돌 시각
Application Name
Application Version
Faulting Module
Module Version
Exception Code
Report ID

특히 프로그램 업데이트 전후로 Application Version이 달라졌는지도 확인할 수 있습니다.

10. PowerShell로 Event ID 1000 빠르게 조회

이벤트 뷰어 GUI 대신 PowerShell에서도 최근 Application Crash 이벤트를 확인할 수 있습니다.

최근 24시간의 Event ID 1000을 확인하려면 다음과 같이 실행합니다.

$StartTime = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Application Error'
    Id           = 1000
    StartTime    = $StartTime
} |
Select-Object TimeCreated, Id, Message |
Format-List

Microsoft의 Get-WinEvent 공식 문서에서도 FilterHashtable을 이용해 Application 로그와 Application Error Provider, 시간 등을 지정하는 방식을 제공합니다.

이 방법은 충돌이 여러 번 발생해 Event Viewer에서 하나씩 찾기 번거로운 경우 유용합니다.

11. 특정 프로그램 충돌만 필터링

예를 들어 ExampleApp.exe의 오류만 찾고 싶다면 다음처럼 확인할 수 있습니다.

$StartTime = (Get-Date).AddDays(-3)

Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Application Error'
    Id           = 1000
    StartTime    = $StartTime
} |
Where-Object {
    $_.Message -match 'ExampleApp\.exe'
} |
Select-Object TimeCreated, Message |
Format-List

ExampleApp.exe 부분을 실제 문제가 발생한 실행 파일 이름으로 변경합니다.

이렇게 하면 특정 애플리케이션의 최근 충돌 기록을 시간순으로 비교하기 쉽습니다.

12. 같은 시간대 Event ID 1001도 확인

Application Crash가 발생한 경우 같은 시간대에 Windows Error Reporting 관련 Event ID 1001이 함께 기록되는 경우가 있습니다.

Microsoft 공식 Application Crash Troubleshooting 문서에서도 Event ID 1000과 1001이 반복되는 상황을 Application Crash 분석 대상으로 설명합니다.

따라서 Event ID 1000을 확인했다면 바로 전후 시간대의 Windows Error Reporting 이벤트도 같이 확인합니다.

다만 Event ID 번호 하나만으로 모든 의미를 고정해서 해석하지 말고 다음 값을 함께 확인합니다.

Source
Event Name
Application Name
Report ID
발생 시간

Report ID가 Event ID 1000의 값과 연결되는지도 참고할 수 있습니다.

13. 오류 이벤트가 있다는 이유만으로 모두 문제는 아님

이벤트 뷰어를 처음 확인하면 상당히 많은 Warning과 Error가 보일 수 있습니다.

이것만 보고:

Windows에 오류가 너무 많다.

라고 판단하면 안 됩니다.

중요한 기준은:

실제 증상이 발생한 시각과 관련된 Event인지

입니다.

예를 들어 프로그램이 오후 3시 10분에 종료됐는데 오전 8시에 발생한 전혀 다른 서비스 오류를 해결하는 것은 현재 문제와 관계없을 수 있습니다.

다음 세 요소를 같이 봅니다.

시간

프로세스 이름

증상

이 세 가지가 연결되는 Event를 우선 분석합니다.

14. 프로그램 하나만 충돌하면 프로그램 영역부터 확인

한 애플리케이션에서만 문제가 발생하고 다른 프로그램은 정상이라면 Windows 복구 명령부터 실행하기보다 해당 프로그램을 먼저 확인합니다.

확인 순서는 다음과 같이 가져갈 수 있습니다.

프로그램 버전 확인
↓
최근 업데이트 확인
↓
플러그인·확장 기능 확인
↓
프로그램 설정 초기화 가능 여부 확인
↓
관련 Driver 또는 Runtime 확인
↓
필요한 경우 재설치

Microsoft 공식 Application Crash Troubleshooting 가이드에서도 먼저 문제가 발생한 Application이 최신 버전인지 확인하도록 안내합니다.

15. 업데이트 이후부터 시작됐다면 변경 시점 비교

안정성 모니터의 장점 중 하나는 충돌 발생 시점과 시스템 변경 시점을 함께 볼 수 있다는 것입니다.

예를 들어:

그래픽 Driver 업데이트

↓

그날부터 특정 프로그램 Crash

패턴이 보인다면 Driver와 프로그램의 연관성을 조사할 근거가 생깁니다.

또는:

프로그램 새 버전 설치

↓

Application Failure 반복

이라면 애플리케이션 업데이트를 우선 확인할 수 있습니다.

하지만 시간상 가까웠다는 이유만으로 바로 원인이라고 단정하지는 않습니다.

Event ID 1000의 Module과 Exception 정보까지 같이 비교합니다.

16. 여러 Windows 기능도 같이 이상하면 시스템 파일 확인

한 프로그램만 종료되는 상황에서 DISM과 SFC를 습관적으로 실행할 필요는 없습니다.

반대로 다음과 같은 증상이 함께 나타난다면 Windows 시스템 무결성도 확인할 수 있습니다.

여러 Windows 기능이 동시에 오작동
여러 프로그램에서 반복적인 시스템 Module 오류
Windows Update 문제
시스템 파일 손상이 의심되는 증상
DISM 또는 Windows Servicing 오류

관리자 권한 터미널에서 먼저 Windows Image 상태를 검사할 수 있습니다.

DISM.exe /Online /Cleanup-Image /ScanHealth

손상이 확인되거나 복구가 필요하다고 판단될 경우:

DISM.exe /Online /Cleanup-Image /RestoreHealth

를 실행합니다.

그다음 Microsoft 공식 지원 절차에 따라:

sfc /scannow

을 실행합니다.

Microsoft는 시스템 파일 복구가 필요한 상황에서 DISM을 먼저 실행한 뒤 SFC를 사용하는 순서를 안내합니다.

17. DISM 실행 후 콘솔 결과만 보지 않기

DISM 명령에서 오류가 발생했다면 로그도 확인할 수 있습니다.

기본 DISM 로그 경로는:

%WINDIR%\Logs\DISM\dism.log

입니다.

Microsoft 공식 DISM 문서에서도 이 파일을 기본 Log로 설명합니다.

PowerShell에서는 다음과 같이 열 수 있습니다.

notepad.exe "$env:WINDIR\Logs\DISM\dism.log"

최근 로그를 빠르게 보려면:

Get-Content "$env:WINDIR\Logs\DISM\dism.log" -Tail 100

을 사용할 수도 있습니다.

18. DISM.log에서 오래된 오류와 현재 오류를 구분

dism.log에는 이전 실행 기록도 포함될 수 있습니다.

따라서 Error라는 문자열만 검색해서 발견한 예전 메시지를 현재 장애 원인이라고 단정해서는 안 됩니다.

다음 항목을 비교합니다.

DISM 실행 시간
실제 오류 발생 시간
Error Code
관련 Component
CBS.log 참조 여부

Microsoft 공식 문서에서는 DISM 로그에 더 자세한 정보가 필요한 경우 CBS.log를 참조할 수 있다고 설명합니다.

온라인 Windows Servicing의 CBS 로그 기본 경로는:

%WINDIR%\Logs\CBS\CBS.log

입니다.

19. SFC 결과도 구분해서 확인

sfc /scannow 실행 후 표시되는 결과는 서로 의미가 다릅니다.

대표적으로:

무결성 위반을 찾지 못함
손상된 파일을 찾아 복구함
손상된 파일을 발견했지만 일부를 복구하지 못함

등으로 나뉩니다.

SFC가 아무 문제도 찾지 못했는데 특정 프로그램 하나만 계속 충돌한다면 다시 해당 애플리케이션 영역으로 돌아가는 것이 좋습니다.

반대로 시스템 파일 손상을 실제로 발견했다면 복구 후 같은 프로그램 충돌이 재발하는지 확인합니다.

20. Event ID 1000의 Windows DLL을 임의로 교체하지 않기

인터넷에서 다음과 같은 해결법을 볼 수 있습니다.

ntdll.dll 다운로드

KERNELBASE.dll 교체

kernel32.dll 다른 PC에서 복사

이러한 방식은 권장하지 않습니다.

Windows 시스템 DLL은 OS 버전과 Build, Component Servicing 상태와 연결되어 있습니다.

특히 Microsoft 공식 Crash Troubleshooting 문서에서도 이런 Windows Module은 다른 잘못된 Module 동작의 결과로 오류 지점에 나타날 수 있다고 설명합니다.

따라서 Faulting Module 이름 하나만 보고 인터넷에서 DLL 파일을 받아 직접 교체하지 않습니다.

Windows 시스템 파일 문제가 실제로 확인됐다면 DISM과 SFC 같은 공식 복구 절차를 우선 사용합니다.

21. 반복 충돌인데 Event Log만으로 부족한 경우

Event ID 1000은 원인 범위를 좁히는 데 유용하지만 항상 Root Cause까지 보여주는 것은 아닙니다.

다음과 같은 상황에서는 Crash Dump가 필요할 수 있습니다.

같은 충돌이 반복됨
Faulting Module만으로 원인 판단 불가
프로그램 공급사에서 Dump 요청
개발자 또는 관리자 수준의 추가 분석 필요

Windows Error Reporting은 특정 애플리케이션 충돌 시 로컬 Dump를 저장하도록 구성할 수 있습니다.

이 기능은 기본적으로 활성화되어 있지 않으며 관리자 권한이 필요합니다.

22. 특정 프로그램에만 WER Dump 설정

예를 들어 분석 대상 프로그램이:

ExampleApp.exe

라고 가정합니다.

먼저 Dump 저장 폴더를 생성합니다.

New-Item -ItemType Directory -Path C:\CrashDumps -Force

관리자 권한 PowerShell에서 해당 프로그램에만 LocalDumps 설정을 추가합니다.

reg.exe add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ExampleApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps" /f

Dump 개수를 제한합니다.

reg.exe add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ExampleApp.exe" /v DumpCount /t REG_DWORD /d 3 /f

Full Dump를 사용하려면:

reg.exe add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ExampleApp.exe" /v DumpType /t REG_DWORD /d 2 /f

이후 동일한 충돌이 발생하면 C:\CrashDumps에 Dump가 생성되는지 확인합니다.

일부 32비트 애플리케이션이나 자체 Crash Reporting을 사용하는 프로그램에서는 동작 조건이 다를 수 있으므로 실제 수집 여부를 반드시 확인합니다.

23. Dump에는 민감한 정보가 포함될 수 있음

Full Process Dump에는 충돌 당시 Process Memory가 포함됩니다.

따라서 환경에 따라 다음 정보가 포함될 수 있습니다.

사용자 데이터
파일 경로
Hostname
프로그램 내부 데이터
인증 관련 정보
메모리에 존재하던 민감정보

Dump 파일을 게시글이나 공개 커뮤니티에 그대로 업로드하지 않습니다.

프로그램 공급사나 지원 담당자에게 전달할 때도 조직의 보안 정책과 개인정보 포함 여부를 먼저 확인합니다.

Full Dump는 용량도 클 수 있기 때문에 무제한으로 수집하지 않는 것이 좋습니다.

24. 분석이 끝나면 LocalDumps 설정 제거

Dump 수집이 끝났다면 해당 프로그램에 추가한 설정을 제거할 수 있습니다.

reg.exe delete "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ExampleApp.exe" /f

C:\CrashDumps에 생성된 파일도 필요한 분석이 끝난 뒤 보관 정책에 맞게 처리합니다.

문제 해결을 위해 임시로 변경한 설정을 그대로 남기지 않는 것도 중요합니다.

25. 수정 후 동일한 조건으로 재검증

설정을 변경하거나 프로그램을 업데이트했다면 문제 발생 조건과 동일한 작업을 다시 수행합니다.

예를 들어 특정 파일을 열 때 충돌했다면 같은 파일을 다시 엽니다.

특정 기능을 실행할 때 종료됐다면 같은 기능을 다시 실행합니다.

이후 다음 세 가지를 확인합니다.

프로그램

정상적으로 실행되고 더 이상 종료되지 않는지 확인합니다.

이벤트 뷰어

같은 시각에 새로운 Event ID 1000이 생성되지 않는지 확인합니다.

안정성 모니터

추가 Application Failure가 기록되는지 확인합니다.

단순히 “한 번 실행됐다”보다 기존 재현 조건에서 문제가 다시 발생하지 않는지 확인하는 것이 실제 해결 판정에 더 중요합니다.

해결되지 않는 경우 추가 확인

문제가 계속된다면 다음 정보를 정리합니다.

Windows 버전 및 Build
문제가 발생한 프로그램 이름
프로그램 버전
충돌 발생 시간
수행 중이던 작업
Event ID
Faulting Application
Faulting Module
Exception Code
Application Path
Module Path
Report ID
Windows Error Reporting Event
최근 프로그램 업데이트 여부
최근 Driver 업데이트 여부
DISM 결과
SFC 결과
동일 증상 재현 여부
필요한 경우 Crash Dump

이 정보가 있으면 단순히:

프로그램이 자꾸 꺼집니다.

라고 문의하는 것보다 훨씬 정확하게 원인을 전달할 수 있습니다.

주의사항

Windows 프로그램 충돌을 분석할 때 다음 사항을 주의합니다.

이벤트 뷰어의 모든 Error를 현재 문제와 연결하지 않기
실제 충돌 시간과 Event 발생 시간을 먼저 비교하기
Event ID 1000만 보고 원인을 확정하지 않기
ntdll.dll, KERNELBASE.dll을 바로 원인으로 단정하지 않기
인터넷에서 시스템 DLL을 임의로 내려받아 교체하지 않기
한 프로그램 문제인데 무조건 DISM·SFC부터 실행하지 않기
여러 설정을 동시에 변경하지 않기
Dump 파일을 공개 커뮤니티에 그대로 업로드하지 않기
WER Dump 설정은 필요한 Application에 제한해서 사용하기
진단이 끝난 임시 설정은 원상 복구하기
수정 후 반드시 같은 재현 조건에서 다시 확인하기

마무리

Windows 11에서 프로그램이 갑자기 종료될 때 가장 중요한 것은 프로그램을 바로 다시 설치하는 것이 아니라 충돌이 실제로 어떻게 기록됐는지 확인하는 것입니다.

먼저 안정성 모니터에서:

언제 문제가 시작됐는지

를 확인합니다.

그다음 Event Viewer에서:

어떤 프로그램이 종료됐는지

↓

어떤 Module에서 예외가 발생했는지

↓

어떤 Exception Code가 기록됐는지

를 확인합니다.

전체 흐름을 정리하면 다음과 같습니다.

프로그램 갑작스러운 종료
↓
충돌 시간 기록
↓
perfmon /rel로 반복 패턴 확인
↓
Event Viewer → Application 확인
↓
Event ID 1000 확인
↓
Faulting Application / Module / Exception Code 확인
↓
동일 시간대 WER 확인
↓
특정 프로그램 문제 / Windows 공통 문제 분리
↓
필요한 영역만 수정
↓
필요하면 WER Dump 수집
↓
같은 조건으로 재검증

특히 Faulting Module에 ntdll.dll이나 KERNELBASE.dll이 표시됐다는 이유만으로 Windows DLL 자체를 원인이라고 판단하는 것은 피하는 것이 좋습니다.

이 Module들은 많은 Process가 공통으로 사용하는 Windows 구성 요소이며 실제 문제는 앞선 다른 Module의 잘못된 동작에서 시작됐을 수 있습니다.

반대로 특정 프로그램과 특정 Module, 동일 Exception Code가 반복된다면 조사 범위를 상당히 좁힐 수 있습니다.

결국 프로그램 충돌 분석도:

증상 → 시간 → 로그 → 반복 패턴 → 원인 범위 → 필요한 수정 → 재검증

순서로 접근하는 것이 중요합니다.

이렇게 기록을 기반으로 확인하면 무작정 프로그램과 Windows를 재설치하는 방식보다 실제 문제의 범위를 훨씬 명확하게 좁힐 수 있습니다.

참고 자료

Microsoft Learn — perfmon
perfmon /rel을 이용한 Windows 안정성 모니터 실행 방법을 확인할 수 있는 공식 문서
https://learn.microsoft.com/ko-kr/windows-server/administration/windows-commands/perfmon
Microsoft Learn — Application or service crashing troubleshooting guidance
Event ID 1000·1001, Faulting Module, Exception Code와 Application Crash 분석 절차에 대한 공식 문서
https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/troubleshoot-application-service-crashing-behavior
Microsoft Learn — Get-WinEvent
PowerShell에서 Application Event Log를 조건별로 검색하는 공식 Cmdlet 문서
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent
Microsoft Learn — Collecting User-Mode Dumps
Windows Error Reporting LocalDumps를 이용해 Application Crash Dump를 저장하는 공식 문서
https://learn.microsoft.com/ko-kr/windows/win32/wer/collecting-user-mode-dumps
Microsoft Learn — DISM Best Practices
DISM의 기본 로그 위치인 %WINDIR%\Logs\DISM\dism.log과 로그 활용 방법을 설명하는 공식 문서
https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/deployment-image-servicing-and-management–dism–best-practices?view=windows-11
Microsoft Support — System File Checker
Windows 시스템 파일 손상이 의심되는 경우 DISM과 SFC를 사용하는 공식 복구 절차
https://support.microsoft.com/ko-kr/windows/experience/backup-recovery/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system-files

Post Views: 18