while(true) и KeDelayExecutionThread в DriverEntry — это неправильно, т.к. служба будет постоянно "Запускается".

Но как создать поток, и еще как быть с буфером?
С ним планируется сделать так:
— буфер объявлен как глобальная переменная UNICODE_STRING вне функций и инициалирован L""
— каллбеки фильтра аппендят к нему некие строки
— по таймеру проверяется, не пустой ли буфер по-прежнему, и если нет — то создается и открывается файл, буфер записывается в него, файл закрывается, после чего буфер опять инициализируется L""

На всякий случай, код создания того файла:

    OBJECT_ATTRIBUTES  objAttr;
    
    InitializeObjectAttributes(&objAttr, &filePath,
       OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,
       NULL, NULL);
       
    return ZwCreateFile(hFile,
                            GENERIC_ALL,
                            &objAttr, ioStatusBlock, NULL,
                            FILE_ATTRIBUTE_NORMAL,
                            0,
                            FILE_OVERWRITE_IF, 
                            FILE_SYNCHRONOUS_IO_NONALERT,
                            NULL, 0);

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

S>- по таймеру проверяется, не пустой ли буфер по-прежнему, и если нет — то создается и открывается файл, буфер записывается в него, файл закрывается, после чего буфер опять инициализируется L""

Зачем открывать/закрывать лог файл на каждый тик таймера? Открыл и пиши себе исходя из своей логики работы. + открытие / закрытие своего файла снова приведет к проходу через твой драйвер фильтр + лишняя проверка на свой / чужей = как результат лишняя работа и просадка проиводительности системы.

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

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

S>>- по таймеру проверяется, не пустой ли буфер по-прежнему, и если нет — то создается и открывается файл, буфер записывается в него, файл закрывается, после чего буфер опять инициализируется L""

___>Зачем открывать/закрывать лог файл на каждый тик таймера? Открыл и пиши себе исходя из своей логики работы. + открытие / закрытие своего файла снова приведет к проходу через твой драйвер фильтр + лишняя проверка на свой / чужей = как результат лишняя работа и просадка проиводительности системы.

Таймер будет работать достаточно редко — минут 5 может, а то и 30, в это время захочется посмотреть лог, а фиг, если он открыт.

В данном случае проверка свой\чужой не нужна, ему пофиг на этот файл, поскольку мониторит лишь конкретные имена файлов, этого файла там не будет, а если занесут в конфиг, ну пусть будет в логе, я же не в каллбеках пишу файл, поэтому рекурсии не будет.

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

___>>Зачем открывать/закрывать лог файл на каждый тик таймера? Открыл и пиши себе исходя из своей логики работы. + открытие / закрытие своего файла снова приведет к проходу через твой драйвер фильтр + лишняя проверка на свой / чужей = как результат лишняя работа и просадка проиводительности системы.

S>Таймер будет работать достаточно редко — минут 5 может, а то и 30, в это время захочется посмотреть лог, а фиг, если он открыт.



А ты не открывай его на запись в монопольном режиме и можно будет посмотреть.

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

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

___>>>Зачем открывать/закрывать лог файл на каждый тик таймера? Открыл и пиши себе исходя из своей логики работы. + открытие / закрытие своего файла снова приведет к проходу через твой драйвер фильтр + лишняя проверка на свой / чужей = как результат лишняя работа и просадка проиводительности системы.

S>>Таймер будет работать достаточно редко — минут 5 может, а то и 30, в это время захочется посмотреть лог, а фиг, если он открыт.

m2l>

m2l>А ты не открывай его на запись в монопольном режиме и можно будет посмотреть.

Да он все равно новый файл каждый раз открывает, господа оффтоперы!
Написано же было, "создается и открывается".

S>while(true) и KeDelayExecutionThread в DriverEntry — это неправильно, т.к. служба будет постоянно "Запускается".
https://msdn.microsoft.com/en-us/library/windows/hardware/ff559932(v=vs.85).aspx

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

S>>while(true) и KeDelayExecutionThread в DriverEntry — это неправильно, т.к. служба будет постоянно "Запускается".
O>https://msdn.microsoft.com/en-us/library/windows/hardware/ff559932(v=vs.85).aspx

Краткий какой ответ ^^
А завершать надо при unload?

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

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

S>Таймер будет работать достаточно редко — минут 5 может, а то и 30, в это время захочется посмотреть лог, а фиг, если он открыт.
S>В данном случае проверка свой\чужой не нужна, ему пофиг на этот файл, поскольку мониторит лишь конкретные имена файлов, этого файла там не будет, а если занесут в конфиг, ну пусть будет в логе, я же не в каллбеках пишу файл, поэтому рекурсии не будет.

