Windows BSOD(Blue Screen of Death)는 특정 화면 보호기를 사용하거나 소프트웨어를 테스트하지 않는 한 컴퓨터 모니터에서 보고 싶은 것이 아닙니다. 그러나 때때로 Windows 사용자는 궁극적인 소프트웨어 오류 사례, 즉 커널 자체의 오류 사례를 경험하며, 이로 인해 시스템이 완전히 정지되고 결국에는 충돌이 발생합니다.

Linux에서는 이러한 종류의 상황을 커널 패닉이라고 합니다. Windows에서는 BSOD라고 합니다. 그러나 그것은 같은 것입니다. 즉, 시스템의 핵심, 커널 및 동반 드라이버에 있는 중요하고 복구할 수 없는 예외입니다.

마이크로 소개

커널 크래시 덤프 도구부터 시작하여 openSUSE 및 CentOS에 대한 설정을 계속하고 심층 분석으로 끝나는 Linux 충돌에 대한 매우 길고 괴상한 시리즈를 수행한 후 Windows 사용자에게 다소 짧고 덜 괴짜 버전의 BSOD 분석. 여기에는 두 가지 이유가 있습니다. 하나는 Windows 소스가 닫혀 있기 때문에 원하는 만큼 깊이 들어갈 수 없습니다. 둘째, 저는 Linux를 사용하는 것만큼 Windows 커널을 다루는 데 능숙하지 않습니다. 그럼에도 불구하고 이 튜토리얼은 여전히 ​​상당히 괴상하고 일반 사용자의 요구 사항, 필요 또는 욕구를 훨씬 뛰어넘을 것입니다. 그러나 Windows 내부에 대해 조금 더 배우고 핵심 시스템 문제를 진단하는 데 도움이 되는 새로운 기술을 습득하고 싶다면 잘 찾아오셨습니다.

이제 시작하겠습니다.

목차

질문

기술 용어를 파헤치기 전에 BSOD에 관한 몇 가지 질문에 답해 보겠습니다.

죽음의 블루 스크린이 나타나는 원인은 무엇입니까?

간단한 대답은 없습니다. 오랜 Windows 사용자는 일부 사람들이 BSOD를 매우 자주 경험하는 반면 다른 사람들은 전혀 보지 못하는 반면 모두 거의 동일한 Windows를 실행하고 있음을 알게 될 것입니다.

광범위한 경험은 일반적으로 BSOD가 Microsoft Windows 구성 요소로 인해 발생하지 않는다는 사실에서 비롯됩니다. 대부분의 사람들은 충돌에 대해 Windows를 비난하기를 좋아하지만 운영 체제 자체로 인해 발생하는 경우는 거의 없습니다.

내 개인적인 경험은 다음과 같습니다.

총 가동 시간이 10년인 두 대의 Windows 시스템에서 BSOD는 각 호스트에서 하나씩 두 번만 발생했습니다. 공교롭게도 두 충돌은 한 시간도 채 안되는 간격으로 발생했습니다.

최근 Windows 업데이트 또는 실행 중인 프로그램 중 하나로 인해 이 문제가 발생했다고 가정할 수 있습니다. 사실, 이것은 특히 두 시스템이 거의 동일한 하드웨어 및 소프트웨어 설정을 가지고 있다는 점을 고려할 때 좋은 단서처럼 보입니다. 그러나 이것은 소프트웨어 결함이 아닙니다.

실제로 일어난 일은 그래픽 카드가 과열되었다는 것입니다. 저것과 같이 쉬운. 몹시 더운 날이었고 그래픽 카드는 정상 온도 범위를 초과했습니다.

다른 컴퓨터에서 발생한 다른 모든 BSOD 사례는 무선 카드, 보안 프로그램 등을 포함하여 소프트웨어 또는 하드웨어에 의해 설치된 불량, 오작동 또는 버그가 있는 드라이버와 관련이 있습니다. 핵심 Windows 구성 요소 중 하나가 삐걱 거리는 것을 본 적이 없습니다. 명확히 하기 위해 여기서는 가정용에 대해 이야기하고 있습니다.

