Есть фильтр-драйвер для устройства. Кидает в логи обращения через него. Сейчас сделано через DbgPrint. Хочется написать отдельную программку, которая могла бы получать логи из драйвера (лучше в структурированном виде а не в виде текстовых строк) и отображать ее. Как проще/правильнее передавать данные ? Можно ли из драйвера писать в майлслот, писать в named shared memory или как прицепится к той-же DbgPrint ?
Вопросов много, просто с такими вещами на уровне драйверов еще не сталкивался...

Если по поводу общей памяти (записи,чтения),то это читай "Драйверы режима ядра: Часть 8: Базовая техника: Работа с памятью. Совместно используемый раздел" BY Four-F
Я просто писал в файл. Но можно изврашенней, если не знаешь, есть ли у тебя права его где-то создать, то можно вписать куда-нибудь ключь в реестре и туда писать, а потом считывать.На счет майлслот не пробывал, но if из ring-3 можно, то и из KernelMode ч/з ZwCreateFile, ZwWriteFile можно.

Кстати можно просто в дровине писать все перехваченые данные в буфер (дописавать), а прога из вне (из UserMode) по тику таймераможет вызывать DeviceIoControl к Твоему драйверу, а он Тебе от себя будет копировать в буфер в UserMode. Кстати - наиболее менее опасно. Там за Тебя с буферами IOManager будет работать.

> Кстати можно просто в дровине писать все перехваченые данные в буфер (дописавать),
> а прога из вне (из UserMode) по тику таймераможет вызывать DeviceIoControl к Твоему драйверу,
бррр... вот это извращение ;)
межпроцессорные средства взаимодействия реализованы в исполнительной системе (т.е. в верхнем уровне ядра), поэтому вызывать их из кернела не только можно, но и нужно, т.к. это единственно правильный способ.

> Хочется написать отдельную программку, которая могла бы
> получать логи из драйвера (лучше в структурированном
> виде а не в виде текстовых строк) и отображать ее
такие программы уже есть, например, DbgView от Руссиновича (лежит на http://www.sysinternals.com) кажется даже с сорцами, хотя я могу и ошибаться.
Писать самому такое муторно, поскольку просто ловить отладочный вывод неинтересно и быстро надоедает, там необходимо добавить гибкую систему филитров и регулярный поиск, чтобы _быстро_ смотреть где лыжи, т.к. при большом кол-ве вывода в нем трудно разобраться, а при малом - трудно диагнористировать проблему

> Как проще/правильнее передавать данные ?
зависит от специфики обработки и кто берет на себя роль активной стороны. если нужно просто посмотреть, что в данный момент делает драйвер, то можно ограничиться DeviceIoControl, чуть сложнее добиться чтобы драйвер мог сигнализировать о проблемах, которые никто не ждал. майл слот (а еще лучше пайп) - требует опроса, что не всегда удобно. тут помогают call-back функции, расположенные в адресном пространстве юзерской программы. если нужно могу рассказать подробнее.

зависит от специфики обработки и кто берет на себя роль активной стороны

я написал об этом. фильтр ведет логи обрашений к нему. Прикладуха должна это дело отображать. Желательно в труктурированном виде.
DeviceIOControl мне не очень нравится, т.к. я не знаю как много инфы может напихатся в буфер в периодах опроса прикладухи. Вообще в идеале у дравера не должно быть никаких буферов. Поэтому я и хотел при бабахать майлслот или shared memory, которая открывается со стороны приложения.
Почитаю статью FF - потом опять буду спрашивать :)

просто ловить отладочный вывод неинтересно

возможно, но все-таки КАК это сделать ?

