Ускорение перечисления процессов и потоков в ОС Windows

    Иногда бывает нужно перечислить все процессы или потоки, которые в данный момент работают в ОС Windows. Это может понадобиться по разным причинам. Возможно, мы пишем системную утилиту вроде Process Hacker, а может быть мы хотим как-то реагировать на запуск/остановку новых процессов или потоков (писать лог, проверять их, внедрять в них свой код). Самым правильным способом это реализовать является, конечно же, написание драйвера. Там всё просто — используем PsSetCreateProcessNotifyRoutine и PsSetCreateThreadNotifyRoutine для установки колбек-функций, которые будут вызываться при запуске/остановке процессов и потоков. Работает очень быстро и не ест ресурсы. Именно так и делают все серьёзные инструменты. Но разрабатывать драйвера — не всегда подходящий способ. Их нужно уметь правильно писать, их с недавних пор обязательно нужно подписывать сертификатами (что не бесплатно) и регистрировать в Microsoft (что не быстро). И ещё их не удобно распространять — например, программы с ними нельзя выкладывать в Microsoft Store.

    Ну, давайте тогда пользоваться тем, что предлагает публичный WinAPI. А предлагает он функцию CreateToolhelp32Snapshot(), которую предлагается использовать как-то вот так. Всё, кажется, хорошо — есть информация о процессах, потоках. Немного расстраивает тот факт, что вместо элегантных колбеков мы вынуждены делать бесконечный пулинг в цикле, но это ладно.

    Самая большая проблема здесь — это производительность. Связка CreateToolhelp32Snapshot() + Process32First() + Process32Next() работает ну очень медленно. Возможно, проблема лежит где-то в той же области, что и описанная вот в этой статье проблема с Heap32First() + Heap32Next(). Кратко — в силу исторических причин кое-где проход по линейному списку занимает квадратичное время.

    Можно ли как-то всё это ускорить? Можно. Но придётся сойти со светлого пути использования одних лишь публичных функций WinAPI.

    Долгое время я считал, что функции WinAPI делятся на публичные (описанные в MSDN, допустимые для использования) и недокументированные (найденные при реверс-инжиниринге системных библиотек, не описанные в MSDN, не поддерживаемые официально). Этот черно-белый мир казался мне простым и логичным: для публичных продуктов используем публичные функции, для личных учебных целей, утилит, внутренних инструментов — можно пытаться использовать и недокументированные.

    Но оказалось, что между этими мирами есть и серая зона. Это функции, которые описаны в MSDN (это делает их похожими на публичные), но Microsoft сообщает, что может изменить или удалить их в любой момент (как недокументированные). Почему такие функции существуют? Всё просто — с одной стороны их польза слишком велика, чтобы её прятать, но с другой стороны у будущих версий ОС могут возникнуть внутренние причины их изменить. Такие функции в одной из встреченных мною терминологий называются «приватными». Пример — NtQuerySystemInformation().

    Оцените первую строчку в документации — «NtQuerySystemInformation may be altered or unavailable in future versions of Windows. Applications should use the alternate functions listed in this topic» — при этом для половины описанных применений этих самых «альтернативных функций» и не описано. Можно ли пользоваться такими функциями? Каждый решает это для себя сам. Лично мне кажется, что «волков бояться — в лес не ходить». Как-будто любая другая функция в MSDN гарантированно никогда не станет «altered or unavailable in future versions of Windows». Любой код нуждается в проверке на новых версиях ОС. Любой код нуждается в поддержке и адаптации. И если есть функция, которая вот сейчас работает и приносит пользу, то почему бы её не использовать?

    А NtQuerySystemInformation приносит существенную пользу. Вот график роста производительности, который получила библиотека MHook при переходе с CreateToolhelp32Snapshot() на NtQuerySystemInformation():

    image

    Как использовать NtQuerySystemInformation()? Очень просто:

    1. Ищем функцию «NtQuerySystemInformation» в библиотеке «ntdll.dll». Теоретически её там может и не найтись, но на практике на всех версиях ОС от Vista до Win10 она есть точно. Не уверен на счёт XP (не было возможности и необходимости проверить)
    2. Выделяем память для буфера с результатами
    3. Вызываем функцию с параметром SystemProcessInformation
    4. Обходим результаты, перемещаясь между записями для отдельных процессов с использованием значения «NextEntryOffset» из структуры описания текущего процесса.
    5. Не забываем освободить память, выделенную на шаге №2

    Примеры кода можно найти здесь или здесь.

    Лично мне с помощью перехода с CreateToolhelp32Snapshot() на NtQuerySystemInformation() удалось в одном достаточно ресурсоёмком сценарии выиграть около 2% общей загрузки процессора, что достаточно много.

    Мораль этой истории в том, что медленная работа WinAPI функции не всегда является окончательным приговором. Операционная система — большая и сложная штука, в ней вполне может оказаться другой способ получения нужной информации.
    • +30
    • 15,4k
    • 5

    Инфопульс Украина

    271,61

    Creating Value, Delivering Excellence

    Поделиться публикацией
    Комментарии 5
      0
      Nt* — это всё же не серая зона, а просто native functions, уровнем выше, docs.microsoft.com/en-us/windows-hardware/drivers/kernel/ntxxx-routines.

      Как вариант ещё на посмотреть — а что, если копнуть дебагером в sysinternals process monitor/explorer?

      Честно говоря, я ещё помню, когда те тулзы были с каким-то кодом открытым, но не сейчас. Сейчас пипл что-то «на стороне» пишет, типа github.com/processhacker/processhacker
        0
        В procmon всегда драйвер был (его хвосты при закрытом procmon всякие темиды палят).
        0
        Странная статья, вещающая об очевидных (разница в скорости за счёт оверхеда) и вполне известных вещах (NtQuerySystemInformation юзалась ещё во времена Win 2000, если ничего не путаю).
          +3
          Понятие «вполнеизвестности» — очень растяжимо. Вот тут было представлено открытие особой важности: как числа в Little Endian в памяти хранятся.

          Так что по уровню велосипедистости — статья среднего уровня…
            0
            Не программирую под windows, но было интересно прочитать

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое