Ну тобто драйвер для фізичного девайсу, так? Так, в такому випадку доведеться розгортати оточення за допомогою додаткової тестової фізичної машини та підключатися, дебажити з іншої машини. Я маю на увазі, що так, що так, Driver Verifier викине ексепшн і ми будемо мати змогу одразу його проаналізувтаи

Так, можна і до віртуальної машини під’єднатися, наприклад. Але Driver Verifier все одно викиlf’ BSOD у випадку помилки. Просто ми будемо одразу мати доступ до дампу пам’яті через WinDBG і будемо мати змогу дослідити цей BSOD.

дуже дякую! :)

Ого! Не очікувала бути Колумбом в сфері Windows Driver Development на DOU :D

Так, потреба в написанні власних Kernel Drivers часто виникає через потребу в забезпеченні секьюрності. Наприклад, розробка сендбоксів, фалових систем, в тому числі і мережевих. Чи якесь ПЗ для контролю і моніторингу девайсів, дій в файловій системі і тд. Так, такі драйвери часто пишуться з використанням вже існуючих бібліотек, на базі «рідних» низькорівневих драйверів. Проте, наш власний драйвер все одно при цьому буде в kernel mode, оскільки нам потрібно перехоплювати, редиректити, модифікувати запити юзера до файлової систем, до девайсів, до мережі.

щиро дякую! :)

На жаль, не завжди в дампі може зберігатися ця інформація. Наприклад, якщо алокація відбулася і після цього драйвер попрацював достатньо часу перед вивантаженням, можуть підчиститися дані про стек, в якому була ця проблемна алокація. В роботі я часто стикалася з такою особливістю «очистки інформації», тому вирішила поділитися цим альтернативним, більш універсальним способом)