이제 우리가 말하는 내용을 알았으니 과학적으로 접근해 봅시다.

BSOD 수집 활성화

기본 제공 시스템 도구를 잘 활용하려면 Windows에서 미니 덤프라고 하는 크래시 덤프를 수집할 수 있도록 설정해야 합니다. 이는 Linux에서 LKCD 또는 Kdump를 활성화하는 것과 유사합니다. 기본적으로 Windows 커널 메모리 덤프는 활성화되어 있으므로 살펴보고 설정이 올바른지 확인하기만 하면 됩니다.

탐색기 메뉴, 속성, 시스템, 고급, 시작 및 복구에서 컴퓨터를 마우스 오른쪽 버튼으로 클릭하여 BSOD 컬렉션을 구성할 수 있습니다. 아래쪽 절반의 시스템 오류에서 매개변수를 구성해야 합니다.

충돌을 시스템 로그에 기록할지, 시스템을 자동으로 다시 시작할지 또는 기존 파일을 덮어쓸지 선택할 수 있습니다. 파일을 덮어쓰지 않는 것이 좋습니다. 나중에 비교 및 ​​분석을 위해 정보를 보유하는 것은 항상 좋은 일입니다.

주목해야 할 또 다른 사항은 디버깅 정보 쓰기 드롭다운 상자입니다. 여기에서 시스템이 충돌할 때 저장할 메모리 부분을 지정할 수 있습니다. 이것은 Kdump DUMPLEVEL과 매우 유사합니다.

다음과 같은 옵션이 있습니다.

작은 메모리 덤프 - 비정상 종료 정보가 포함된 기본 파일만 있습니다. 메모리에 로드된 실행 파일 및 DLL에 대한 추적이 없기 때문에 이것은 제한된 값입니다. Windows XP에서 이 파일의 크기는 64K입니다. Windows 7에서는 128K입니다.

커널 메모리 덤프 - 커널 버그나 드라이버 중 하나로 인해 커널 크래시가 발생하므로 대부분의 경우 충분해야 하는 커널만 포함하는 메모리 부분을 덤프합니다.

전체 메모리 덤프 - RAM의 전체 내용을 덤프합니다.

설정에 만족하면 확인을 클릭합니다. 이제 분석을 시작할 수 있습니다.

BSOD 수집

충돌의 근본 원인을 찾는 것은 쉽지 않습니다. 하드웨어 문제는 문제를 정확히 지적하지 않고 다양한 증상으로 나타날 수 있는 불규칙하고 예측하지 못한 동작을 유발할 수 있습니다. 소프트웨어 문제는 진단하기 쉬워야 합니다.

BSOD가 발생하면 첫 번째 작업은 문제가 있는 구성 요소를 격리하고 BSOD를 다시 트리거하도록 하는 것입니다. 문제를 복제할 수 있으면 문제를 해결할 수 있습니다.

드라이버 검증 도구

BSOD 문제를 해결하려는 경우 Driver Verifier를 사용해야 합니다.

Driver Verifier는 강력한 도구이며 다른 구성 요소와 메모리를 공유하지 않고 격리된 메모리 풀에서 드라이버를 실행하고, 극단적인 메모리 압력을 제공하고, 매개 변수를 확인하고, 언로드 확인 등 많은 작업을 수행할 수 있습니다.

Verifier 사용을 시작하려면 실행 파일을 찾아 시작하십시오. Windows XP에서 시작> 실행> 확인 프로그램을 클릭합니다. Windows 7에서 인라인 검색 상자에 Verifier를 입력하고 Enter 키를 누릅니다.

