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 еще можно получить NtQueryProcess(ProcessImageFileName). Или GetMappedFileName на PEB::ImageBaseAddress.
Забавный факт состоит в том, что если процесс использует всякие лоадеры/протекторы, то все эти методы могут дать разные результаты

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.
Забавный факт состоит в том, что если процесс использует всякие лоадеры/протекторы, то все эти методы могут дать разные результаты