2012-07-02 2 views
0

개발중인 드라이버 중 하나가 BSOD를 발생 시켰습니다. 불행히도 덤프 파일은 구성되지 않았기 때문에 생성되지 않았습니다/리소스가 부족합니다. 나는이 충돌을 재현하려고 시도했지만 지금까지는 운이 없다.덤프없는 BSOD 분석

WinDbg 또는 다른 도구를 사용하여 정보를 얻을 수있는 방법이 있습니까? BSOD

  • .SYS 파일의

    • 스크린 샷 : 는이 정보를 가지고있다.
    • 그것의 PDB
    • 소스 코드
    • 그것이 내가 덤프 자체를 제외한 모든이

    에 추락 한 기계.

    귀하의 도움을 많이 주시면 감사하겠습니다.


    위에서 말한 것처럼 덤프 (/ 미니 덤프)는 없습니다. 이것이 실제 문제입니다.

    이 특정 충돌의 경우 스택을 가져올 수 없다는 것을 알고 있습니다. 특정 코드 행을 얻는 것만으로도 충분합니다. BSOD는 모듈의 주소를 포함하고 있기 때문에 정확하게 어떤 줄을 발견 할 수있는 방법이있는 것처럼 보입니다. 위에서 언급했듯이 .sys 파일, pdb 및 소스 코드가 있습니다.

    이것은 MSDN : SYSTEM_SERVICE_EXCEPTION에서 가져온 특정 코드입니다. 특정 줄이 무엇인지 어떻게 알 수 있습니까? 및/또는 특정 예외가 제기 되었습니까?

  • +0

    나는 SYSTEM_SERVICE_EXCEPTION을 알고 있다고 생각합니다. 이 예외의 매개 변수 2와 3은 당신에게 더 많은 정보 라인, 함수, 주소를 줄 것이다. 또한 이것은 간접적 인 충돌 (일부 시스템 서비스 충돌)으로 보이므로 이러한 문제를 분석하기 위해 메모리 덤프가 필요합니다. – Rohan

    +0

    매개 변수 2와 3에서 정보 라인, 기능, 주소를 알려 주셨습니다. 그게 정확히 내 질문이야. 어떻게 쓸 수 있니? – eeoo2555

    +0

    예외 레코드 및 컨텍스트 레코드의 경우 __memory address__입니다. 그래서 그들을 사용하려면 덤프가 필요합니다. 또한 실제로는 주소/행 번호가 아니라 정보가있는 일부 레코드/정보에 대한 포인터입니다. BTW, BSOD 스크린에서 소스 코드 라인을 얻을 수 없다. – Rohan

    답변

    1

    충돌 주소가 있습니다. 소스 행을 알고 싶습니까?

    kd 또는 windbg를 시작하고 그 앞에 주소와 코드를 재촉하십시오. 함수 진입 점 (스택을 조정하는 위치)을 찾고 이제 심볼 테이블을 조회 할 수 있습니다. 그곳에서 다시 재앙을 벌이고 근원을 비교하십시오.

    죄송합니다. 일부 asm을 읽을 필요가 있습니다. 나는 더 좋은 방법을 안다.

    +0

    좋은 생각입니다. 컴파일러는 생성 된 어셈블리와 인터리브 된 주석으로 소스 코드가있는 어셈블리 파일 (텍스트 파일)을 생성하는 옵션을 가질 수도 있습니다. 텍스트 brough에서 원시 명령어 바이트를 검색하면 충돌이 거의 발생하지 않으며 충돌 상황에서 소스 라인을 찾을 수 있습니다. – ixe013

    +0

    답변 해 주셔서 감사합니다. 이것은 실제로 내가 한 일입니다. .sys 파일을 WinDbg에서 크래시 덤프로 연 다음 ** "u! my_driver + offset"**을 사용했습니다. 이것은 정확한 충돌을 일으켰습니다. 디스 어셈블리 창을 보면 소스 코드에서 정확한 라인을 찾을 수있는 코드의 전체 그림을 볼 수 있습니다. 감사. – eeoo2555

    0

    C:\windows에 미니 덤프가 있기 때문에 거기에 있는지 확인하십시오. 사용 가능한 경우 Windbg에서 열고 분석하십시오. 덤프를 생성하기 위해 낮은 리소스를 구성 할 필요가 없습니다.이 링크 http://support.microsoft.com/kb/254649에서 덤프 파일을 만들 때 창을 설정하는 방법을 참조하십시오. 드라이버를 디버그하려면 전체 덤프를 만드십시오.

    문제를 분석하기 위해 다시 질문에 오는 :

    하지만 당신이 가지고있는 정보로 좋은 결론에 도달하지는 않을 것입니다. 문제를 제대로 이해하려면 덤프 파일이 필요합니다.