Сообщение Re[3]: NtQueryInformationProcess от 18.08.2017 5:04
Изменено 18.08.2017 5:19 Alexander G
Re[3]: NtQueryInformationProcess
Здравствуйте, Burbulis1978, Вы писали:
B>Предполагается что ответит читатель который реально работал с указанной napi , т.е. имеет практику конкретно под win10.
То есть, имел опыт портирования конкретного примера из CodeProject на Win10 и помнит, что именно с ним было не так ?
Так то функция работает, Windows по-прежнему использует её для внутренних нужд.
А в конкретном примере она может не работать по десяткам разных причин, если более детальной информации нет.
Для того, чтобы опытный читатель смог предположить, что же именно не так, крайне желательно привести, как именно она не работает, например:
1. Какой именно ProcessInformationClass она возвращает?
2. Возвращает ли она не-успешный NTSTATUS (какой именно?)
3. Если успешный NTSTATUS, но выходную структуру не заполняет, или заполняет неожиданным образом, то в чём именно нет соответствия ожиданиям?
4. Если до возврата из неё не доходит, почему? Exception там случается, BSOD ли, или просто нельзя получить её адрес?
Ещё неплохо сформулировать более высокоуровневую задачу. Что от неё в конце-концов нужно.
Имя "ехешника" процесса, как в примере? Уже сто лет как есть GetProcessImageFileName и QueryFullProcessImageName всякие.
Вообще всё, что она может сказать? Тогда да, вызывать её.
B>И знает что делать. В любом случае спасибо что не остались в стороне.
B>Всё как обычно: Знающие не говорят, говорящие не знают.(с) какой-то дядька.
В данном конкретном случае проблема исключительно в постановке вопроса. Так-то знающие могут сказать.
Вот недавно было: вызов 64-битной версии этой вашей NtQueryInformationProcess из 32-битного процесса
Так что прояснить про обычный сраный вызов обычной часто используемой NT API функции читатели уж точно в состоянии.
B>Предполагается что ответит читатель который реально работал с указанной napi , т.е. имеет практику конкретно под win10.
То есть, имел опыт портирования конкретного примера из CodeProject на Win10 и помнит, что именно с ним было не так ?
Так то функция работает, Windows по-прежнему использует её для внутренних нужд.
А в конкретном примере она может не работать по десяткам разных причин, если более детальной информации нет.
Для того, чтобы опытный читатель смог предположить, что же именно не так, крайне желательно привести, как именно она не работает, например:
1. Какой именно ProcessInformationClass она возвращает?
2. Возвращает ли она не-успешный NTSTATUS (какой именно?)
3. Если успешный NTSTATUS, но выходную структуру не заполняет, или заполняет неожиданным образом, то в чём именно нет соответствия ожиданиям?
4. Если до возврата из неё не доходит, почему? Exception там случается, BSOD ли, или просто нельзя получить её адрес?
Ещё неплохо сформулировать более высокоуровневую задачу. Что от неё в конце-концов нужно.
Имя "ехешника" процесса, как в примере? Уже сто лет как есть GetProcessImageFileName и QueryFullProcessImageName всякие.
Вообще всё, что она может сказать? Тогда да, вызывать её.
B>И знает что делать. В любом случае спасибо что не остались в стороне.
B>Всё как обычно: Знающие не говорят, говорящие не знают.(с) какой-то дядька.
В данном конкретном случае проблема исключительно в постановке вопроса. Так-то знающие могут сказать.
Вот недавно было: вызов 64-битной версии этой вашей NtQueryInformationProcess из 32-битного процесса
Автор: ononim
Дата: 09.08.17
.Дата: 09.08.17
Так что прояснить про обычный сраный вызов обычной часто используемой NT API функции читатели уж точно в состоянии.
Re[3]: NtQueryInformationProcess
Здравствуйте, Burbulis1978, Вы писали:
B>Предполагается что ответит читатель который реально работал с указанной napi , т.е. имеет практику конкретно под win10.
То есть, имел опыт портирования конкретного примера из CodeProject на Win10 и помнит, что именно с ним было не так ?
Так то функция работает, Windows по-прежнему использует её для внутренних нужд.
А в конкретном примере она может не работать по десяткам разных причин, если более детальной информации нет.
Для того, чтобы опытный читатель смог предположить, что же именно не так, крайне желательно привести, как именно она не работает, например:
1. Какой именно ProcessInformationClass она возвращает?
2. Возвращает ли она не-успешный NTSTATUS (какой именно?)
3. Если успешный NTSTATUS, но выходную структуру не заполняет, или заполняет неожиданным образом, то в чём именно нет соответствия ожиданиям?
4. Если до возврата из неё не доходит, почему? Exception там случается, BSOD ли, или просто нельзя получить её адрес?
При всём этом отсутствии информации, наиболее вероятное предположение было высказано:
неправильная структура, может выливаться в неожиданное заполнение или нехватку буфера.
Где именно неправильно и что именно — без деталей неясно. Но на стороне спрашивающего эти детали доступны, с ними он вполне может пойти в гугл за праильным определением структуры.
Ещё неплохо сформулировать более высокоуровневую задачу. Что от неё в конце-концов нужно.
Имя "ехешника" процесса, как в примере? Уже сто лет как есть GetProcessImageFileName и QueryFullProcessImageName всякие.
Вообще всё, что она может сказать? Тогда да, вызывать её.
B>И знает что делать. В любом случае спасибо что не остались в стороне.
B>Всё как обычно: Знающие не говорят, говорящие не знают.(с) какой-то дядька.
В данном конкретном случае проблема исключительно в постановке вопроса. Так-то знающие могут сказать.
Вот недавно было: вызов 64-битной версии этой вашей NtQueryInformationProcess из 32-битного процесса
Так что прояснить про обычный сраный вызов обычной часто используемой NT API функции читатели, скорее всего, в состоянии.
B>Предполагается что ответит читатель который реально работал с указанной napi , т.е. имеет практику конкретно под win10.
То есть, имел опыт портирования конкретного примера из CodeProject на Win10 и помнит, что именно с ним было не так ?
Так то функция работает, Windows по-прежнему использует её для внутренних нужд.
А в конкретном примере она может не работать по десяткам разных причин, если более детальной информации нет.
Для того, чтобы опытный читатель смог предположить, что же именно не так, крайне желательно привести, как именно она не работает, например:
1. Какой именно ProcessInformationClass она возвращает?
2. Возвращает ли она не-успешный NTSTATUS (какой именно?)
3. Если успешный NTSTATUS, но выходную структуру не заполняет, или заполняет неожиданным образом, то в чём именно нет соответствия ожиданиям?
4. Если до возврата из неё не доходит, почему? Exception там случается, BSOD ли, или просто нельзя получить её адрес?
При всём этом отсутствии информации, наиболее вероятное предположение было высказано:
неправильная структура, может выливаться в неожиданное заполнение или нехватку буфера.
Где именно неправильно и что именно — без деталей неясно. Но на стороне спрашивающего эти детали доступны, с ними он вполне может пойти в гугл за праильным определением структуры.
Ещё неплохо сформулировать более высокоуровневую задачу. Что от неё в конце-концов нужно.
Имя "ехешника" процесса, как в примере? Уже сто лет как есть GetProcessImageFileName и QueryFullProcessImageName всякие.
Вообще всё, что она может сказать? Тогда да, вызывать её.
B>И знает что делать. В любом случае спасибо что не остались в стороне.
B>Всё как обычно: Знающие не говорят, говорящие не знают.(с) какой-то дядька.
В данном конкретном случае проблема исключительно в постановке вопроса. Так-то знающие могут сказать.
Вот недавно было: вызов 64-битной версии этой вашей NtQueryInformationProcess из 32-битного процесса
Автор: ononim
Дата: 09.08.17
.Дата: 09.08.17
Так что прояснить про обычный сраный вызов обычной часто используемой NT API функции читатели, скорее всего, в состоянии.