Verifier가 시작되면 이를 구성해야 합니다. 대부분의 사람들에게 적합한 표준 설정을 만들거나 주로 코드 개발자에게 유용한 사용자 지정 설정을 구성할 수 있습니다. 작업을 표시하거나 작업을 삭제하거나 현재 확인된 드라이버에 대한 정보를 표시할 수도 있습니다.

다음 메뉴 화면에서 서명되지 않은 드라이버, 이전 버전의 Windows용으로 빌드된 드라이버 또는 모든 드라이버 중에서 확인하려는 드라이버를 선택해야 합니다. 아직 문제가 실제로 무엇인지 모르기 때문에 모두 선택합니다.

다음 단계는 재부팅하는 것입니다. Verifier는 많은 CPU를 소비하고 시스템 속도를 상당히 저하시킵니다. 추가 충돌이 발생할 수도 있습니다. Verifier는 BSOD 사이에 결함이 있는 드라이버를 비활성화하고 최종적으로 바탕 화면에 도달할 때까지 재부팅합니다. 또한 소수의 미니 덤프를 수집했을 수도 있습니다.

이제 Verifier를 비활성화할 수 있습니다. 응용 프로그램을 시작하고 기존 설정을 삭제합니다.

또한 컴퓨터가 Verifier로 인해 데스크톱으로 부팅할 수 없는 경우 마지막으로 성공한 구성을 시작하거나 안전 모드로 부팅하여 도구를 비활성화할 수 있습니다.

자, 미니 덤프가 수집되었습니다. 분석해 보겠습니다.

블루스크린 진단

미니 덤프를 진단하려면 여러 가지 도구가 필요합니다. Linux 자습서를 기억한다면 crash를 사용하기 위한 전제 조건은 설치된 디버그 기호 및 debuginfo 패키지로 커널을 컴파일하는 것이었습니다.

Windows 심볼 패키지

음, Windows도 다르지 않습니다. 적절한 분석을 하려면 기호가 필요합니다. Windows 커널 버전과 정확히 일치하는 기호를 다운로드하여 설치해야 합니다. 그렇지 않으면 분석이 정확하지 않습니다. 다시 말하지만, 이와 관련하여 Linux와 다르지 않습니다.

이에 대한 예를 나중에 보여드리겠습니다.

기호가 설치된 후 충돌 데이터를 읽고 해석하는 도구가 필요합니다. 가장 쉽고 천천히 괴짜 언덕을 오르는 세 가지 도구를 보여 드리겠습니다.

BSOD 분석 도구 1:WhoCrashed

WhoCrashed는 기계 충돌을 일으킨 드라이버를 찾을 수 있는 간단하고 효과적인 도구입니다. 이 도구는 Windows 디버거를 설치해야 합니다.

BSOD 분석 도구 2:Nirsoft

Windows에 대해 어느 정도 진지한 사람이라면 Nir Sofer에서 개발하고 유지 관리하는 매우 다재다능한 Windows 유틸리티 모음인 Nirsoft 도구에 대해 들어봤을 것입니다. 특히 Windows 커널 메모리 덤프 분석에 사용되는 BlueScreenView라는 진단 도구가 필요합니다. 무엇보다도 이 유용한 작은 도구는 Nir가 개발한 100개 이상의 응용 프로그램 모음인 Nirlauncher라는 초강력 스위스 군용 칼 스타일 도구 상자에 포함되어 있습니다. Nir의 웹사이트가 내 Greatest 목록에 포함된 데에는 이유가 없습니다.

또한 Nir Sofer에는 BSOD를 시작하는 도구가 있어 충돌을 시뮬레이션할 수 있습니다. 이 도구는 StartBlueScreen이라고 하며 Nirlauncher 패키지에 포함되어 있습니다. Nirlauncher에 대한 자세한 내용은 내 소프트웨어 리뷰를 참조하십시오.

곧 이 두 프로그램에 대해 이야기하겠습니다.

BSOD 분석 도구 3:Windows 디버거(Windbg)