Вот что то мне подсказывает, что логика твоего драйвера немного "страдает", потому как несколько тем назад ты сильно переживал что *WriteFile не успеет сбросить кешированые буфера на диск, если вдруг произойдет BSOD, а теперь ты планируешь хранить в драйвере (и скорей всего в NonPagedPool) тонны событий — которые будут сбрасываться на диск раз в 5-30 минут? То есть сейчас уже не переживаем что данные потеряются? И еще там аккуратней с проверкой "белого списка" в калл-беках, кого писать а кого нет, ибо если накосячить, получишь диградацию производительности целевой системы. Драйвера они требуют более продуманного подхода, писать по аналогии как на фреймворках, где никто ни о чем не заботится, главное чтобы быстро наклепать — тут не получится.
Рассмотри вариант с рабочим сервисом который общается с драйвером через IOCTL: ждет события от драйвера и когда тот готов передать информацию в сервис, выставляет событие и передает данные в сервис по запросу IOCTL. Так у тебя и драйвер не будет занимать много NonPaged памяти для событий, так и сервис будет практически мгновенно обновлять лог файл.

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

>и скорей всего в NonPagedPool
См. головную тему.
Глобальная переменная UNICODE_STRING, каждые 5-30 мин грузится в лог и очищается. ПЛАНИРУЮ сделать так. Пока не сделал.

> То есть сейчас уже не переживаем что данные потеряются?
Так то был лог. Призванный заменить лог дебага, чтобы, во-первых, не тратить время на настройку WinDbg (да и установку вообще), во-вторых, меньше тормозило на слабом железе (без брекпоинтов можно жить, без лога нет и ради одного лишь этого приходится мучаться с WinDbg), в-третьих по-хорошему лог все равно нужен.
А здесь... Ну, в идеале бы не терять. Но как? Писать в файл прямо в фильтрах? Усложняет архитектуру (избежать рекурсии), замедляет быстродействие, особенно на HDD.

> Рассмотри вариант с рабочим сервисом
Заказчик отверг.

> Так у тебя и драйвер не будет занимать много NonPaged памяти для событий
Он ее и так не будет ее сильно много занимать.

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

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

>>и скорей всего в NonPagedPool
S>См. головную тему.
S>Глобальная переменная UNICODE_STRING, каждые 5-30 мин грузится в лог и очищается. ПЛАНИРУЮ сделать так. Пока не сделал.

Здесь речь идет не о способе представления твоего буфера, а о виде памяти которая будет использоваться для хранения: PagedPool или NonPagedPool

>Так то был лог. Призванный заменить лог дебага, чтобы, во-первых, не тратить время на настройку WinDbg (да и установку вообще),
>во-вторых, меньше тормозило на слабом железе (без брекпоинтов можно жить, без лога нет и ради одного лишь этого приходится мучаться с WinDbg), в-третьих по-хорошему лог все равно нужен.

WinDbg это первое что ты должен поставить и настоять чтобы продуктивно писать и отлаживать драйвера. Можно конечно и лог писать, но продуктивность такой отладки особенно если падает в BSOD намного ниже, нежели поставить WinDbg и искать причину на месте.
И потом мучится с ним особо и не нужно, если с отладчиком студии дружишь — WinDbg можно сказать lite версия того отладчика, хотя возможностей намного больше чем у студии.

S>А здесь... Ну, в идеале бы не терять. Но как? Писать в файл прямо в фильтрах? Усложняет архитектуру (избежать рекурсии), замедляет быстродействие, особенно на HDD.

Если речь идет о дебаг логе — то можно или юзать DbgView — он умеет складировать лог в память и при BSOD вытягивать его из MEMORY.DMP при следующей загрузке.
Если все таки о логе событий которые нужно перехватывать — то я думаю вариант с сервисом был бы крайне уместен.

>>Рассмотри вариант с рабочим сервисом
S>Заказчик отверг.

Ну дело ваше конечно, просто ты ему еще такую вещь объясни: сейчас вам нужен только лог открытий/закрытий файлов. Завтра понадобится что то еще, потом еще что и еще... соответственно скорей всего поменяется формат сохранения файла или условия его сохранения на диск. Все это
может привести к неоправданному усложнению логики работы драйвера и как результат к возможным ошибкам и вылетам. А так написал легенький драйвер фильтр, который только складирует в память и выдает то что отсладировал по запросу, а сложную логику разбора, сохранения и мало ли чего еще
делает уже user-mode приложение или сервис.


>> Так у тебя и драйвер не будет занимать много NonPaged памяти для событий
S>Он ее и так не будет ее сильно много занимать.
Просто оцени количество событий и необходимой памяти на 5-30 минут держания лога в памяти выделенной драйвером.

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

___>Здесь речь идет не о способе представления твоего буфера, а о виде памяти которая будет использоваться для хранения: PagedPool или NonPagedPool

Буферы UNICODE_STRING всегда выделяют либо в NonPagedPool, либо в NonPagedPoolNx. Я сделаю в первом.

___>WinDbg это первое что ты должен поставить и настоять чтобы продуктивно писать и отлаживать драйвера.

Бюджетный ноутбук + VirtualBox + WinDbg + запись видео с экрана для заказчика = кромешный Адъ и потом в редакторе вырезать полчаса тормозов из видео.
Без WinDbg лучше.

S>Здравствуйте, _f_b_i_, Вы писали:
___>>Здесь речь идет не о способе представления твоего буфера, а о виде памяти которая будет использоваться для хранения: PagedPool или NonPagedPool
S>Буферы UNICODE_STRING всегда выделяют либо в NonPagedPool либо в NonPagedPoolNx
Это кто вам такую чушь сказал?