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а и все структуры к нему относящиеся придется кропотливо вручную дефайнить.