Windows 디버거는 Windows 시스템의 드라이버, 응용 프로그램 및 서비스를 포함하여 모든 종류의 문제를 해결하는 데 사용할 수 있는 다목적 도구입니다.

Windows 디버거는 Windows SDK에 포함되어 있습니다.

Windows 7에서 디버거를 설치할 때 .NET Framework 4 오류가 발생할 수 있습니다. .NET Framework에서 개발된 응용 프로그램으로 작업하지 않는 한 무시해도 됩니다. 우리의 경우 안전하게 진행할 수 있습니다.

설치 메뉴에서 원하는 구성 요소를 선택할 수 있습니다. 공통 유틸리티 아래에 Windows용 디버깅 도구가 필요합니다.

Windows 디버거는 시작할 때 별로 흥미로워 보이지 않지만 제대로 익숙해지고 작업하는 데 꽤 많은 시간이 걸리는 강력한 도구입니다. 소스 검사, 실행 중인 프로세스에 연결, 커널 덤프 검사 등에 사용할 수 있기 때문에 Linux의 GDB와 유사합니다.

BSOD 예

BSOD 시작(StartBlueScreen 사용)

이러한 도구가 작동하는 것을 보려면 BSOD가 필요합니다. 내 Windows 7 컴퓨터에서 Verifier를 실행해도 부작용이 발생하지 않았습니다. 따라서 앞서 언급한 NirSoft StartBlueScreen 도구를 사용해 봐야 합니다.

StartBlueScreen은 명령줄 도구입니다. 여러 매개변수를 사용하여 실행해야 하며, 그러면 BSOD가 트리거됩니다. BSOD를 실행하려면 Windows 상자에서 관리자 계정을 사용해야 합니다.

Windows 7에서 숨겨진 관리자 계정을 활성화하는 것은 약간 까다로울 수 있지만 이에 대한 별도의 자습서가 곧 제공될 예정입니다. 사실, Windows XP에서 동일한 작업을 수행하는 것도 쉬운 일이 아닙니다. 다시 말하지만, 이에 대해서는 별도로 논의하겠습니다.

관리자로 로그인한 후 명령줄에서 StartBlueScreen을 실행합니다. Nir Sofer는 자신의 웹 사이트에 여러 가지 예를 나열하므로 다음 중 하나를 사용합니다.

StartBlueScreen.exe 0x12 0 0 0 0

시스템 요청이 활성화된 상태에서 Linux에서 echo c> /proc/sysrq-trigger를 실행하는 것과 매우 유사합니다. 실제로 몇 초 후에 악명 높은 BSOD를 볼 수 있습니다.

머신이 덤프를 완료하도록 합니다. 발생한 후 충돌을 분석할 수 있습니다. 컴퓨터가 재부팅된 후 팝업 메시지가 표시될 수 있습니다. 무슨 일이 일어났는지에 대한 힌트가 이미 있고, 곧 더 자세한 내용이 나올 것입니다.

BSOD 분석

세 가지 도구가 각각 무엇을 제공하는지 살펴보겠습니다.

WhoCrashed 결과

일어난 일에 대한 매우 간단한 드릴다운을 얻습니다. 대부분의 사람들에게 이 정보는 시작하기에 충분합니다. 잘못된 드라이버의 이름을 알면 문제를 격리하는 데 도움이 될 수 있습니다.

오류가 nirsoftbluescreendriver.sys 드라이버로 인해 발생하는 알 수 없는 커널 트랩임을 알 수 있습니다. 글쎄, 이것은 예상됩니다. Nir의 코드는 내 null 포인터 커널 드라이버 예제와 비슷하다고 생각합니다.

Nirsoft BlueScreenView 결과

BlueScreenView는 더 자세한 정보를 제공합니다. 루트 폴더에 있는 미니 덤프 파일을 자동으로 로드합니다. Top View에는 Linux 충돌 분석 파일의 Panic String과 동일한 Bug Check String과 Kernel Page Error와 유사한 Bug Check Code를 포함하여 충돌에 대한 기본 정보가 표시됩니다.

