А>...но (если речь идет о простом TDI-фильтре) что значит зафейлить хендлер ClientEventChainedReceive()?

Проблема в том, что перехватить chained receive обработчик просто так не получится. Вот представим ситуацию: клиент регистрирует chain receive обрабочик, но не регистрирует обычный receive обработчик и не шлёт TDI_RECEIVE, т.е. ждёт, когда ему транспортный драйвер будет давать прямой доступ к буферам. Допустим, мы перехватили этот обработчик. Что мы делаем, когда нас позвали? Производим некую обработку согласно нашему алгоритму, после чего мы должны вызвать оригинальный обработчик клиента. Если бы мы ранее перехватили обычный receive обрабочик, мы могли бы передать эти данные ему, но клиент его не зарегистрировал и это его право, никто не обязывает его делать это. Итак, мы вызвали chain receive обработчик клиента, тот вернул STATUS_PENDING. Теперь мы не можем вернуть данные транспорту, т.к. по документации мы должны дождаться, когда клиент вызовет TdiReturnChainedReceives(). Чтобы это сделать, мы должны перехватить TdiReturnChainedReceives(), например, пропатчив EAT соответствующего драйвера, а это уже никак не укладывается в рамки обычного фильтра. Сделать это, конечно, можно, если сильно охота, но во-первых, такое поведение вряд ли обойдут вниманием всякие антивирусы/антируткиты, т.е. можно поиметь проблем с ними, а значит и с пользователями твоего продукта, во-вторых, я не уверен, что модификация EAT сетевых драйверов будет работать на 64-битных системах, я даже на 99% думаю, что не будет, вроде бы даже видел где-то замечание на эту тему, ссылки вот только нет под рукой. Так что этот метод связан с определёнными проблемами и проще всего с этим просто не связываться. Гораздо проще в данном случае тупо завершить set event handler запрос с кодом STATUS_NOT_SUPPORTED, ну т.е. установить pIrp -> IoStatus и вызвать IoCompleteRequest().