Привет,

есть такой код

DriverEntry()
KeInitializeEvent(&DriverData.SyncEvent, NotificationEvent, FALSE);
...
DriverThread()
PVOID lEvents[] = { &Data->SyncEvent };
KeWaitForMultipleObjects(sizeof(lEvents) / sizeof(lEvents[0]), lEvents, ...);

...
DriverUnload()
KeSetEvent(&DriverData.SyncEvent, 0, FALSE);

Больше нигде этот эвент не используется. На нем ждет только ядреный поток.
Если драйвер просто загрузить и выгрузить — все отрабатывает идеально.
Если же драйвер выполняет какие-либо операции ВВ, то при попытке выгрузки получаю бсод. Но самое странное что при этом

kd> dt -r 0xF135A140 KEVENT
+0x008 WaitListHead : _LIST_ENTRY [ 0x21c07559 — 0x294a2d8e ]
+0x000 Flink : 0x21c07559 _LIST_ENTRY
+0x004 Blink : 0x294a2d8e _LIST_ENTRY

Тоесть мало того что присутствуют странные ожидальщики, так еще и адреса вообще указывают черт знает куда. Откуда это?
Не мудрено что следствием становится

FAULTING_IP:
nt!KeSetEvent+30
804f8fdc 66394616 cmp word ptr [esi+16h],ax

Похожая бага обсуждалась на OSR, но там человек использовал событие на стеке с IRP.

память для DriverData где выделена?

Здравствуйте, Аноним, Вы писали:

А>память для DriverData где выделена?
Единственный глобальный объект.
Тоже думал в эту сторону, но тогда неясно почему в остальных случаях работает нормально.
Еще были варианты, что ведомый поток сдох, но он таки жив.
Кстати, почему у некоторых системных потоков нормально отображает типы эвентов, а у некоторых пишет Unknown?

А>>память для DriverData где выделена?
pva>Единственный глобальный объект.
В paged или nonpaged памяти? (надо второй вариант, хотя не похоже на причину)
Есть возможность live дебага? Поставьте on-access бряку на адрес ивента с проверкой условия — на "корявость" адреса.

Здравствуйте, ononim, Вы писали:

O>Есть возможность live дебага? Поставьте on-access бряку на адрес ивента с проверкой условия — на "корявость" адреса.
Все оказалось банальней. Чуть выше был рабочий буфер маленького размера.