> возможно, но все-таки КАК это сделать ?
посмотри сорцы руссиновича, у меня только драйвер, который падчит ядро, а делает это он вот так (много ЦП'шный код опущен для краткости):

.text:0001062A sub_1062A       proc near	       ; CODE XREF: sub_10706+15Fp
.text:0001062A 
.text:0001062A var_4	       = dword ptr -4
.text:0001062A 
.text:0001062A		       push    ebp
.text:0001062B		       mov     ebp, esp
.text:0001062D		       push    ecx
.text:0001062E		       cmp     byte_10AEA, 0
.text:00010635		       push    edi
.text:00010636		       jz      short loc_10646
.text:00010638		       mov     byte_10AE9, 1
.text:0001063F		       mov     al, 1
.text:00010641		       jmp     loc_10701
.text:00010646 ; ────────────────────────────────────────────────────────────────────── ─────
.text:00010646 
.text:00010646 loc_10646:			       ; CODE XREF: sub_1062A+Cj
.text:00010646		       mov     eax, offset loc_10AD4
.text:0001064B		       mov     eax, [eax+2]
.text:0001064E		       mov     dword_10BA8, eax
.text:00010653		       mov     ecx, [eax]
.text:00010655		       mov     dword_10BA8, ecx
.text:0001065B		       mov     al, [ecx+1]
.text:0001065E		       cmp     al, 8Dh
.text:00010660		       jnz     short loc_10666
.text:00010662		       push    7
.text:00010664		       jmp     short loc_10670
.text:00010666 ; ────────────────────────────────────────────────────────────────────── ─────
.text:00010666 
.text:00010666 loc_10666:			       ; CODE XREF: sub_1062A+36j
.text:00010666		       cmp     al, 8Bh
.text:00010668		       jnz     loc_106FF
.text:0001066E		       push    0Ah
.text:00010670 
.text:00010670 loc_10670:			       ; CODE XREF: sub_1062A+3Aj
.text:00010670		       pop     edi
.text:00010671		       xor     eax, eax
.text:00010673		       test    edi, edi
.text:00010675		       jbe     short loc_10693
.text:00010677		       push    esi
.text:00010678		       mov     esi, ecx
.text:0001067A		       sub     esi, offset unk_10B20
.text:00010680 
.text:00010680 loc_10680:			       ; CODE XREF: sub_1062A+66j
.text:00010680		       mov     dl, byte	ptr unk_10B20[esi+eax]
.text:00010687		       mov     byte ptr	unk_10B20[eax],	dl
.text:0001068D		       inc     eax
.text:0001068E		       cmp     eax, edi
.text:00010690		       jb      short loc_10680
.text:00010692		       pop     esi
.text:00010693 
.text:00010693 loc_10693:			       ; CODE XREF: sub_1062A+4Bj
.text:00010693		       add     ecx, eax
.text:00010695		       mov     word ptr	unk_10B20[eax],	25FFh
.text:0001069E		       push    ebx
.text:0001069F		       mov     dword_10AEC, eax
.text:000106A4		       mov     dword_10BA4, ecx
.text:000106AA		       mov     dword ptr unk_10B22[eax], offset	dword_10BA4
.text:000106B4		       mov     eax, cr0
.text:000106B7		       mov     ebx, eax
.text:000106B9		       and     eax, 0FFFEFFFFh
.text:000106BE		       mov     cr0, eax
.text:000106C1		       mov     eax, ebx
.text:000106C3		       mov     [ebp+var_4], eax
.text:000106C6		       mov     eax, dword_10BA8
.text:000106CB		       mov     word ptr	[eax], 25FFh
.text:000106D0		       mov     eax, dword_10BA8
.text:000106D5		       mov     dword_10BA0, offset sub_1054E
.text:000106DF		       mov     dword ptr [eax+2], offset dword_10BA0
.text:000106E6		       mov     eax, [ebp+var_4]
.text:000106E9		       mov     cr0, eax
.text:000106EC		       mov     byte_10AEA, 1
.text:000106F3		       mov     byte_10AE9, 1
.text:000106FA		       mov     al, 1
.text:000106FC		       pop     ebx
.text:000106FD		       jmp     short loc_10701
.text:000106FF ; ────────────────────────────────────────────────────────────────────── ─────
.text:000106FF 
.text:000106FF loc_106FF:			       ; CODE XREF: sub_1062A+3Ej
.text:000106FF		       xor     al, al
.text:00010701 
.text:00010701 loc_10701:			       ; CODE XREF: sub_1062A+17j
.text:00010701					       ; sub_1062A+D3j
.text:00010701		       pop     edi
.text:00010702		       leave
.text:00010703		       retn
.text:00010703 sub_1062A       endp
.text:00010703 
.text:00010AD4 ; ────────────────────────────────────────────────────────────────────── ─────
.text:00010AD4 
.text:00010AD4 loc_10AD4:			       ; DATA XREF: sub_1062A+1Co
.text:00010AD4		       jmp     ds:DbgPrint
.text:00010AD4 ; ───────────────────────────────────────────────────────────────────────────

p.s. надеюсь мне не оторвут хвост за овертраффик? а то ж место на сервере кончается

kaspersky
надеюсь мне не оторвут хвост за овертраффик?

Все ОК. Посты, подобные этому - гордость форума.

infern0, на сайте лежат сорсы RegMon/FileMon'ов. Там самый простой способ - юзер ставит таймер (1сек) и по нему забирает лог через DeviceIoControl. Размер буфера может быть очень велик. Второй простой способ тоже делать асинхронный вызов ReadFile и ждать, когда драйвер посчитает нужным он отдаст лог. Можно через разделяемую память, как в упомянутой выше статье.

можно просто Event слать, как между tread-ами;

> можно просто Event слать, как между tread-ами;
Event конечно лучше, т.к. драйвер может сигнализировать о том, что у него что-то есть и тогда его можно постоянно не опрашивать...

Господа, раз уж начали вариации на данную тему, позвольте мне тоже, выпендриться. Не сочтите меня за идиота, (хотя я сам уже давно себя таковым считаю. Гыыы :)
а что если взять и подправить дескрипторы, касающиеся PTE/PDE, и разрешить пользовательскому приложению ходить в 3,4й гигабайт за данными,??

PS:! Блин, я вот в детстве хотел писателем фантастом стать !!! Не бейте меня...:)

