Проблема следующего характера: минифильтр иногда возвращает странные адреса совершенно несравнимые с адресным пространством драйвера.При попытке доступа к таким адресам вылетает BSOD. Можно ли как-нибудь проверить является ли адрес "правильным"? На !адрес проскакивает. Может сделать слепок адреса мэина драйвера и как-нибудь сверять его с "левым" адресом?

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

F>Проблема следующего характера: минифильтр иногда возвращает странные адреса совершенно несравнимые с адресным пространством драйвера.При попытке доступа к таким адресам вылетает BSOD. Можно ли как-нибудь проверить является ли адрес "правильным"? На !адрес проскакивает. Может сделать слепок адреса мэина драйвера и как-нибудь сверять его с "левым" адресом?

А что вы имеете ввиду под "минифильтр иногда возвращает странные адреса"? Можете пример кода набросать и указать где неправильные адреса и как вы к ним обращаетесь?

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

AF>А что вы имеете ввиду под "минифильтр иногда возвращает странные адреса"? Можете пример кода набросать и указать где неправильные адреса и как вы к ним обращаетесь?
Обычный коллбак-фильтр реестра. При обработке RegNtQueryValueKey (ссылка на описание класса http://msdn.microsoft.com/en-us/library/ff560991(v=VS.85).aspx). В некоторых случаях ResultLength (A pointer to a variable that receives (from the system) the amount of valid data, in bytes, in the KeyValueInformation buffer) указывает куда-то в глубину космоса.

Обработка полученной информации была взята из RegMon-а, и выглядит в общих чертах так:

switch(KeyValueInformation):
case KeyValueFullInformation:
{
        PKEY_VALUE_FULL_INFORMATION FullInfo = (PKEY_VALUE_FULL_INFORMATION)KeyValueInformation;
        switch(FullInfo->Type) //тип выявляется корректно
        {
    case REG_SZ:    
        case REG_EXPAND_SZ:
        case REG_MULTI_SZ:
        {
             WCHAR s[256];
             s[0]=((PWCHAR)((PCHAR) FullInfo + FullInfo->DataOffset))[0];    //допустим если сделать так, то вылетит БСОД.  
        }    

..............
}

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


Хотя если ввести проверку на ResultLength[0]==Length, вроде, "битые" данные отсекаются, однако боюсь, что подобная проверка приведет к потере некоторых "небитых" данных.

F>Хотя если ввести проверку на ResultLength[0]==Length, вроде, "битые" данные отсекаются, однако боюсь, что подобная проверка приведет к потере некоторых "небитых" данных.

В Information буфере надо считать данные валидными лишь до Length. В ResultLength вам смотреть не надо, если только вы не модифицируете данные в своем обработчике.
И еще в том случае если этот код — перехват SDT — надо читаемые данные оборачивать в try__except с ProbeForRead внутри в том случае если ExGetPreviousMode()==UserMode.
И вообще код ужасен, подучите матчасть для начала.

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

F>>Хотя если ввести проверку на ResultLength[0]==Length, вроде, "битые" данные отсекаются, однако боюсь, что подобная проверка приведет к потере некоторых "небитых" данных.

O>В Information буфере надо считать данные валидными лишь до Length. В ResultLength вам смотреть не надо, если только вы не модифицируете данные в своем обработчике.
O>И еще в том случае если этот код — перехват SDT — надо читаемые данные оборачивать в try__except с ProbeForRead внутри в том случае если ExGetPreviousMode()==UserMode.
O>И вообще код ужасен, подучите матчасть для начала.

Понимаете, в некоторых случаях вылетает BSOD при попытке обратиться к этим самым данным и возникает это когда в ResultLength записывается бред.
Я же написал, что код в общих чертах.

F>Понимаете, в некоторых случаях вылетает BSOD при попытке обратиться к этим самым данным и возникает это когда в ResultLength записывается бред.
F>Я же написал, что код в общих чертах.
можно лог windbg анализа такого бсода?

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

F>Здравствуйте, Alexey Frolov, Вы писали:

F>Обычный коллбак-фильтр реестра. При обработке RegNtQueryValueKey (ссылка на описание класса http://msdn.microsoft.com/en-us/library/ff560991(v=VS.85).aspx).

Во-первых, есть отличия в фильтрах на разных операционках, на какой вы проверяете? Можно собрать код для одной target platform, а запускать на другой, там есть нюансы. Во-вторых из сказанного не очевидно, речь идет про Pre или про Post операцию? (хотя если иногда работает, то смею предположить, что все использовано корректно). Но все таки проверьте на всякий случай не используете ли вы один и тот же обработчик для per и post операции. В-третьих, чтобы так смело обращаться к данным, для начала неплохо бы проверить их наличие и размер. В вашем случае это и параметр Length (REG_QUERY_VALUE_KEY_INFORMATION) и параметр DataLength (KEY_VALUE_FULL_INFORMATION). В-четвертых, в пост-обработчике неплохо бы проверять статус операции

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

F>Здравствуйте, Fenir, Вы писали:
F>Хотя если ввести проверку на ResultLength[0]==Length, вроде, "битые" данные отсекаются, однако боюсь, что подобная проверка приведет к потере некоторых "небитых" данных.

Если вы только мониторите, но не меняете данные, то этот параметр будет содержать осмысленное значение только в постоперации. То есть его нужно запомнить в преоперации и в постоперации можно к нему обратиться. Но судя по коду речь идет о преоперации, поэтому не нужно проверять. Я могу и ошибаться но подбные параметры часто могут содержать NULL, то есть того кто вызвал функцию не интересует это значение.

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

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

F>>Здравствуйте, Fenir, Вы писали:
F>>Хотя если ввести проверку на ResultLength[0]==Length, вроде, "битые" данные отсекаются, однако боюсь, что подобная проверка приведет к потере некоторых "небитых" данных.

AF>Если вы только мониторите, но не меняете данные, то этот параметр будет содержать осмысленное значение только в постоперации. То есть его нужно запомнить в преоперации и в постоперации можно к нему обратиться. Но судя по коду речь идет о преоперации, поэтому не нужно проверять. Я могу и ошибаться но подбные параметры часто могут содержать NULL, то есть того кто вызвал функцию не интересует это значение.

Извиняюсь за поздний ответ.
Спасибо, отлавливал pre. Не подскажите как post вообще отловить в XP sp2 для x86? Добавление в перехватчик, допустим, такой строки case RegNtPostQueryValueKey: результатов не дает(в msdn написано, что появились такие операции в win serv 2003, однако sp2 вышел вроде как позже, да и в RegMon-е коллбаки используются и работает превосходно(однако не могу понять почему)).

F>...написано, что появились такие операции в win serv 2003, однако sp2 вышел вроде как позже...

Ядро Windows XP x86 отличается от Windows Server 2003 x86, и пакет обновления тут роли не играет. Но вот, например, на Windows XP x64 должно работать, т.к. у них ядра одинаковые с Windows Server 2003 x64.

F>...в RegMon-е коллбаки используются и работает превосходно...

RegMon (как и Process Monitor нынешний) на Windows XP x86 хукает SDT весьма активно.

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

F>>...написано, что появились такие операции в win serv 2003, однако sp2 вышел вроде как позже...

x64>Ядро Windows XP x86 отличается от Windows Server 2003 x86, и пакет обновления тут роли не играет. Но вот, например, на Windows XP x64 должно работать, т.к. у них ядра одинаковые с Windows Server 2003 x64.

F>>...в RegMon-е коллбаки используются и работает превосходно...
x64>RegMon (как и Process Monitor нынешний) на Windows XP x86 хукает SDT весьма активно.

То есть я никак не смогу получить более осмысленную информацию через коллбаки?