아래쪽 창에는 메모리에 로드된 모든 드라이버 목록이 있으며 충돌과 관련된 드라이버는 연어로 표시되어 있습니다. 색상 이름인 것 같습니다. 크래시 프로세스에 대한 호출 추적만 보려면 옵션 메뉴에서 필터를 변경할 수 있습니다.

또한 원본 BSOD 화면(XP 스타일)을 로드할 수도 있습니다.

이것은 때때로 유용할 수 있습니다. 예를 들어 기술 정보 섹션을 살펴보십시오. 잘못된 드라이버의 이름과 메모리 주소가 있습니다. 다시 한 번 Linux 유추를 사용하려면 작업 백 트레이스의 예외 RIP와 같습니다. 실제로 스택에 집중해 보겠습니다.

실행 파일의 이름과 메모리 주소가 있습니다. 이론적으로 소스가 있으면 커널 충돌을 초래한 코드의 정확한 줄을 정확히 찾아낼 수 있습니다. 그렇지 않기 때문에 귀하가 할 수 있는 최선의 방법은 가능한 한 많은 데이터를 수집하고 추가 분석을 위해 Microsoft에 정보를 보내는 것입니다. 곧 그것에 대해 이야기하겠습니다.

일반적으로 Microsoft는 Microsoft 구성 요소의 충돌에 대한 패치를 발행하므로 질문은 nkrnlpa.exe가 Microsoft 구성 요소인지 어떻게 알 수 있습니까? 글쎄, 하나의 항목을 두 번 클릭하거나 마우스 오른쪽 버튼을 클릭하고 속성을 선택하면 자세한 정보를 얻을 수 있습니다.

보시다시피 Windows 충돌 작업은 Linux 작업과 크게 다르지 않습니다. 그러나 정확히 무슨 일이 일어났는지 알고 싶을 것이므로 항상 쉽게 사용할 수 있는 것은 아닌 소스가 필요합니다. 그런 다음 다시 말하지만 Linux에서도 항상 가능한 것은 아닙니다. 특히 Nvidia와 같은 독점 드라이버를 커널에 로드한 경우에는 더욱 그렇습니다. 파일 버전에 유의하십시오. 이것은 곧 작동하게 될 기호를 사용하려는 경우에 중요합니다.

Windows 디버거 결과

Windows 디버거는 언급된 세 가지 도구 중 가장 복잡하고 가장 강력한 도구입니다. 시작하기 전에 디버거로 작업하려면 시간, 인내 및 지식이 필요하다는 점을 알고 있어야 합니다. 사실, 내 허세에도 불구하고 충돌 분석에 관한 상식과 보편적 지식이 여기에 잘 적용되지만 도구에 대해 상당히 경험이 없습니다. 한 시스템에서 코드의 흐릿한 흔적 아래로 비즈니스를 알고 있다면 다른 모든 시스템에서 괜찮을 것입니다.

권한

관리자로 작업하지 않는 경우 명백한 보안상의 이유로 메모리 덤프에 액세스할 수 있는 권한이 없습니다. 파일을 복사하거나 올바른 권한을 설정해야 할 수 있습니다.

기호 로드

가장 먼저 해야 할 일은 기호를 로드하는 것입니다. 도구는 경로가 환경 변수에 저장되지 않을 수 있으므로 디스크의 기호 위치를 인식하지 못할 수 있습니다. 요점을 강조하기 위해 기호를 지정하지 않고 크래시 덤프를 로드하겠습니다.

오류 문자열을 확인하십시오. ERROR:Module loaded completed but ... 이는 기호가 로드되지 않은 경우 발생하는 것으로, 분석이 다소 무의미해집니다. 실제로 분석을 실행하면 몇 개의 물음표가 표시될 것입니다. 디버거는 충돌 당시 메모리에서 드라이버가 어떻게 매핑되었는지 추측할 수 없기 때문입니다.

