Учусь драйвера писать.
Накатан простенький .sys, который создает девайс и при вызове клиентом DeviceIoControl копирует в клиентский буфер, точнее, в
Irp->AssociatedIrp.SystemBuffer,
сообщение с полученным dwIoControlCode.
Все было весело, пока DeviceIoControl не была вызвана с контрол кодом 0x567. Процедура не вернула, система начала медленно терять сознание, а после закрытия клиента выпала в синьку.
При отладке под сайсом выяснилось, что именно при контрол коде 0x567 в Irp->AssociatedIrp.SystemBuffer оказывается NULL, даже если клиент передал валидный буфер.
Сильно подозреваю, что это какой-нибудь зарезервированный код, но информации по этому поводу не нахожу...

"Все было весело, пока DeviceIoControl не была вызвана с контрол кодом 0x567" - если вазвал ты, то проверь ControlCode. Разбири по битикам это поле и глянь какой тип : METHOD_ХХХ обмена данных указал. IOManager в соответствии с ними заполняет rp->AssociatedIrp.SystemBuffer и/или выделяет память. Возможно ошибка в этом.

буферизованный ввод-вывод (buffered I/O) - METHOD_BUFFERED

Four-F: -"Создавая IRP, при операции записи, диспетчер ввода-вывода копирует данные из пользовательского входного буфера в выделенный системный буфер и передает драйверу его адрес в поле AssociatedIrp.SystemBuffer структуры _IRP. Размер скопированных данных помещается в поле Parameters.DeviceIoControl.InputBufferLength структуры IO_STACK_LOCATION."

GetMethod(567h)=METHOD_NEITHER - похоже баг действительно тут. Должен быть METHOD_BUFFERED.

П.С. Если я всё правильно понял...

http://four-f.narod.ru/KmdKit16.zip

Там есть новая тулза - I/O Control Code Decoder. Она как раз для таких дел. Введи 00000567 и поймешь причину. В любом случае драйвер и его клиент должны действовать согласованно. А драйвер ещё и должен стараться защититься от неправильных действий своего клиента.

Вот оно что...

#define METHOD_BUFFERED 0
#define METHOD_IN_DIRECT 1
#define METHOD_OUT_DIRECT 2
#define METHOD_NEITHER 3

Спасибо большое! Впредь буду внимательнее читать доки...