Сообщение Re[2]: FS Minifilter, IRP_MJ_CREATE. Кривой FileName? от 08.01.2018 16:01
Изменено 08.01.2018 16:12 sergey77666
Re[2]: FS Minifilter, IRP_MJ_CREATE. Кривой FileName?
Здравствуйте, okman, Вы писали:
O>Здравствуйте, sergey77666, Вы писали:
S>>Примерно такой код
S>>...
S>>И вот на этом самом месте, где RtlStringCchPrintfW, иногда происходит ерунда.
O>1. Спецификатор '%wZ' требует передачи указателя на UNICODE_STRING, а не сам UNICODE_STRING.
O>2. Вместо вытаскивания имени из FILE_OBJECT надежнее FltGetFileNameInformation.
Так. От тотального перехода на указатели стало хуже.
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "[SmolinsFileProtector2] CreateFile: %wZ\r\n", &(pFileObject.FileName)); — работает
res = RtlStringCchPrintfW(bufPFO, 1024, L"%wZ", &(pFileObject.FileName)); — не работает, теперь постоянно выдает 80000005
Значит, сам pFileObject.FileName "кривой", что ли. Еще есть подозрения на функцию
FsRtlIsNameInExpression(&strExeExtCheckPattern, &(pFileObject.FileName), TRUE, NULL
где:
UNICODE_STRING strExeExtCheckPattern = RTL_CONSTANT_STRING(L"*.EXE");
Вряд ли она повреждает этот FileName. Но ввсе же надо смотреть.
Сперва надо вообще все потихоньку выкинуть, по крайней мере все это безумие со строками, и посмотреть что будет.
Оперативки на момент падения было 400 МБ свободной (по диспетчеру задач). ChromeSetup столько не жрет (а проблема была уже после его запуска).
O>Здравствуйте, sergey77666, Вы писали:
S>>Примерно такой код
S>>...
S>>И вот на этом самом месте, где RtlStringCchPrintfW, иногда происходит ерунда.
O>1. Спецификатор '%wZ' требует передачи указателя на UNICODE_STRING, а не сам UNICODE_STRING.
O>2. Вместо вытаскивания имени из FILE_OBJECT надежнее FltGetFileNameInformation.
Так. От тотального перехода на указатели стало хуже.
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "[SmolinsFileProtector2] CreateFile: %wZ\r\n", &(pFileObject.FileName)); — работает
res = RtlStringCchPrintfW(bufPFO, 1024, L"%wZ", &(pFileObject.FileName)); — не работает, теперь постоянно выдает 80000005
Значит, сам pFileObject.FileName "кривой", что ли. Еще есть подозрения на функцию
FsRtlIsNameInExpression(&strExeExtCheckPattern, &(pFileObject.FileName), TRUE, NULL
где:
UNICODE_STRING strExeExtCheckPattern = RTL_CONSTANT_STRING(L"*.EXE");
Вряд ли она повреждает этот FileName. Но ввсе же надо смотреть.
Сперва надо вообще все потихоньку выкинуть, по крайней мере все это безумие со строками, и посмотреть что будет.
Оперативки на момент падения было 400 МБ свободной (по диспетчеру задач). ChromeSetup столько не жрет (а проблема была уже после его запуска).
Re[2]: FS Minifilter, IRP_MJ_CREATE. Кривой FileName?
Здравствуйте, okman, Вы писали:
O>Здравствуйте, sergey77666, Вы писали:
S>>Примерно такой код
S>>...
S>>И вот на этом самом месте, где RtlStringCchPrintfW, иногда происходит ерунда.
O>1. Спецификатор '%wZ' требует передачи указателя на UNICODE_STRING, а не сам UNICODE_STRING.
O>2. Вместо вытаскивания имени из FILE_OBJECT надежнее FltGetFileNameInformation.
Так. От тотального перехода на указатели стало хуже.
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "[SmolinsFileProtector2] CreateFile: %wZ\r\n", &(pFileObject.FileName)); — работает
res = RtlStringCchPrintfW(bufPFO, 1024, L"%wZ", &(pFileObject.FileName)); — не работает, теперь постоянно выдает то 80000005, то просто пустая строка
Значит, сам pFileObject.FileName "кривой", что ли. Еще есть подозрения на функцию
FsRtlIsNameInExpression(&strExeExtCheckPattern, &(pFileObject.FileName), TRUE, NULL
где:
UNICODE_STRING strExeExtCheckPattern = RTL_CONSTANT_STRING(L"*.EXE");
Вряд ли она повреждает этот FileName. Но все же надо смотреть.
BSOD не там, а именно на return, во всяком случае в ситуации с Edge.
Сперва надо вообще все потихоньку выкинуть, по крайней мере все это безумие со строками, и посмотреть что будет.
Оперативки на момент падения было 400 МБ свободной (по диспетчеру задач). ChromeSetup столько не жрет (а проблема была уже после его запуска).
O>Здравствуйте, sergey77666, Вы писали:
S>>Примерно такой код
S>>...
S>>И вот на этом самом месте, где RtlStringCchPrintfW, иногда происходит ерунда.
O>1. Спецификатор '%wZ' требует передачи указателя на UNICODE_STRING, а не сам UNICODE_STRING.
O>2. Вместо вытаскивания имени из FILE_OBJECT надежнее FltGetFileNameInformation.
Так. От тотального перехода на указатели стало хуже.
DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "[SmolinsFileProtector2] CreateFile: %wZ\r\n", &(pFileObject.FileName)); — работает
res = RtlStringCchPrintfW(bufPFO, 1024, L"%wZ", &(pFileObject.FileName)); — не работает, теперь постоянно выдает то 80000005, то просто пустая строка
Значит, сам pFileObject.FileName "кривой", что ли. Еще есть подозрения на функцию
FsRtlIsNameInExpression(&strExeExtCheckPattern, &(pFileObject.FileName), TRUE, NULL
где:
UNICODE_STRING strExeExtCheckPattern = RTL_CONSTANT_STRING(L"*.EXE");
Вряд ли она повреждает этот FileName. Но все же надо смотреть.
BSOD не там, а именно на return, во всяком случае в ситуации с Edge.
Сперва надо вообще все потихоньку выкинуть, по крайней мере все это безумие со строками, и посмотреть что будет.
Оперативки на момент падения было 400 МБ свободной (по диспетчеру задач). ChromeSetup столько не жрет (а проблема была уже после его запуска).