Когда-то пользовался этим методом, ещё когда была бумажная книжка Нэббета по нативным функциям Windows NT.
Годы шли, и я про эту функцию забыл. И тут , она резко понадобилась, прямо-таки внезапно как понос.
Обнаружил что она не работает корректно в моём коде, думал было код у меня кривой,
полез на кодпрожект, нашёл там статью с исходноком и демку. Запустил демку , и она не работает.Тут нужно отметить
что не работает она не чуть не хуже чем мой код, т.е. не работают и код из статьи на код проджекте и мой примерно одинаково.
Но! при всём при этом отлично работает ProcessExplorer марка нашего Руссиновича, а ведь он тоже использует эту NAPI.
В чём грабли?
B>что не работает она не чуть не хуже чем мой код, т.е. не работают и код из статьи на код проджекте и мой примерно одинаково. B>Но! при всём при этом отлично работает ProcessExplorer марка нашего Руссиновича, а ведь он тоже использует эту NAPI. B>https://www.codeproject.com/Articles/19685/Get-Process-Info-with-NtQueryInformationProcess
То есть читателю предлагется скачать и запустить код чтобы посмотреть как именно оно не работает? Лень.
Но потыркать на кнопки не лень, так что могу предположит что используемая структура определена неверно. Почему неверно определена — тоже можно понастроить гипотез. Например пытаемся заюзать 32хбитную структуру в 64хбитной апликухе, или пытаемся заюзать некоторые структуры, определение которых менялось от версии к версии винды, потому нужно определить версию винды и подставить нужную структуру. Где взять правильную структуру? В гугле вестимо.
B>В чём грабли?
В сарае.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Burbulis1978, Вы писали:
B>Но! при всём при этом отлично работает ProcessExplorer марка нашего Руссиновича, а ведь он тоже использует эту NAPI.
Здравствуйте, ononim, Вы писали:
B>>что не работает она не чуть не хуже чем мой код, т.е. не работают и код из статьи на код проджекте и мой примерно одинаково. B>>Но! при всём при этом отлично работает ProcessExplorer марка нашего Руссиновича, а ведь он тоже использует эту NAPI. B>>https://www.codeproject.com/Articles/19685/Get-Process-Info-with-NtQueryInformationProcess O>То есть читателю предлагется скачать и запустить код чтобы посмотреть как именно оно не работает? Лень. O>Но потыркать на кнопки не лень, так что могу предположит что используемая структура определена неверно. Почему неверно определена — тоже можно понастроить гипотез. Например пытаемся заюзать 32хбитную структуру в 64хбитной апликухе, или пытаемся заюзать некоторые структуры, определение которых менялось от версии к версии винды, потому нужно определить версию винды и подставить нужную структуру. Где взять правильную структуру? В гугле вестимо.
B>>В чём грабли? O>В сарае.
Предполагается что ответит читатель который реально работал с указанной napi , т.е. имеет практику конкретно под win10.
И знает что делать. В любом случае спасибо что не остались в стороне.
Всё как обычно: Знающие не говорят, говорящие не знают.(с) какой-то дядька.
Здравствуйте, CEMb, Вы писали:
CEM>Здравствуйте, Burbulis1978, Вы писали:
B>>Но! при всём при этом отлично работает ProcessExplorer марка нашего Руссиновича, а ведь он тоже использует эту NAPI.
CEM>Можно тут глянуть: http://processhacker.sourceforge.net/ Вроде как, тот же PE, но с исходниками
Очень большое спасибо, реально очень-очень интересный прожект.Это просто волшебно
Здравствуйте, CEMb, Вы писали:
CEM>Здравствуйте, Burbulis1978, Вы писали:
B>>Но! при всём при этом отлично работает ProcessExplorer марка нашего Руссиновича, а ведь он тоже использует эту NAPI.
CEM>Можно тут глянуть: http://processhacker.sourceforge.net/ Вроде как, тот же PE, но с исходниками
Спасибо огромнейшее! Прожект просто волшебный, жаль только что драйвера legacy , а в целом просто чудесно
Масса примеров чудесного кода
Здравствуйте, Burbulis1978, Вы писали:
B>Предполагается что ответит читатель который реально работал с указанной napi , т.е. имеет практику конкретно под win10.
То есть, имел опыт портирования конкретного примера из CodeProject на Win10 и помнит, что именно с ним было не так ?
Так то функция работает, Windows по-прежнему использует её для внутренних нужд.
А в конкретном примере она может не работать по десяткам разных причин, если более детальной информации нет.
Для того, чтобы опытный читатель смог предположить, что же именно не так, крайне желательно привести, как именно она не работает, например:
1. Какой именно ProcessInformationClass она возвращает?
2. Возвращает ли она не-успешный NTSTATUS (какой именно?)
3. Если успешный NTSTATUS, но выходную структуру не заполняет, или заполняет неожиданным образом, то в чём именно нет соответствия ожиданиям?
4. Если до возврата из неё не доходит, почему? Exception там случается, BSOD ли, или просто нельзя получить её адрес?
При всём этом отсутствии информации, наиболее вероятное предположение было высказано:
неправильная структура, может выливаться в неожиданное заполнение или нехватку буфера.
Где именно неправильно и что именно — без деталей неясно. Но на стороне спрашивающего эти детали доступны, с ними он вполне может пойти в гугл за праильным определением структуры.
Ещё неплохо сформулировать более высокоуровневую задачу. Что от неё в конце-концов нужно.
Имя "ехешника" процесса, как в примере? Уже сто лет как есть GetProcessImageFileName и QueryFullProcessImageName всякие.
Вообще всё, что она может сказать? Тогда да, вызывать её.
B>И знает что делать. В любом случае спасибо что не остались в стороне. B>Всё как обычно: Знающие не говорят, говорящие не знают.(с) какой-то дядька.
Здравствуйте, Burbulis1978, Вы писали:
B>Предполагается что ответит читатель который реально работал с указанной napi , т.е. имеет практику конкретно под win10. B>И знает что делать. В любом случае спасибо что не остались в стороне. B>Всё как обычно: Знающие не говорят, говорящие не знают.(с) какой-то дядька.
ответил Вам как раз человек более чем знающий! Вы бы лучше пример минимальный собрали воспроизводящий проблему, если конечно еще сами не разобрались — сразу бы получили ответ.
Здравствуйте, Alexander G, Вы писали:
AG>Здравствуйте, Burbulis1978, Вы писали:
B>>Предполагается что ответит читатель который реально работал с указанной napi , т.е. имеет практику конкретно под win10.
AG>То есть, имел опыт портирования конкретного примера из CodeProject на Win10 и помнит, что именно с ним было не так ?
AG>Так то функция работает, Windows по-прежнему использует её для внутренних нужд. AG>А в конкретном примере она может не работать по десяткам разных причин, если более детальной информации нет.
AG>Для того, чтобы опытный читатель смог предположить, что же именно не так, крайне желательно привести, как именно она не работает, например: AG>1. Какой именно ProcessInformationClass она возвращает?
Ожидаю что вернёт его собственно и запрашиваю:
ProcessBasicInformation
AG>2. Возвращает ли она не-успешный NTSTATUS (какой именно?) AG>3. Если успешный NTSTATUS, но выходную структуру не заполняет, или заполняет неожиданным образом, то в чём именно нет соответствия ожиданиям? AG>4. Если до возврата из неё не доходит, почему? Exception там случается, BSOD ли, или просто нельзя получить её адрес?
Вот набросал тестовый код:
00007ff8`e4c656b0 4c8bd1 mov r10,rcx
00007ff8`e4c656b3 b819000000 mov eax,19h
00007ff8`e4c656b8 f604250803fe7f01 test byte ptr [SharedUserData+0x308 (00000000`7ffe0308)],1
00007ff8`e4c656c0 7503 jne ntdll!ZwQueryInformationProcess+0x15 (00007ff8`e4c656c5)
00007ff8`e4c656c2 0f05 syscall
00007ff8`e4c656c4 c3 ret
Поскольку я трассирую в юзерспэйсе дальше меня никто не пустил.SoftICe под Win10 не работает,
а windbg вынужден юзать тоолько в юзерспэйсе, VMWARE нет путёвой, и второго компа лишнего тоже нет.
После выхода из NtQueryInformationProcess
Возращается NTSTATUS == STATUS_SUCCESS ,dwSize == RLength. функция выполняется.Без падений и синих экранов.
А вот с processinfo засада ProcessInfo->PebBaseAddress == NULL.
С помощью гугла ещё до обращения сбда находил какието лекарства, связанные со смещением этого поля в зависимости от версии OS.
Но они не помогли.
При всём при этом SystemProcessesInformation — NtQueryInformationProcess, отрабатывает на ура.Без вопросов.
AG>Ещё неплохо сформулировать более высокоуровневую задачу. Что от неё в конце-концов нужно.
В конце концов , хочется получить сервис которых будет делать срезы на предмет состояния процессов, кол-ва потоков,
счётчиков производительности, процессорного времени, памяти,WorkingSet-ов и т.д. и сохранять всё это в базу данных, чтобы другой сервис
всё это безобразие анализировал, в рамках разных промежутков времени и прринимал решения в соответствии с заданными пользователем правилами.
Как-то так.
AG>Имя "ехешника" процесса, как в примере? Уже сто лет как есть GetProcessImageFileName и QueryFullProcessImageName всякие. AG>Вообще всё, что она может сказать? Тогда да, вызывать её.
B>После выхода из NtQueryInformationProcess B>Возращается NTSTATUS == STATUS_SUCCESS ,dwSize == RLength. функция выполняется.Без падений и синих экранов. B>А вот с processinfo засада ProcessInfo->PebBaseAddress == NULL. B>С помощью гугла ещё до обращения сбда находил какието лекарства, связанные со смещением этого поля в зависимости от версии OS. B>Но они не помогли.
Очень похоже на то что вы из 32хбитного процесса пытаетесь получить PEB 64хбитного.
Надо понимать, что у 32хбитных процессов в 64хюитной винде два PEB(а) (ну и сразу скажу — у потоков таких процессов — по два TEB'а). Один PEB — 64хбитный, второй — 32хбитный.
32хбитная версия NtQueryInformationProcess выдает адрес 32хбитного PEB'а. 64хбитная — 64хбитного соответственно.
У 64хбитных процессов нету 32хбитного PEB-а, поэтому 32хбитная NtQueryInformationProcess для таких процессов возвращает PebBaseAddress=NULL.
Адекватное решение (а не тот хак что я ниже писал) — в 64хбитной винде юзать 64хбитные приложения. 64хбитный PEB — он есть у всех. Правда возникает вопрос зачем вам этот PEB. Например, помимо того что в 32хбитных процессах есть два PEBa(и по два TEB-а), у них еще есть и по два PEB loader list'а. Причем они разные. Один содержит 64хбитные длл (там обычно только ntdll wow64 и прочие кишки wow64 подсистемы), а второй — 32хбитные. Впрочем оба содержат ентри на имаж ехешника. Так что это нужно тоже учитывать, и если захочется из 64хбитного процесса получить адрес 32хбитного PEB-а, то можно воспользоваться NtQueryInformationProcess(ProcessWow64Information). По документации она возвращает 0 для 64хбитных процессов, и не 0 для 32хбитных. А по факту для последних она возвращает адрес на их 32хюитный PEB. Надо понимать что если захочется воспользоваться этой информацией из 64хбитного кода, то структуру 32хбитного PEBа и все структуры к нему относящиеся придется кропотливо вручную дефайнить.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>... у них еще есть и по два PEB loader list'а. Причем они разные. Один содержит 64хбитные длл (там обычно только ntdll wow64 и прочие кишки wow64 подсистемы), а второй — 32хбитные. Впрочем оба содержат ентри на имаж ехешника.
Возникает ли надобность получать имя ехешника именно оттуда?
Первая ентри в InLoadOrderModuleList вроде как всегда на ехешник, но через ImagePathName в RTL_USER_PROCESS_PARAMETERS из PEB как-то чище выглядит.
O>>... у них еще есть и по два PEB loader list'а. Причем они разные. Один содержит 64хбитные длл (там обычно только ntdll wow64 и прочие кишки wow64 подсистемы), а второй — 32хбитные. Впрочем оба содержат ентри на имаж ехешника. AG>Возникает ли надобность получать имя ехешника именно оттуда? AG>Первая ентри в InLoadOrderModuleList вроде как всегда на ехешник, но через ImagePathName в RTL_USER_PROCESS_PARAMETERS из PEB как-то чище выглядит.
Но RTL_USER_PROCESS_PARAMETERS тоже отличаются — тоже одна 32хбитная, а вторая — 64хбитная. И теоретически могут сожержать разную информацию
А image path еще можно получить NtQueryInformationProcess(ProcessImageFileName). Или GetMappedFileName на PEB::ImageBaseAddress.
Забавный факт состоит в том, что если процесс использует всякие лоадеры/протекторы, то все эти методы могут дать разные результаты
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
B>>После выхода из NtQueryInformationProcess B>>Возращается NTSTATUS == STATUS_SUCCESS ,dwSize == RLength. функция выполняется.Без падений и синих экранов. B>>А вот с processinfo засада ProcessInfo->PebBaseAddress == NULL. B>>С помощью гугла ещё до обращения сбда находил какието лекарства, связанные со смещением этого поля в зависимости от версии OS. B>>Но они не помогли. O>Очень похоже на то что вы из 32хбитного процесса пытаетесь получить PEB 64хбитного. O>Надо понимать, что у 32хбитных процессов в 64хюитной винде два PEB(а) (ну и сразу скажу — у потоков таких процессов — по два TEB'а). Один PEB — 64хбитный, второй — 32хбитный. O>32хбитная версия NtQueryInformationProcess выдает адрес 32хбитного PEB'а. 64хбитная — 64хбитного соответственно. O>У 64хбитных процессов нету 32хбитного PEB-а, поэтому 32хбитная NtQueryInformationProcess для таких процессов возвращает PebBaseAddress=NULL. O>Адекватное решение (а не тот хак что я ниже писал) — в 64хбитной винде юзать 64хбитные приложения. 64хбитный PEB — он есть у всех. Правда возникает вопрос зачем вам этот PEB. Например, помимо того что в 32хбитных процессах есть два PEBa(и по два TEB-а), у них еще есть и по два PEB loader list'а. Причем они разные. Один содержит 64хбитные длл (там обычно только ntdll wow64 и прочие кишки wow64 подсистемы), а второй — 32хбитные. Впрочем оба содержат ентри на имаж ехешника. Так что это нужно тоже учитывать, и если захочется из 64хбитного процесса получить адрес 32хбитного PEB-а, то можно воспользоваться NtQueryInformationProcess(ProcessWow64Information). По документации она возвращает 0 для 64хбитных процессов, и не 0 для 32хбитных. А по факту для последних она возвращает адрес на их 32хюитный PEB. Надо понимать что если захочется воспользоваться этой информацией из 64хбитного кода, то структуру 32хбитного PEBа и все структуры к нему относящиеся придется кропотливо вручную дефайнить.
Нда, бяда пячаль. Ну что, будем думать что делать дальше.
У меня была робкая надежда что внутри NtQueryInformationProces будет как раньше,по хэндлу получаться PEPROCESS а оттуда уже распихивание в структуру
PROCESS_BASIC_INFORMATION.
case ProcessBasicInformation:
if ( ProcessInformationLength != (ULONG) sizeof(PROCESS_BASIC_INFORMATION) ) {
return STATUS_INFO_LENGTH_MISMATCH;
}
st = ObReferenceObjectByHandle(
ProcessHandle,
PROCESS_QUERY_INFORMATION,
PsProcessType,
PreviousMode,
(PVOID *)&Process,
NULL
);
if ( !NT_SUCCESS(st) ) {
return st;
}
BasicInfo.ExitStatus = Process->ExitStatus;
BasicInfo.PebBaseAddress = Process->Peb;
BasicInfo.AffinityMask = Process->Pcb.Affinity;
BasicInfo.BasePriority = Process->Pcb.BasePriority;
BasicInfo.UniqueProcessId = (ULONG_PTR)Process->UniqueProcessId;
BasicInfo.InheritedFromUniqueProcessId = (ULONG_PTR)Process->InheritedFromUniqueProcessId;
ObDereferenceObject(Process);
//
// Either of these may cause an access violation. The
// exception handler will return access violation as
// status code. No further cleanup needs to be done.
//
try {
*(PPROCESS_BASIC_INFORMATION) ProcessInformation = BasicInfo;
if (ARGUMENT_PRESENT(ReturnLength) ) {
*ReturnLength = sizeof(PROCESS_BASIC_INFORMATION);
}
} except(EXCEPTION_EXECUTE_HANDLER) {
return STATUS_SUCCESS;
}
return STATUS_SUCCESS;
Вот так и рушатся надежды. На лёгкий выход из сложной ситуации.
Здравствуйте, Burbulis1978, Вы писали:
B>У меня была робкая надежда что внутри NtQueryInformationProces будет как раньше,по хэндлу получаться PEPROCESS а оттуда уже распихивание в структуру B>PROCESS_BASIC_INFORMATION.
Скорее всего, происходящее в ядре особо существенно не поменялось. (Приведенный код — видимо, код ядра Windows или Reactos).
Но на 64-разрядных системах ядро тоже 64-разрядное! Непосредственно с ядром в таких системах взаимодействует всегда 64-разрядная ntdll.
Для работы 32-разрядных приложений в таких системах существует Wow64 уровень, и приложения работают с 32-разрядной ntdll, остальные системные dll тоже 32-разрядные.
Т.к. x86-64 процессор сам по себе поддерживает x86 режим, то для Wow64 уровня задач не очень много, но он явно делает это:
1. Осуществляет трансляцию между 32битными и 64битными структурами для системных вызовов. Поинтеры там перебить на 64-разрядные, SIZE_T, и т.д.
2. Подсовывает 32-разрядную System32 папку (File System Redirection)
3. Подсовывает 32-разрядные ключи реестра (Registry Redirection)
Переключение в 64-битный режим делается раньше вышеприведенных трансляций.
Про TEB / PEB. Это служебные структуры, используемые, в основном, в User Mode для всевозможных контекстов.
Для быстрого доступа к TEB, его адрес записан в сегментном регистре, для того, чтобы этот быстрый доступ к TEB было удобно сделать высокоуровневым, в одном из полей TEB указатель на себя. Местами TEB используется в реализации служебных функций (там есть поле для GetLastError), местами обращения к нему неявно вставляются компилятором (это Structured Exception Handling и (статический) Thread Local Storage).
В каждом TEB есть указатель на PEB. PEB тоже хранит всяческие служебные контексты, уже для процесса. в поле Ldr хранятся списки загруженных модулей.
Поскольку TEB и PEB такие базовые вещи, что будут нужны и ехешнику непосредственно (SEH, TLS), и используемым в нём 32-разрядным системным модулям, и 64-битной ntdll вместе с Wow64 слоем, и при этом они являются структурами с указателями, в Wow64 процессе нужны отдельно 32-битный и 64-битный TEB/TEB. И они разные. Некоторые поля могут быть только в 64-битном или только в 32-битном TEB/PEB. Ну и из-за специфики Wow64, некоторые служебные поля в этих парных TEB/TEB могут иметь не тот смысл, что в "чистом 32-битном" или "чистом 64-битном".
Важный момент отличия 32-битного и 64-битного PEB: в 32-битном PEB::Ldr хранится список загруженных 32-битных модулей, в 64-битном — список 64-битных, который очень небольшой (64-битная ntdll, три-четыре dllки Wow64 слоя, ну и сам ехешник содержится и в 64-битном, и в 32-битном списке).
Поскольку клиенты NtQueryInformationProcess будут ожидать такой PEB, какой разрядности запрос, ну то есть какой разрядности сами клиенты, их нельзя удовлетворить, если 32-битный клиент спрашивает за 64-битный процесс. Поэтому 32-разрядная NtQueryInformationProcess не возвращает TEB для 64-разрядного процесса.
С учётом всего этого:
1. Смотря что с PEB делать, для Wow64 процесса может быть нужен либо 32-битный, либо 64-битный PEB, либо безразлично. Если нужен конкретный, обычно это 32-битный.
2. С PEB со всеми этими поинтерами в нём удобно работать в контексте процесса, к которому этот PEB относится. Внедрить dll-ку и работать через NtCurrentTeb()->Peb. Тогда для х64 систем нужны две dll-ки, 32-разрядная для 32-разрядных процессов, 64-разрядная для 64-разрядных процессов. В случае интенсивной работы с Ldr единственный нормальный вариант (не будешь же Loader Lock захватывать интерпроцессно).
3. В случае отсутствия надобности лезть в потроха загрузчика, но при этом наличия интенсивной работы с различными NT API, следует использовать 64-разрядный процесс на 64-разрядных системах. Если в итоге нужно, чтобы основное приложение было одно 32-битныое, следует завести вспомогательное 64-битное, и использовать IPC.
4. В принципе "какой-нибудь PEB другого процесса" можно получить из процесса любой разрядности без внедрения dll и без NtQueryInformationProcess. Главный вопрос — что дальше.
ProcessInfo->PebBaseAddress == NULL.