Сообщение Re: Поймать TerminateProcess для своего приложения от 22.02.2019 10:32
Изменено 22.02.2019 12:13 EreTIk
Re: Поймать TerminateProcess для своего приложения
Здравствуйте, _agg, Вы писали:
_>привет всем, понадобилось в момент когда из диспетчера задач вызывают снять задачу записать в лог сообщение об этом, пытался вот так:
_>Это поточная функция, которая как мне казалось должна поймать TerminateProcess вызываемый для моего процесса диспетчером задач, но увы и поэтому прошу помощи у знающих людей как же правильно это сделать?
Как справедливо сказано выше, процесс станет сигнальным объектом, когда уничтожится, то есть перестанет иметь исполняющиеся нити.
Почему этот код должен срабатывать только при уничтожении процесса из диспетчером задач? Как это будет отличаться от других случаев:
Если интересует именно вызов TerminateProcess, то в Windows 10 (а скорее всего и и на более старых версиях) в отдельном процессе можно следить за ETW-событиями, которые логируют вызов TerminateProcess одного процесса для другого:
Но сразу надо учесть, что:
P.S. Зачем вокруг логирования ошибки открытия процесса городить while (false)? В боевом коде после if (!hProcess) есть еще код, который не попал в приведенный пример?
_>привет всем, понадобилось в момент когда из диспетчера задач вызывают снять задачу записать в лог сообщение об этом, пытался вот так:
| Скрытый текст | |
_>_>t2f::T2F — пишет лог _>err::GetErrMsg() — вызывает GetLastError и форматирует сообщение из полученной ошибки | |
_>Это поточная функция, которая как мне казалось должна поймать TerminateProcess вызываемый для моего процесса диспетчером задач, но увы и поэтому прошу помощи у знающих людей как же правильно это сделать?
Как справедливо сказано выше, процесс станет сигнальным объектом, когда уничтожится, то есть перестанет иметь исполняющиеся нити.
Почему этот код должен срабатывать только при уничтожении процесса из диспетчером задач? Как это будет отличаться от других случаев:
- не диспетчером задач, а другой внешний процесс, например — антивирус, завершает процесс?
свой же процесс внутри системного или библиотечного кода (по зависимостям) вызывает одну из функций, завершающей процесс?
необработанное исключение внутри процесса приводит к завершению процесса?
процесс сам завершился "штатно"? Если важно отделить только это событие и сейчас в этой точке завершается нить с приведенным кодом, то тогда может пойти от обратного: в месте завершения нити залогировать "штатный" выход, а если нет такой записи в логе, то считать что произошла непредусмотренная ситуация уничтожения процесса?
Если интересует именно вызов TerminateProcess, то в Windows 10 (а скорее всего и и на более старых версиях) в отдельном процессе можно следить за ETW-событиями, которые логируют вызов TerminateProcess одного процесса для другого:
| PspLogAuditTerminateRemoteProcessEvent | |
| |
Но сразу надо учесть, что:
- taskmgr, помимо TerminateProcess, вызывает EndTask, что приведет к RPC-вызову csrss, который уже и будет непосредственным инициатором вызова TerminateProcess.
не TerminateProcess'ом единым можно заставить процесс умереть: 12 ways to terminate a process.
P.S. Зачем вокруг логирования ошибки открытия процесса городить while (false)? В боевом коде после if (!hProcess) есть еще код, который не попал в приведенный пример?
Re: Поймать TerminateProcess для своего приложения
Здравствуйте, _agg, Вы писали:
_>привет всем, понадобилось в момент когда из диспетчера задач вызывают снять задачу записать в лог сообщение об этом, пытался вот так:
_>Это поточная функция, которая как мне казалось должна поймать TerminateProcess вызываемый для моего процесса диспетчером задач, но увы и поэтому прошу помощи у знающих людей как же правильно это сделать?
Как справедливо сказано выше, процесс станет сигнальным объектом, когда уничтожится, то есть перестанет иметь исполняющиеся нити.
Почему этот код должен срабатывать только при уничтожении процесса из диспетчером задач? Как это будет отличаться от других случаев:
Если интересует именно вызов TerminateProcess, то в Windows 10 (а скорее всего и и на более старых версиях) в отдельном процессе можно следить за ETW-событиями, которые логируют вызов TerminateProcess одного процесса для другого:
Но сразу надо учесть, что:
P.S. Зачем вокруг логирования ошибки открытия процесса городить while (false)? В боевом коде после if (!hProcess) есть еще код, который не попал в приведенный пример?
_>привет всем, понадобилось в момент когда из диспетчера задач вызывают снять задачу записать в лог сообщение об этом, пытался вот так:
| Скрытый текст | |
_>_>t2f::T2F — пишет лог _>err::GetErrMsg() — вызывает GetLastError и форматирует сообщение из полученной ошибки | |
_>Это поточная функция, которая как мне казалось должна поймать TerminateProcess вызываемый для моего процесса диспетчером задач, но увы и поэтому прошу помощи у знающих людей как же правильно это сделать?
Как справедливо сказано выше, процесс станет сигнальным объектом, когда уничтожится, то есть перестанет иметь исполняющиеся нити.
Почему этот код должен срабатывать только при уничтожении процесса из диспетчером задач? Как это будет отличаться от других случаев:
- не диспетчером задач, а другой внешний процесс, например — антивирус, завершает процесс?
свой же процесс внутри системного или библиотечного кода (по зависимостям) вызывает одну из функций, которая завершает текущий процесс?
необработанное исключение внутри процесса приводит к завершению процесса?
процесс сам завершился "штатно"? Если важно отделить только это событие и сейчас в этой точке завершается нить с приведенным кодом, то тогда может пойти от обратного: в месте завершения нити залогировать "штатный" выход, а если нет такой записи в логе, то считать что произошла непредусмотренная ситуация уничтожения процесса?
Если интересует именно вызов TerminateProcess, то в Windows 10 (а скорее всего и и на более старых версиях) в отдельном процессе можно следить за ETW-событиями, которые логируют вызов TerminateProcess одного процесса для другого:
| PspLogAuditTerminateRemoteProcessEvent | |
| |
Но сразу надо учесть, что:
- taskmgr, помимо TerminateProcess, вызывает EndTask, что приведет к RPC-вызову csrss, который уже и будет непосредственным инициатором вызова TerminateProcess.
не TerminateProcess'ом единым можно заставить процесс умереть: 12 ways to terminate a process.
P.S. Зачем вокруг логирования ошибки открытия процесса городить while (false)? В боевом коде после if (!hProcess) есть еще код, который не попал в приведенный пример?