.sympath 명령을 실행하여 현재 기호 경로를 확인할 수 있습니다. 기호를 로드하지 않으면 비어 있습니다. 이제 기호를 로드합니다.

기호를 로드한 후에는 미니 덤프 파일을 다시 열 필요가 없습니다. 다시 로드하기만 하면 됩니다. 기호 검색 경로 창에서 다시 로드 상자를 선택하거나 명령 창 하단에 kd>로 표시된 디버거 명령줄에서 .reload를 실행하여 이를 수행할 수 있습니다.

이제 다른 출력이 표시됩니다.

분석 실행

분석 실행은 !analyze -v 명령을 실행하여 수행됩니다. -v 플래그는 장황함을 나타냅니다.

!분석 -v

이제 충돌 인수에 대한 자세한 문자열을 포함하여 더 많은 정보가 표시됩니다. 대부분의 사람들에게 이것은 기본 요구 사항보다 훨씬 높지만 실제로 시스템을 제어하고 문제를 해결하고 심지어 Microsoft가 핵심 버그를 수정하는 데 도움이 되는 경우 몇 분 동안 분석을 실행하고 충돌 보고서를 보낼 것입니다. , 가능하다면.

기호가 커널과 일치하지 않습니다!

자, 이것은 여러분이 주목해야 할 것입니다. 잘못된 기호를 로드하면 충돌에 대한 정보가 잘못됩니다. 실제로 커널 버전보다 이전이거나 최신인 기호를 다운로드한 경우 문제가 발생합니다.

이는 커널 업데이트 후 openSUSE 11.2의 리포지토리에서 debuginfo 패키지를 사용할 수 없는 Linux 예제와 유사합니다. 사실, 나는이 문제에 직면했습니다. 심볼 설치로 돌아가 봅시다:

기호는 커널 7600.16385용이며, 제가 잘못 생각한 것이 아니라면 RTM입니다. 타임스탬프와 정확한 수정 버전(090713-1255)을 확인하십시오. 반면에 Windows 7은 최신 커널을 실행하고 있으며 커널 버전에도 영향을 줄 수 있는 여러 업데이트를 거쳤습니다.

버전은 7600.16481입니다. 둘이 안맞아! 이와 같은 경우가 발생하고 최신 버전의 커널 기호를 다운로드할 수 없는 경우 Microsoft에 지원을 요청해야 합니다. 타사 드라이버에 대한 기호가 없을 가능성이 큽니다. 타사 공급업체에 문의할 수도 있습니다.

온라인에서 올바른 기호를 검색하세요!

이제 Windows 측면에서 운영 체제의 최신 기호를 얻기 위해 수행해야 할 작업은 다음과 같습니다. Windows 디버거에서 크래시 덤프를 로드한 후 기호 검색 경로 창을 다시 엽니다. 로컬 경로 외에도 디버거 내에서만 액세스할 수 있는 온라인 기호 저장소를 지정합니다. 자세한 내용은 이 Microsoft KB 문서를 참조하십시오.

구체적으로 다음을 원합니다.

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

c:\symbols를 시스템의 올바른 기호 경로로 바꿉니다. 경로는 기호 검색 경로를 사용하여 입력할 필요가 없습니다. .sympath 명령을 사용하여 명령줄에서 지정할 수도 있습니다. 곧 다른 디버거 명령과 옵션에 대해 논의할 것입니다. 그리고 분석을 다시 실행해 봅시다. 물론 Nirsoft 드라이버에 대한 기호는 없습니다.

더 재미있게 만들기 위해 다음은 호출 스택입니다(자세한 내용은 곧 설명).

그리고 우리는 좋다!

기타 디버거 명령 및 옵션

다행스럽게도 Windows 디버거에는 매우 풍부하고 자세한 도움말이 있어 이러한 종류의 작업을 좋아한다면 바로 시작할 수 있습니다. Linux 충돌 분석에 익숙하다면 대부분의 내용이 익숙할 것입니다.

