1 / 41

WinDbg 를 이용한 커널 드라이버 디버깅 3. Dump Debugging

WinDbg 를 이용한 커널 드라이버 디버깅 3. Dump Debugging. KOREA SYSTEM PROGRAMMER 1 st System Kernel Conference 2003.11.8. 목차. BSOD Crash Dump File Bug Check 덤프분석 예. BSOD. Blue Screen of Death ( 죽음의 블루스크린 ) 커널레벨 오류발생 복구불능 분석정보표시 bugcheck 코드 오류드라이버 오류주소 덤프생성. BSOD. Crash Dump File. 메모리 덤프

jane
Télécharger la présentation

WinDbg 를 이용한 커널 드라이버 디버깅 3. Dump Debugging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WinDbg를 이용한 커널 드라이버 디버깅3. Dump Debugging KOREA SYSTEM PROGRAMMER 1st System Kernel Conference 2003.11.8

  2. 목차 • BSOD • Crash Dump File • Bug Check • 덤프분석 예

  3. BSOD • Blue Screen of Death ( 죽음의 블루스크린 ) • 커널레벨 오류발생 • 복구불능 • 분석정보표시 • bugcheck 코드 • 오류드라이버 • 오류주소 • 덤프생성

  4. BSOD

  5. Crash Dump File • 메모리 덤프 • 메모리를 그대로 파일로 생성 • .dmp로 생성, WinDbg로 분석가능 • 오류가 발생했을 때 생성됨 • 임의의 순간에 생성가능 • 전체 메모리 덤프(Complete Memory Dump) • 메모리(RAM) 크기와 같은 크기로 생성(2GB도 가능) • %SystemRoot%\Memory.dmp에 생성 • 다시 덤프가 발생하면 같은 파일에 덮어씀 • 부트드라이브의 페이징파일크기가 RAM보다 커야함

  6. Crash Dump File • 커널 메모리 덤프(Kernel Memory Dump) • 커널에서 사용된 메모리만 덤프파일로 생성 • 전체 메모리 덤프의 약 1/3 크기 • %SystemRoot%\Memory.dmp에 생성 • 작은 메모리 덤프(Small Memory Dump) 미니덤프, 64KB 크기로 생성 오류 코드, 파라미터 정보 포함 오류 프로세스, 쓰레드 정보 포함(not memory) 오류 쓰레드 콜스택 덤프, 로드된 드라이버 리스트 %SystemRoot%\Minidump\mini022900-01.dmp 디버깅 어려움

  7. C:\WINNT\memory.dmp (256MB) 메모리(256MB) User Memory C:\WINNT\memory.dmp (80MB) Kernel Memory C:\WINNT\Minidump\ Mini022900-01.dmp(64KB) Crash Dump File • 전체 메모리 덤프 • 커널 메모리 덤프 • 작은 메모리 덤프

  8. Crash Dump File • 덤프파일 종류 설정 • 내컴퓨터 – • 등록정보 – • 고급탭 – • “시작 및 복구” • * 페이징파일 • 크기설정 – • “성능옵션”

  9. Crash Dump File

  10. Bug Check • Bug Check Code • 미리 정의된 오류코드들 • 0x1~ 0xF9 • 원인분석의 실마리 제공 • Bug Check Parameter • 4개의 파라미터 • Bug Check Code 별로 추가 정보 제공 • WinDbg Help • Bug Check Code Reference • 코드, 파라미터, 분석방법 설명

  11. Bug Check ********************************************************* * * Bugcheck Analysis * ********************************************************* Use !analyze -v to get detailed debugging information. BugCheck C4, {60, 0, 10, 2} Probably caused by : MyDrv.sys Followup: MachineOwner ---------

  12. Bug Check 0x50 • Bug Check 0x50: PAGE_FAULT_IN_NONPAGED_AREA • Arg1: fffffff0, memory referenced. • Arg2: 00000001, value 0 = read, 1 = write • Arg3: f9dac3fe, the instruction address which referenced the bad memory address. • Arg4: 00000000, (reserved) • 유효하지 않은 시스템주소를 참조한 경우 • 하드웨어 오류

  13. Bug Check 0x50 kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except, it must be protected by a Probe. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: fffffff0, memory referenced. Arg2: 00000001, value 0 = read operation, 1 = write operation. Arg3: f9dac3fe, If non-zero, the instruction address which referenced the bad memory address. Arg4: 00000000, (reserved) Debugging Details: ------------------

  14. Bug Check 0x50 kd> kv ChildEBP RetAddr Args to Child f252e7bc 804f076e ... nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0]) f252e808 804f102a ... nt!KiBugCheckDebugBreak+0x19 (FPO: [Non-Fpo]) f252ebd0 804f14c9 ... nt!KeBugCheck2+0x43c (FPO: [Non-Fpo]) f252ebf0 8050ed3d ... nt!KeBugCheckEx+0x19 (FPO: [Non-Fpo]) f252ec3c 8052cfd0 ... nt!MmAccessFault+0x6cb (FPO: [Non-Fpo]) f252ec3c f9dac3fe ... nt!KiTrap0E+0xb8 (FPO: [0,0] TrapFrame @ f252ec54) f252eccc f9dace7a ... MyDrv!BugCheck50+0xe (FPO: [Non-Fpo]) (CONV: stdcall) [d:\project\test\mydrv\mydrv.c @ 278] f252fc10 804e8185 ... MyDrv!MyDrvDeviceControl+0x2ea (FPO: [Non-Fpo]) (CONV: stdcall) [d:\project\test\mydrv\mydrv.c @ 450] void BugCheck50(void) { PCHAR p = (PCHAR)0xfffffff0; *p = 0; // LINE 278 }

  15. Bug Check 0x8E • Bug Check 0x8E: KERNEL_MODE_EXCEPTION_NOT_HANDLED • Arg1: c0000005, The exception code that was not handled • Arg2: f9dbe4ab, The address that the exception occurred at • Arg3: bad4ac3c, Trap Frame • Arg4: 00000000 • 커널모드에서 exception이 발생한 경우

  16. Bug Check 0x8E kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, ... Arguments: Arg1: c0000005, The exception code that was not handled Arg2: f9dbe4ab, The address that the exception occurred at Arg3: bad4ac3c, Trap Frame Arg4: 00000000 Debugging Details:

  17. Bug Check 0x8E TRAP_FRAME: bad4ac3c -- (.trap ffffffffbad4ac3c) ErrCode = 00000000 eax=00000000 ebx=89f00f00 ecx=bad4acc0 edx=bad4acc0 esi=810c9930 edi=8119cf18 eip=f9dbe4ab esp=bad4acb0 ebp=bad4acc8 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282 MyDrv!BugCheck8E+1b: f9dbe4ab 8a08 mov cl,[eax] kd> .trap bad4ac3c ErrCode = 00000000 eax=00000000 ebx=89f00f00 ecx=bad4acc0 edx=bad4acc0 esi=810c9930 edi=8119cf18 eip=f9dbe4ab esp=bad4acb0 ebp=bad4acc8 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282 MyDrv!BugCheck8E+1b: f9dbe4ab 8a08 mov cl,[eax]

  18. Bug Check 0x8E ChildEBP RetAddr Args to Child f275f3dc 804f076e ... nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0]) f275f428 804f102a ... nt!KiBugCheckDebugBreak+0x19 (FPO: [Non-Fpo]) f275f7f0 804f14c9 ... nt!KeBugCheck2+0x43c (FPO: [Non-Fpo]) f275f810 804f4fd5 ... nt!KeBugCheckEx+0x19 (FPO: [Non-Fpo]) f275fbcc 8052ae25 ... nt!KiDispatchException+0x307 (FPO: [Non-Fpo]) f275fc34 8052add6 ... nt!CommonDispatchException+0x4d (FPO: [0,20,0]) f275fcc8 f9d1eeb8 ... nt!Kei386EoiHelper+0x18e f2760c10 804e8185 ... MyDrv!MyDrvDeviceControl(_DEVICE_OBJECT* pDeviceObject = 80dff8c0 , _IRP* pIrp = 96cc0f68 )+0x328 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\project\test\mydrv\mydrv.c @ 467] f2760c20 80626d10 ... nt!IopfCallDriver+0x31 (FPO: [0,0,1]) case MYDRV_IOCTL_BUGCHECK_0x8E: BugCheck8E( NULL ); pIrp -> IoStatus.Status = STATUS_SUCCESS; pIrp -> IoStatus.Information = 0; break;

  19. Bug Check 0x8E kd> kv ChildEBP RetAddr Args to Child f275fcc8 f9d1eeb8 ... MyDrv!BugCheck8E+0x1b (FPO: [Non-Fpo]) (CONV: stdcall) [d:\project\test\mydrv\mydrv.c @ 306] f2760c10 804e8185 ... MyDrv!MyDrvDeviceControl+0x328 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\project\test\mydrv\mydrv.c @ 467] f2760c20 80626d10 ... nt!IopfCallDriver+0x31 (FPO: [0,0,1]) f2760c44 8055887c ... nt!IovCallDriver+0x9e (FPO: [Non-Fpo]) void BugCheck8E(PCHAR p) { char szBuf[8]; strcpy( szBuf, p ); // LINE 306 }

  20. Bug Check 0x8E kd> u MyDrv!BugCheck8E MyDrv!BugCheck8E [d:\project\test\mydrv\mydrv.c @ 303]: f9dbe490 55 push ebp f9dbe491 8bec mov ebp,esp f9dbe493 83ec18 sub esp,0x18 f9dbe496 8b4508 mov eax,[ebp+0x8] f9dbe499 8945f4 mov [ebp-0xc],eax f9dbe49c 8d4df8 lea ecx,[ebp-0x8] … f9dbe4a8 8b45f4 mov eax,[ebp-0xc] f9dbe4ab 8a08 mov cl,[eax] ; eax = 0

  21. Bug Check 0x7F • Bug Check 0x7F: UNEXPECTED_KERNEL_MODE_TRAP • Arg1: 00000008, EXCEPTION_DOUBLE_FAULT • Arg2~4 : 0 • 커널스택 오버플로우가 발생한 경우 • Arg1: 00000000, Divide by Zero Error • Arg1: 00000005, Bounds Check Fault • Arg1: 00000006, Invalid Opcode

  22. Bug Check 0x7F kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* UNEXPECTED_KERNEL_MODE_TRAP (7f) This means a trap occurred in kernel mode, and it's a trap of a kind that the kernel isn't allowed to have/catch (bound trap) or that is always instant death (double fault). … Arguments: Arg1: 00000008, EXCEPTION_DOUBLE_FAULT Arg2: 00000000 Arg3: 00000000 Arg4: 00000000 Debugging Details: ------------------

  23. Bug Check 0x7F STACK_TEXT: f784528c fc8ac93a nt!ExRaiseStatus+0x7c f784529c fc8f78f0 Ntfs!NtfsRaiseStatus+0x65 f78455a4 fc8caa46 Ntfs!NtfsCommonCreate+0x489 f7845644 8041f79f Ntfs!NtfsFsdCreate+0x157 f7845658 f819ac53 nt!IopfCallDriver+0x35 WARNING: Stack unwind information not available. Following frames may be wrong. f784577c f819adc2 FilDrv+0x2c53 f784578c 8041f79f FilDrv+0x2dc2 f78457a0 f06c1441 nt!IopfCallDriver+0x35 f78457c0 f06c074a v3filter+0x1441 f78457d0 8041f79f v3filter+0x74a f78457e4 8049b252 nt!IopfCallDriver+0x35 f784596c 8045110c nt!IopParseDevice+0xa04 f78459dc 804a412d nt!ObpLookupObjectName+0x4db f7845aec 804960c1 nt!ObOpenObjectByName+0xc5 f7845bc0 80497dcd nt!IoCreateFile+0x3ec f7845c00 80465091 nt!NtCreateFile+0x2e f7845c00 80400a11 nt!KiSystemService+0xc4

  24. Bug Check 0x7F f7845ca4 f819c56f nt!ZwCreateFile+0xb f7845e1c f819d8f1 FilDrv+0x456f f7846670 f819f63d FilDrv+0x58f1 f7846d7c f819aba4 FilDrv+0x763d f7846eb8 f819adc2 FilDrv+0x2ba4 f7846ec8 8041f79f FilDrv+0x2dc2 f7846edc f06c1441 nt!IopfCallDriver+0x35 f7846efc f06c074a v3filter+0x1441 f7846f0c 8041f79f v3filter+0x74a f7846f20 8049b252 nt!IopfCallDriver+0x35 f78470a8 8045110c nt!IopParseDevice+0xa04 f7847118 804a412d nt!ObpLookupObjectName+0x4db f7847228 804960c1 nt!ObOpenObjectByName+0xc5 f78472fc 80497dcd nt!IoCreateFile+0x3ec f784733c 80465091 nt!NtCreateFile+0x2e f784733c 80400a11 nt!KiSystemService+0xc4 FilDrv F7846EC8 - F7845CA4 = 0x1224 ( 4644 )

  25. Bug Check 0x7F f78473e0 f7b4f4ac nt!ZwCreateFile+0xb f7847454 f7b5daa4 v3engine+0x10c f784746c f7b5dbde v3engine+0x294 f784758c f7b4fd09 v3engine+0x12e f7847598 f06c2194 v3engine+0x75e f7847864 f06c1236 v3filter+0x2194 f78478c4 f06c13c8 v3filter+0x1236 f78478f0 f06c074a v3filter+0x13c8 f7847900 8041f79f v3filter+0x74a f7847914 8049b252 nt!IopfCallDriver+0x35 f7847a9c 8045110c nt!IopParseDevice+0xa04 f7847b0c 804a412d nt!ObpLookupObjectName+0x4db f7847c1c 804960c1 nt!ObOpenObjectByName+0xc5 f7847cf0 80497dcd nt!IoCreateFile+0x3ec f7847d30 80465091 nt!NtCreateFile+0x2e f7847d30 77f881e3 nt!KiSystemService+0xc4 0012c778 77e6c3ac ntdll!NtCreateFile+0xb V3engine + v3filter F7847900 - F78473E0 = 0x520 ( 1312 ) Stack Area : 12KB F7848000 ~ F7845000

  26. Bug Check 0xC4 • Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION Arg1: 00000060, A driver has forgotten to free its pool allocations prior to unloading. Arg2: 00000000, paged bytes Arg3: 00000010, nonpaged bytes, Arg4: 00000002, total # of (paged+nonpaged) allocations that weren't freed. • Arg1: 60, 메모리릭 감지

  27. Bug Check 0xC4 kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_VERIFIER_DETECTED_VIOLATION (c4) A device driver attempting to corrupt the system has been caught. This is because the driver was specified in the registry as being suspect (by the administrator) and the kernel has enabled substantial checking of this driver. Arg1: 00000060, A driver has forgotten to free its pool allocations prior to unloading. Arg2: 00000000, paged bytes Arg3: 00000010, nonpaged bytes, Arg4: 00000002, total # of (paged+nonpaged) allocations that weren't freed. To get the name of the driver at fault, type dp ViBadDriver l1; dS @$p Then type !verifier 3 drivername.sys for info on the allocations that were leaked that caused the bugcheck. Debugging Details:

  28. Bug Check 0xC4 kd> !verifier 3 mydrv.sys Verify Level 79 ... enabled options are: special pool all pool allocations checked on unload … Summary of All Verifier Statistics RaiseIrqls 0x0 AcquireSpinLocks 0x0 Synch Executions 0x0 Trims 0x0 Pool Allocations Attempted 0x2 Pool Allocations Succeeded 0x2 Pool Allocations Succeeded SpecialPool 0x2 Pool Allocations With NO TAG 0x0 Pool Allocations Failed 0x0 Resource Allocations Failed Deliberately 0x0

  29. Bug Check 0xC4 Current paged pool allocations 0x0 for 00000000 bytes Peak paged pool allocations 0x0 for 00000000 bytes Current nonpaged pool allocations 0x2 for 00000010 bytes Peak nonpaged pool allocations 0x2 for 00000010 bytes Driver Verification List Entry State NonPagedPool PagedPool Module 81581f08 Loaded 00000010 00000000 MyDrv.sys Current Pool Allocations 00000000 00000002 Current Pool Bytes 00000000 00000010 Peak Pool Allocations 00000000 00000002 Peak Pool Bytes 00000000 00000010 PoolAddress SizeInBytes Tag CallersAddress ba568ff8 0x00000008 Ddk f9d4450b 819c6ff8 0x00000008 Ddk f9d4450b

  30. Bug Check 0xC4 kd> db ba568ff8 ba568ff8 46 69 6e 64 20 4d 65 00-?? ?? ?? ?? ?? ?? ?? ?? Find Me.???????? ba569008 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? kd> db 819c6ff8 819c6ff8 46 69 6e 64 20 4d 65 00-?? ?? ?? ?? ?? ?? ?? ?? Find Me.???????? 819c7008 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? kd> u f9d4450b MyDrv!BugCheckC4+13 [d:\project\test\mydrv\mydrv.c @ 315]: f9d4450b 8945fc mov [ebp-0x4],eax f9d4450e 8b45fc mov eax,[ebp-0x4] void BugCheckC4(void) { PCHAR p = (PCHAR)ExAllocatePool( NonPagedPool, 8 ); // LINE 315 strcpy( p, "Find Me" ); }

  31. Bug Check 0xD6 • Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION Arg1: 9fbcf000, memory referenced Arg2: 00000001, value 0 = read, 1 = write Arg3: f9dd0549, if non-zero, the address which referenced memory. Arg4: 00000000, (reserved) • 할당된 메모리 범위를 넘어서 사용할 경우

  32. Bug Check 0xD6 kd> !analyze -v ******************************************************************************* * Bugcheck Analysis * ******************************************************************************* DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION (d6) N bytes of memory was allocated and more than N bytes are being referenced. This cannot be protected by try-except. When possible, the guilty driver's name (Unicode string) is printed on the bugcheck screen and saved in KiBugCheckDriver. Arguments: Arg1: 9fbcf000, memory referenced Arg2: 00000001, value 0 = read operation, 1 = write operation Arg3: f9dd0549, if non-zero, the address which referenced memory. Arg4: 00000000, (reserved) Debugging Details: ------------------

  33. Bug Check 0xD6 ChildEBP RetAddr Args to Child bad327bc 804f076e nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0]) bad32808 804f102a nt!KiBugCheckDebugBreak+0x19 (FPO: [Non-Fpo]) bad32bd0 804f14c9 nt!KeBugCheck2+0x43c (FPO: [Non-Fpo]) bad32bf0 8050ed3d nt!KeBugCheckEx+0x19 (FPO: [Non-Fpo]) bad32c3c 8052cfd0 nt!MmAccessFault+0x6cb (FPO: [Non-Fpo]) bad32c3c f9dd0549 nt!KiTrap0E+0xb8 (FPO: [0,0] TrapFrame @ bad32c54) bad32ccc f9dd0f09 MyDrv!BugCheckD6( void )+0x19 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\project\test\mydrv\mydrv.c @ 324] bad33c10 804e8185 MyDrv!MyDrvDeviceControl(_DEVICE_OBJECT* pDeviceObject = 81155f18 , _IRP* pIrp = 9fbccf68 )+0x379 (FPO: [Non-Fpo]) (CONV: stdcall) [d:\project\test\mydrv\mydrv.c @ 488] bad33c20 80626d10 nt!IopfCallDriver+0x31 (FPO: [0,0,1]) void BugCheckD6(void) { PCHAR p = (PCHAR)ExAllocatePool( NonPagedPool, 8 ); p[8] = 0; // LINE 324 ExFreePool( p ); }

  34. Bug Check 0xA • Bug Check 0xA: IRQL_NOT_LESS_OR_EQUAL • Arg1: 00000016, memory referenced • Arg2: 00000002, IRQL • Arg3: 00000000, value 0 = read, 1 = write • Arg4: 804f84dd, address which referenced memory • IRQL이 높을 때 수행할 수 없는 함수를 수행 • IRQL이 높을 때 잘못된 메모리를 참조 • 메모리가 깨진 경우

  35. Bug Check 0xA kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pagable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 00000016, memory referenced Arg2: 00000002, IRQL Arg3: 00000000, value 0 = read operation, 1 = write operation Arg4: 804f84dd, address which referenced memory Debugging Details: ------------------

  36. Bug Check 0xA kd> kv ChildEBP RetAddr Args to Child f24067c8 804f076e … nt!RtlpBreakWithStatusInstruction (FPO: [1,0,0]) f2406814 804f102a … nt!KiBugCheckDebugBreak+0x19 (FPO: [Non-Fpo]) f2406bdc 804f14c9 … nt!KeBugCheck2+0x43c (FPO: [Non-Fpo]) f2406bfc 8052d1c5 … nt!KeBugCheckEx+0x19 (FPO: [Non-Fpo]) f2406bfc 804f84dd … nt!KiTrap0E+0x2ad (FPO: [0,0] TrapFrame @ f2406c18) f2406ca8 804f17a0 … nt!KiWaitTest+0x31 (FPO: [Non-Fpo]) f2406cb8 f9d263e2 … nt!KeSetEvent+0x56 (FPO: [3,0,3]) f2406ccc f9d26e57 … MyDrv!BugCheckA+0x12 (FPO: [Non-Fpo]) (CONV: stdcall) f2407c10 804e8185 … MyDrv!MyDrvDeviceControl+0x2c7 (FPO: [Non-Fpo]) (CONV: kd> .trap f2406c18 ErrCode = 00000000 eax=00000000 ebx=f9d266a8 ecx=f2406c98 edx=00000000 esi=f9d266a0 edi=00000000 eip=804f84dd esp=f2406c8c ebp=f2406ca8 iopl=0 nv up ei pl nz ac pe cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010213 nt!KiWaitTest+31: 804f84dd 6683781601 cmp word ptr [eax+0x16],0x1

  37. Bug Check 0xA KEVENT event; void BugCheckA(void) { KeSetEvent( &event, IO_NO_INCREMENT, FALSE ); // 왜 죽었을까??? } nt!KiWaitTest: 804f84ac 55 push ebp 804f84ad 8bec mov ebp,esp 804f84af 83ec10 sub esp,0x10 804f84b2 53 push ebx 804f84b3 56 push esi 804f84b4 8bf1 mov esi,ecx ... 804f84c0 8d5e08 lea ebx,[esi+0x8] 804f84c3 8b03 mov eax,[ebx] ... 804f84dd 6683781601 cmp word ptr [eax+0x16],0x1 ; eax = 0

  38. Bug Check 0xA nt!KeSetEvent: 804f174a 53 push ebx 804f174b 56 push esi 804f174c 57 push edi 804f174d ff1594264d80 call dword ptr [nt!_imp__KeRaiseIrqlToDpcLevel (804d2694)] 804f1753 8b4c2410 mov ecx,[esp+0x10] ... 804f1771 803900 cmp byte ptr [ecx],0x0 804f1774 741a jz nt!KeSetEvent+0x46 (804f1790) ... 804f1780 8b4e08 mov ecx,[esi+0x8] ... 804f1789 e8d66b0000 call nt!KiUnwaitThread (804f8364) 804f178e eb10 jmp nt!KeSetEvent+0x56 (804f17a0) 804f1790 85ff test edi,edi 804f1792 750c jnz nt!KeSetEvent+0x56 (804f17a0) 804f1794 8b542414 mov edx,[esp+0x14] 804f1798 894104 mov [ecx+0x4],eax 804f179b e80c6d0000 call nt!KiWaitTest (804f84ac) 804f17a0 8a4c2418 mov cl,[esp+0x18]

  39. Bug Check 0xA kd> u mydrv!BugCheckA MyDrv!BugCheckA [d:\project\test\mydrv\mydrv.c @ 270]: … f9d263d3 6a00 push 0x0 f9d263d5 6a00 push 0x0 f9d263d7 68a066d2f9 push 0xf9d266a0 f9d263dc ff15b865d2f9 call dword ptr [MyDrv!_imp__KeSetEvent (f9d265b8)] kd> dt KEVENT f9d266a0 -b +0x000 Header : +0x000 Type : 0 '' +0x001 Absolute : 0 '' +0x002 Size : 0 '' +0x003 Inserted : 0 '' +0x004 SignalState : 1 +0x008 WaitListHead : [ 0x0 - 0x0 ] +0x000 Flink : (null) +0x004 Blink : (null)

  40. 참고문헌 • WinDbg Help • Inside Windows 2000 • The NT Insider (OSR) • Debugging Applications

  41. Q & A

More Related