stop: 0x000000c2 (0x000000007, 0x00000b8a,...)
BAD_POOL_CALLER

Вот это вываливается на синем экране... Нашел в DDK описание "Attempt to free pool which was already freed", что означает - пытаюсь освободить пул, который уже освобожден. Все конечно понятно с пулом, но в моём драйвере нет выделения и освобождения пула.
Смысл работы драйвера - эмулировать новый HDD в системе, при этом просто подсовывать данные из файла-имиджа, считанного с дискеты.
Есть еще одна особенность, крах системы происходит только при многократном запуске и остановке драйвера, причем после остановки может пройти много времени и BSOD вываливается, например, при простом закрытии Explorer или при переключении между задачами. Процедура UnLoad
DriverUnload proc pDriverObject:PDRIVER_OBJECT
.if hDiskFile!=NULL
invoke ZwClose, hDiskFile
.endif
invoke IoDeleteSymbolicLink, addr SymbLinkName
mov eax, pDriverObject
assume eax:ptr DRIVER_OBJECT
invoke IoDeleteDevice, [eax].DeviceObject
assume eax:ptr nothing
ret
DriverUnload endp

Точно сказать невозможно. Причин может быть много. Например, ты аттачишься к имеющемуся девайсу, перехватываешь его IRP и устанавливаешь процедуру завершения (Completion Routine). К тебе приходит IRP, ты перенаправляешь его ниже по стеку и какой-то из драйверов ниже откладывает обработку этого IRP. Ты выгружаешь драйвер, но адрес процедуры завершения находится в теле драйвера, когда происходит завершение IRP система вызывает твою процедуру, но ее там уже нет. В твоем случае, судя по BAD_POOL_CALLER, проблема, наверное в другом. Но все равно может быть какая-то завязка с отложенными IRP. Или ты ассоиативный список не освободил или хрен знает еще что. По одному BSOD'у тут не разобраться. Включи в айсе трап на исключения faults on. Так на ещё живой системе можно посмотреть какой поток, состояние стека, жив ли твой драйвер и т.п. может за что-нить и зацепишься.

Немного разобрался, вся "засада" в broadcast сообщениях...
Когда система обнаруживает новый диск (юзал flash usb) по системе проходит сообщение uMsg = WM_DEVICECHANGE WParam = DBT_DEVICEARRIVAL (8000h) lParam = 12FEE4 на что окошки (не все) отвечают, очевидно OK! - broadcast сообщение uMsg = WM_DEVICECHANGE WParam = 7, LParam = 0
При отключении flash - uMsg = WM_DEVICECHANGE WParam = DBT_DEVICEREMOVECOMPLETE (8004h) lParam = 12FEE4, на что ответ идет uMsg = WM_DEVICECHANGE WParam = 7, LParam = 0
В моём приложении сообщения проходят немного не так (не в той последовательности) => не все системные модули получают уведомление об отключении устройства. И когда происходит время кому-нить обратиться к диску (например проверить его наличие) - BSOD
Но это пока только предположение :)

См. в KmdKit (на этом сайте) пример \examples\advanced\RamDisk\. Может поможет чем-нибудь.

Разобрался окончательно - "шальные ручки" до добра не доводят. Не удалил часть кода, в котором по esi записывается один DWORD, а это происходило в момент вызова диспетчера чтения => через определенное время, когда память очищалась системой - получал BSOD :(