Сообщение Re[6]: Как синхронизировать PFLT_POST_OPERATION_CALLBACK и п от 14.09.2018 9:44
Изменено 14.09.2018 10:13 LimyKurn
Re[6]: Как синхронизировать PFLT_POST_OPERATION_CALLBACK и п
Здравствуйте, 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, а вот по синхронизации надо либо что-то делать, либо все-таки счесть данную архитектуру чем-то ужасным (пусть она и избитая в юзермоде, но здесь не та обстановка). И спинлоки как вариант "что-то делать" — не нравятся.
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, а вот по синхронизации надо либо что-то делать, либо все-таки счесть данную архитектуру чем-то ужасным (пусть она и избитая в юзермоде, но здесь не та обстановка). И спинлоки как вариант "что-то делать" — не нравятся.
Re[6]: Как синхронизировать PFLT_POST_OPERATION_CALLBACK и п
Здравствуйте, 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, а вот по синхронизации надо либо что-то делать, либо все-таки счесть данную архитектуру чем-то ужасным (пусть она и избитая в юзермоде, но здесь не та обстановка. Но правда если переделывать архитектуру, то мы получим гемор — делать службу не вариант, т.к. ее нет, совсем — гемор по ее созданию слишком большой. А если перенести логирование в минифильтры, то это гемор поменьше, но придется его оптимизировать по быстродействию, что ли, к тому же логирование создает файл — от рекурсии защищаться придется). Но и спинлоки как вариант "что-то делать" — не нравятся.
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, а вот по синхронизации надо либо что-то делать, либо все-таки счесть данную архитектуру чем-то ужасным (пусть она и избитая в юзермоде, но здесь не та обстановка. Но правда если переделывать архитектуру, то мы получим гемор — делать службу не вариант, т.к. ее нет, совсем — гемор по ее созданию слишком большой. А если перенести логирование в минифильтры, то это гемор поменьше, но придется его оптимизировать по быстродействию, что ли, к тому же логирование создает файл — от рекурсии защищаться придется). Но и спинлоки как вариант "что-то делать" — не нравятся.