Согласно документация, ContinueDebugEvent закроет дескрипторы после EXIT_THREAD_DEBUG_EVENT и EXIT_PROCESS_DEBUG_EVENT.
Что происходит с этими ручками в следующем случае:
DebugSetProcessKillOnExit(FALSE); // Keep the process running after stopping the debugger.
DebugActiveProcessStop(dwProcessId);
Процесс и потоки по-прежнему будут работать, а документация ничего не упоминает о дескрипторах. Могу я предположить, что они для меня закроются?





да, DebugActiveProcessStop вызывает CloseAllProcessHandles перед фактической остановкой отладки через вызов DbgUiStopDebugging. CloseAllProcessHandles закрывает все открытые потоки и дескрипторы процессов. его список хранится в потоке TEB - это означает, что вызов должен выполняться только из того же потока, который вызывает другой api отладки (например, WaitForDebugEvent). К сожалению, я также не вижу подтверждения этого в документации, только исследования. этот скриншот из win10
@ user1000039 - это трюки с ручками, реализация DebugActiveProcess (которая создает поток в отлаживаемом процессе), невозможность комбинировать ожидание отладочных событий и сообщений графического интерфейса одновременно - причина, по которой я лично не использую Win32 debug api, а DbgUi api
@ user1000039 - также в Статья о внутренней отладке в пользовательском режиме заметка Alex Ionescu о CloseAllProcessHandles. но я не документация msdn для этого
Подтверждено на Win10. Легко проверяется с помощью: Получить дескриптор во время события CREATE_PROCESS_DEBUG_EVENT (DebugEvent->u.CreateProcessInfo.hProcess), которое отправляется сразу после DebugActiveProcess(). Затем попробуйте CloseHandle() перед DebugActiveProcessStop(), и он вернет OK. Но попробуйте вызвать его после, и он вернет false с ошибкой «handle invalid». Так я понял, что это вообще происходит!
@MaximPaperno - я лично предпочитаю использовать собственный api, DbgUi* для отладчика. он не делает ненужных вещей (например, создает новый поток, если он связан с активным процессом), управляет дескрипторами и т. д.
Интересный. Я полагаю, вы имеете в виду использование NTDLL? Кажется, трудно найти на нем много информации. openrce.org/articles/full_view/25 и undocumented.ntinternals.net/UserMode/Undocumented%20Functio ns /…. В моем конкретном случае использования, похоже, не хватает эквивалента OUTPUT_DEBUG_STRING_EVENT (просто нужно прослушать какой-то OutputDebugString() запущенного стороннего процесса).
@MaximPaperno - DbgExceptionStateChange с кодом исключения DBG_PRINTEXCEPTION_WIDE_C или DBG_PRINTEXCEPTION_C, это отладочная печать (внутренне DbgPrint / OutputDebugStrings), вызовите это исключение
Жаль, что это не задокументировано, но, похоже, это ответ. Спасибо!