Зависание системы при вызове моей функции из обработчика WFP

Windows 7 x64. В функции-обработчике classifyFn0 я вызываю функцию такого вида:

Код (Text):

1. NTSTATUS TMLogWriteRecord(IN PTM_LOG_RECORD Record)
2. {
3.     KIRQL oldIrql;
4.     NTSTATUS status;
5.  
6.     KeAcquireSpinLock(&gLock, &oldIrql);
7.     try {
8.         status = FifoWrite(Record, Record->Length);
9.     } except( EXCEPTION_EXECUTE_HANDLER ) {
10.     }
11.     KeReleaseSpinLock(&gLock, oldIrql);
12.     return status;
13. }

Где FifoWrite записывает в невыгружаемую память структуру, длина которой определена ее первым членом. Эта структура заполняется в самом обработчике и как временная переменная хранится в стеке.

Зависание системы происходит в самой функции FifoWrite если в ней используются данные какого либо параметра. Если функцию FifoWrite сделать пустой, то зависания не происходит.
Зависание происходит, например, при следующей реализации функции FifoWrite

Код (Text):

1. NTSTATUS FifoWrite(IN PVOID SourceData, IN ULONG Size)
2. {
3.     ULONG Size_ = Size;
4.  
5.     return STATUS_SUCCESS;
6. }

Подобных проблем не возникало в Windows XP x86 при использовании Firewall-Hook.

Как вы думаете с чем может быть связана данная проблема?

ЗЫ: Возможно данная тема уже была, я такую к сожалению не нашел.

 

Интересно, а как именно виснет? На какой инструкции? И что видно при этом в отладчике?

 

Я отлаживаю данный код методом тыка. По принципу повисло не повисло. К сожалению ошибка воспроизводится далеко не всегда, иногда сразу, а иногда через сотню повторений. Не возникает и BSOD, а потому креш дамп не формируется.

Причем проблема возникает только при использовании WFP в classifyFn0, хотя функция TMLogWriteRecord вызывается и из других мест, но зависаний там не происходит.

Единственно, что приходит на ум так только то что classifyFn0 может вызываться на уровне выше чем DISPATCH_LEVEL, то есть на уровне DIRQL. Неужели это возможно? Если да, то с каким объектами синхронизации лучше работать?

 

Не думаю, что отладка такой странной проблемы возможна с помощью метода тыка. Может, конечно, кто-нибудь определит в чем дело по приведенному коду, но лучше все же использовать отладчик.

С WFP не работал, но сомневаюсь, что она вызывается выше, чем на DISPATCH_LEVEL. Все-таки это не обработчик прерывания.

P.S. Проблема, конечно, не в этом, но лучше все же использовать __try/__except вместо try/except, чтобы избежать казусов.

 

для анализа hang/deadlock крешдамп не нужен

 

Проблема оказалась в неправильном копировании IPv6 адреса, в результате нарушался стек.

Спасибо за ответы в теме.