<блин, я не могу ............>

там много править придется и не только PTE/PDE... и еще следить, чтобы винда не вернула все обратно. тут есть еше одна сложность - см. драйвер руссиновича сбрасывает WP, чтобы писать со своего уровня супервизора, а с прикладного уровня придется корректировать не только DPL, но и давать атрибуты на запись. теперь самое интересное, я знаю несколько мест в ядре, которые закладываются на незаписываемость некоторых учатков своего кода (т.е. они возбуждают таким образом исключение), к тому же потенциально опасно это давать приложениям право писать в ядро (кстати, RTL бормана тоже возбуждает исключение аналогичм образом, правда пишет не в ядро, в а первые 4 кб адресного пространства, но все равно... грантий, что юзер не полезет в ядро у нас нет).
последствия же могут быть любыми - вплоть до порчи файловой системы. уж лучше написать драйвер, позволяющий через DeviceIoControl явно писать/читать заданные регионы памяти.

[ kaspersky: см. драйвер руссиновича сбрасывает WP... ]

Если имется ввиду FileMon, то там такого нет вообще. Обычный драйвер-фильтр. Всё сделано документированным приаттачиванием к существующим девайсам файловой системы через IoAttachDeviceToDeviceStack и IoAttachDeviceByPointer.

Если имется ввиду RegMon, то там есть патч SDT, но сделан он не тупым сбросом WP, а более грамотно - путем перемапливания SDT с доступом на запись. см. тут Защита от записи в SDT в винде


[ CARDINAL: а что если взять и подправить дескрипторы, касающиеся PTE/PDE ]

Это из серии "зачем просто, когда можно сложно" :) Править PTE/PDE придется из ядра. Если ты уже в ядре, на кой хрен тебе заниматься таким геморроем, когда можно спокойно воспользоваться документированными методами.


[ CARDINAL: и разрешить пользовательскому приложению ходить в 3,4й гигабайт за данными ]

См. "Часть 9 : Базовая техника: Работа с памятью. Разделяемая память" - там именно это и сделано, но только правильно.

> Если имется ввиду FileMon,
нет, DbgView, дизассемблерный листинг которого я приводил выше, смотри:

.text:000106B4		       mov     eax, cr0
.text:000106B7		       mov     ebx, eax
.text:000106B9		       and     eax, 0FFFEFFFFh
.text:000106BE		       mov     cr0, eax

Непойму чего то драйвер то свой или чужой?
Если свой то почему не реализовать функцию передачи логов в драйвере в самом? И пользователь её просто будет вызывать по DeviceIoControl драйвер в указанный буфер пользователя всё что надо запишет.