예를 들어 매우 유용한 명령은 lm(모듈 나열)입니다. lml을 실행하여 짧은 모듈 목록을 가져오거나 lmv를 실행하여 완전하고 자세한 목록을 얻을 수 있습니다. u 플래그로 사용자 영역 모듈을 나열하거나 k 플래그로 커널 모듈을 나열할 수도 있습니다.

다음은 lvm의 예입니다.

다음은 lml의 예입니다. Windows 커널이 이러한 기호로 컴파일되지 않았거나 사용할 수 없기 때문에 일부 드라이버에는 기호, 즉 타사 드라이버가 없습니다. 판매처에서 받을 수 있습니다.

보기 메뉴에는 몇 가지 명령이 내장되어 있으므로 명령줄에서 찾을 필요가 없습니다. 조금 전에 본 Watch, Locals, Registers, Memory, Call Stack 등이 있습니다.

예를 들어 프로세스 및 스레드를 표시할 수 있습니다.

또는 레지스터:

사용할 수 있는 다른 명령으로는 !memusage 및 !address가 있습니다. 방금 본 명령과 옵션의 조합은 crash 유틸리티에서 사용하는 bt, ps 및 기타 명령과 매우 유사합니다. 전반적인 아이디어는 동일합니다.

분해

소스가 없더라도 바이너리 코딩된 디스어셈블을 보고 싶을 수 있습니다. 코드에서 진행되는 작업을 완전히 이해하지 못할 수도 있지만 무엇이 잘못되었는지 표시할 수 있습니다.

분해 옵션과 다른 많은 옵션을 메뉴에서 사용할 수 있습니다.

시작합니다:

그리고 다른 창을 기본 인터페이스에 내장할 수 있습니다.

이것은 Windows 디버거가 할 수 있는 일의 빙산에 거의 영향을 미치지 않지만 대부분의 사람들에게는 충분할 것 같습니다.

다음은 무엇입니까?

문제의 원인을 파악한 경우 다음과 같이 여러 가지를 시도할 수 있습니다.

불량 드라이버 제거 또는 비활성화

이것이 중요한 기능을 잃을 수 있으므로 차이가 있는지, 즉 가능하다면 확인하십시오. 문제가 지속되면 하드웨어와 관련된 복잡한 문제가 있을 수 있습니다.

드라이버를 업데이트해 보십시오.

작동할 수 있습니다. 공급업체 사이트 또는 Microsoft 업데이트로 이동하여 하드웨어 및 소프트웨어용 최신 드라이버를 구하십시오. 데이터를 백업하고 시스템을 이미지화하여 이동할 기준을 확보하십시오.

정보를 Google에서 검색

항상 현명한 움직임. 드라이버 이름이나 버그 확인 문자열을 찾으면 문제에 대한 해결 방법을 포함하여 유용한 정보를 얻을 수 있습니다. 일반적으로 누군가가 귀하의 문제와 유사한 것을 보거나 듣거나 경험했어야 합니다.

항상 그렇듯이 신중하고 신중하게 데이터를 필터링하십시오. 제안된 솔루션 중 일부를 시도하기로 결정한 경우 데이터가 안전한지, 잘 알려진 구성으로 롤백할 수 있는지 확인하십시오.

기타

유용한 충돌 정보가 있는 경우 분석을 위해 개발자에게 보내야 합니다. 이는 Microsoft 또는 Microsoft Windows용 하드웨어 또는 소프트웨어 드라이버를 개발하는 타사일 수 있습니다. 아래를 참조하십시오.

분석을 위해 커널 덤프 정보 제출

나는 여기에 단단한 것이 없습니다. 제안 사항이 있으면 보내주십시오. 여러 Microsoft 링크를 시도했지만 일반 사용자에게는 범위를 벗어난 것 같습니다.

