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

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

LK>>Так UNICODE_STRING я не просто так предлагаю, а для решения то самой проблемы.

O>UNICODE_STRING, vector или просто wchar_t — это не важно. Пока у тебя не будет синхронизации доступа к
O>этой переменной, работать твой драйвер корректно не будет.

LK>>Про verifier — спасибо, гляну. А что именно он дает, в 2 словах?

O>Verifier позволяет быстрее обнаруживать различные скрытые ошибки, которые в нормальных условиях обычно
O>не проявляются сразу или проявляются спустя долгое время, когда программа уже в релизе.

O>Ну например, ты обращаешься к paged-памяти на DISPATCH_LEVEL. В нормальных условиях это иногда
O>может работать месяцами и годами, не выпадая в BSOD, а затем вдруг начинает падать (как правило, в
O>самый неожиданный и неудачный момент).

O>Когда ты включаешь соответствующую проверку в Verifier, он принудительно сбрасывает paged-память на
O>диск при повышении IRQL, так что данная ошибка всплывает практически сразу.

O>Это лишь один из примеров.

Спасибо за verifier, а вот по синхронизации надо либо что-то делать, либо все-таки счесть данную архитектуру чем-то ужасным (пусть она и избитая в юзермоде, но здесь не та обстановка. Но правда если переделывать архитектуру, то мы получим гемор — делать службу не вариант, т.к. ее нет, совсем — гемор по ее созданию слишком большой. А если перенести логирование в минифильтры, то это гемор поменьше, но придется его оптимизировать по быстродействию, что ли, к тому же логирование создает файл — от рекурсии защищаться придется). Но и спинлоки как вариант "что-то делать" — не нравятся.