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

S>А именно не того файла, с которым работают — а того исполняемого, который работает. Его контрольную сумму на данный момент.

S>Придумал такое решение:
S>- в каллбеке фильтра информация (включая путь к этому exe) не добавляется сразу в глобальную очередь записи в лог, а создается новый поток и она передается в него
S>- этот поток пытается открыть файл и посчитать MD5, результат добавляет в глобальную очередь
S>- поток логирования, как и сейчас, каждые N времени проверяет, не пуста ли очередь, если полна — создает файл лога и пишет ее всю

S>Но есть вопросы:
S>- насчет открывания файлов, насколько будет велик шанс, что он сможет открыть EXE-файл, который, скорее всего, сейчас выполняется?
Само по себе исполнение никак не блокирует разделяемый доступ на чтение. Но так как не планируется сохранять целостность exe-файла, он (exe-файл) может быть переименован или (если процесс успеет помереть) изменен-удален.

S>- сможет ли он открывать его так, чтобы гарантированно не повредить ему этим (если тот читает себя самого — SFX, например)?
Чтение файла не конфликтует с его исполнением. Side-эффекты могут быть, например: процесс уничтожился, exe-файл пытаются удалить, но при этом происходит расчет MD5. Либо файл для расчета открыт так, что удаление будет невозможно, либо удаление будет успешным, но создать файл с тем же именем поверх будет невозможно до окончания вычисления MD5.

S>- нету ли все-таки какого-то более готового способа получить хоть какой-то хеш EXE-файла? Который не только лежит на диске как файл, но и загружается как процесс.
В PE заголовке есть CheckSum (_IMAGE_OPTIONAL_HEADER), но для EXE-файлов процессов поле может быть некорректным и/или незаполненным.

S>- как лучше упорядочить все это? <...>
Лучше вынести все, что можно из драйвера в user mode, например, в Win32-сервис или просто утилиту. То есть делегировать не в отдельную нить, а унести всю обработку в свой user mode процесс (IOCTL/сообщения mini-фильров/разделяемая память через секции и события).