가장 관련성이 높은 페이지는 oca.microsoft.com이지만 서버 쪽 오류가 있는 것 같습니다. 저를 수정하거나 피드백과 링크를 보내주십시오.

참고:크래시 덤프 전송은 민감한 문제입니다. 메모리 덤프에는 암호 및 충돌 시 메모리에 로드된 거의 모든 항목을 포함한 개인 정보가 포함될 수 있습니다. 충돌 데이터를 업로드하거나 메일로 보내기 전에 이 점에 유의하십시오.

추가 사항

메모리 진단

간헐적인 하드웨어 문제가 발생하는 경우 컴퓨터에서 메모리 테스트를 실행할 수 있습니다. 가장 인기 있는 오픈 소스 도구는 Memtest86+입니다. 이 도구는 독립 실행형 ISO로 사용할 수 있습니다. 또한 대부분의 Linux 배포판에 포함되어 있으며 모두 라이브 CD로 부팅할 수 있습니다.

Windows 메모리 진단을 사용할 수도 있습니다.

또한 Linux 충돌에 나열된 일반적인 조언도 여기에 적용됩니다!

그게 전부입니다, 여러분!

참조

드라이버 검증기

Windows 기호 패키지

Windows용 디버깅 도구

윈도우 SDK

후크래쉬

Nirsoft 웹사이트

Nirsoft Nirlauncher(내 리뷰)

Nirsoft BlueScreenView

Nirsoft StartBlueScreen

Windows 메모리 진단

멤테스트86+

온라인 기호 하우투

Windows 디버거 내에서 실시간으로 온라인 서버에서 기호 검색:

Microsoft Symbols Server를 사용하여 디버그 기호 파일 얻기

기타 유용한 리소스

커널 메모리 덤프 분석에 대한 Microsoft 문서:

레지스트리 조정, 키보드 사용 a-la 시스템 요청(SysRq), Windows 디버거의 명령줄 사용 및 배치(스크립팅된) 사용을 포함한 유용한 문서입니다.

메모리 덤프 파일 옵션 개요

키보드 덤프 트리거

Mark Russinovich(Sysinternals, 이제 Wininternals)의 훌륭한 기사:

통화가 두절된 사례

그리고 Windows 디버거에 내장된 도움말을 잊지 마세요! 매우 철저하고 상세합니다. 마지막으로 우리는 모든 상황에서 가장 친한 친구인 인터넷 검색 엔진으로 돌아갑니다.

결론

와우, 그것은 길었고 내가 예상했던 것보다 훨씬 괴짜였습니다. 분명히 커널 작업을 처리할 때 슈퍼 괴짜를 피할 수 없습니다. 그럼에도 불구하고 이 기사를 즐기셨기를 바랍니다.

여기에는 커널 메모리 덤프 설정, 드라이버 확인, 커널 충돌을 검사하기 위한 세 가지 도구, 강력한 Windows 디버거에 이르기까지 WhoCrashed와 같은 매우 간단한 도구 등 모든 것이 있습니다. 또한 Nirsoft 도구를 사용하여 BSOD를 트리거한 다음 분석했습니다. 기계에 기호가 설치되어 있는지 확인했습니다. 몇 가지 명령과 옵션을 포함하여 Windows 디버거가 제공하는 기능을 자세히 살펴보았습니다. 마지막으로 몇 가지 일반적인 팁과 풍부한 링크가 있습니다.

Windows 사용자의 이익과 즐거움을 위해 Linux 사용자가 작성한 기사가 아닌 이 기사만큼 친근한 기사를 많이 찾지 못할 것입니다. 그리고 거기에 비밀이 있습니다. 구문은 다르지만 기본 원칙은 동일합니다. Linux 또는 Windows 커널 충돌 분석에 익숙해지면 다른 쪽을 사용하는 것이 훨씬 더 편할 것입니다. 그리고 그것이 전부일 것입니다. 나는 보냈다. 주위에 당신을보고!

건배.