I received a nice memory dump from a customer running some DTM test at Vista (windbg analysis below). It seems my USB driver requested D0 IRP, received it in its power handler, set completion routine using IoSetCompletionRoutine() and passed it down. IO_REMOVE_LOCK was used to protect driver from premature unloading. Driver then received remove IRP, processed it and called IoReleaseRemoveLockAndWait(). So far so good. Then completion routine for D0 IRP was called which made its task and finally called IoReleaseRemoveLock(). Below BSOD followed. It seems blocked remove IRP handler was awaken and finished standard way which in turn caused device removal and driver unload. When completion routine continued, it crashed immediatelly. tcusb.sys + 0x2b33 is the first instruction after mentioned IoReleaseRemoveLock() call.
Is above scenario possible? It isn’t quite easy to analyze unloaded driver so I partially guess 
And WinDbg doesn’t make good job with symbols in this case… If so, does it mean I have to use IoSetCompletionRoutineEx() even for power IRPs? I was under impression it is necessary for only IRPs which driver allocates but if above is correct, it should be done for any IRP.
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS (ce)
A driver unloaded without cancelling timers, DPCs, worker threads, etc.
The broken driver’s name is displayed on the screen.
Arguments:
Arg1: 9f982b33, memory referenced
Arg2: 00000008, value 0 = read operation, 1 = write operation
Arg3: 9f982b33, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, Mm internal code.
Debugging Details:
WRITE_ADDRESS: 9f982b33
FAULTING_IP:
tcusb+2b33
9f982b33 ?? ???
DEFAULT_BUCKET_ID: VISTA_RC
BUGCHECK_STR: 0xCE
PROCESS_NAME: System
CURRENT_IRQL: 0
TRAP_FRAME: ab731c1c – (.trap ffffffffab731c1c)
ErrCode = 00000010
eax=00000000 ebx=865ec5e0 ecx=00000000 edx=00000000 esi=83cf674c edi=00000000
eip=9f982b33 esp=ab731c90 ebp=ab731c9c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
<unloaded_tcusb.sys>+0x2b33:
9f982b33 ?? ???
Resetting default scope
IP_MODULE_UNLOADED:
tcusb+2b33
9f982b33 ?? ???
LAST_CONTROL_TRANSFER: from 8188fa74 to 818a9ef2
STACK_TEXT:
ab731c04 8188fa74 00000008 9f982b33 00000000 nt!MmAccessFault+0x106
ab731c04 9f982b33 00000008 9f982b33 00000000 nt!KiTrap0E+0xdc
WARNING: Frame IP not in any known module. Following frames may be wrong.
ab731c8c 83cf6498 865ec5e0 00000000 ab731cbc <unloaded_tcusb.sys>+0x2b33
ab731cbc 818acb3b 83cf63e0 865ec5e0 83cf6498 0x83cf6498
ab731cf0 8ac6dd87 83d240e0 868e6fd0 77505353 nt!IopfCompleteRequest+0x13d
ab731d10 8ac517dc 83d24028 00000000 84642f18 usbhub!UsbhPdoSetD0+0x3c8
ab731d30 8198c882 83d24028 868e6fd0 867a7448 usbhub!UsbhHubWorker+0x50
ab731d44 81878e18 8380eab8 00000000 867a7448 nt!IopProcessWorkItem+0x23
ab731d7c 81a254a8 8380eab8 ab73a680 00000000 nt!ExpWorkerThread+0xfd
ab731dc0 8189145e 81878d1b 80000000 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: kb
FOLLOWUP_IP:
tcusb+2b33
9f982b33 ?? ???
SYMBOL_STACK_INDEX: 2
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: tcusb+2b33
MODULE_NAME: tcusb
IMAGE_NAME: tcusb.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: 0xCE_W_tcusb+2b33
BUCKET_ID: 0xCE_W_tcusb+2b33
Followup: MachineOwner
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]</unloaded_tcusb.sys></unloaded_tcusb.sys>