異步IRP的教訓(已附DUMP)

[教訓]異步IRP中，IoSetCompletionRoutine()要在IoCallDriver()的前面，否則底層驅動完成了讀寫以後，找不到完成例程，會致使出錯。看似簡單，不當心卻可能帶來大麻煩。

 

 [通過]修改驅動，須要把原來較大的IO切成小IO發給磁盤驅動，結果改完後一讀寫數據就藍屏，百思不得其解。折騰了很長時間以後，才發如今RwBuildIrpAndCallDriver()函數裏，IoSetCompletionRoutine()在IoCallDriver()的前面。遂作修改，調整順序，數據讀寫正常。

 

其實在DUMP文件中，經過對堆棧調用和崩潰位置的分析，應該能夠早點看出問題來。

 

下附DUMP分析：

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (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: 000000e8, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
	bit 0 : value 0 = read operation, 1 = write operation
	bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: 80a0da16, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS:  000000e8 

CURRENT_IRQL:  2

FAULTING_IP: 
hal!KeAcquireInStackQueuedSpinLock+26
80a0da16 8711            xchg    edx,dword ptr [ecx]

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  Idle

TRAP_FRAME:  8087924c -- (.trap 0xffffffff8087924c)
ErrCode = 00000002
eax=808792d4 ebx=00000000 ecx=000000e8 edx=808792d4 esi=00000000 edi=8a500c88
eip=80a0da16 esp=808792c0 ebp=808792e0 iopl=0         nv up ei pl nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010212
hal!KeAcquireInStackQueuedSpinLock+0x26:
80a0da16 8711            xchg    edx,dword ptr [ecx]  ds:0023:000000e8=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from 80a0da16 to 8086c6d0

STACK_TEXT:  
8087924c 80a0da16 badb0d00 808792d4 00000001 nt!KiTrap0E+0x238
808792c0 8082519e 8a500c88 8a500c48 00000000 hal!KeAcquireInStackQueuedSpinLock+0x26
808792e0 8081a518 8a500c88 00000000 00000000 nt!KeInsertQueueApc+0x20
80879314 ba108c70 80879344 ba108f54 8a797030 nt!IopfCompleteRequest+0x1d8
8087931c ba108f54 8a797030 8a500c48 00000001 CLASSPNP!ClassCompleteRequest+0x11
80879344 8081a3e2 00000000 87eed5d8 898ab488 CLASSPNP!TransferPktComplete+0x180
80879374 b9dfc8f8 8aac49e0 87eed5d8 808793b8 nt!IopfCompleteRequest+0xa2
80879384 b9dfc436 8a436d80 00000001 00000000 SCSIPORT!SpCompleteRequest+0x5e
808793b8 b9dfc6f7 8aac49e0 8a436d80 80879427 SCSIPORT!SpProcessCompletedRequest+0x632
80879428 8086de5f 8aac499c 8aac4928 00000000 SCSIPORT!ScsiPortCompletionDpc+0x2b5
80879450 8086dd44 00000000 0000000e 00000000 nt!KiRetireDpcList+0x61
80879454 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x28


STACK_COMMAND:  kb

FOLLOWUP_IP: 
CLASSPNP!ClassCompleteRequest+11
ba108c70 5d              pop     ebp

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  CLASSPNP!ClassCompleteRequest+11

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: CLASSPNP

IMAGE_NAME:  CLASSPNP.SYS

DEBUG_FLR_IMAGE_TIMESTAMP:  41107ec2

FAILURE_BUCKET_ID:  0xA_CLASSPNP!ClassCompleteRequest+11

BUCKET_ID:  0xA_CLASSPNP!ClassCompleteRequest+11

Followup: MachineOwner
---------