[教训]异步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 ---------