Как выполнять команды WinDbg через регулярные интервалы?

Question

Я хотел бы выполнять некоторые команды в WinDbg через регулярные промежутки времени, например. каждую минуту. В этом конкретном случае я хотел бы получить статистику обработки (!handle) и статистику объекта .NET (!dumpheap -stat) для построения графика. В качестве обходного пути я использую procdump и создаю дамп каждую минуту, но для этого требуется много места на жестком диске (полный мини-накопитель для .NET), и мне нужно проанализировать все дампы позже (автоматизировано с помощью скриптов).

Как я могу выполнять команды WinDbg через равные промежутки времени?

Предположения: Режим работы пользователя в режиме реального времени. Целевое приложение работает все время. Команда заканчивается на ;g, так что она будет продолжать работать после выполнения команды. Сроки не должны быть точными, особенно время выполнения команды не имеет значения.

Прежде чем приступить к реализации собственного отладчика с помощью механизма отладчика, я подумал, что могу спросить, возможно ли это с помощью самого WinDbg.

Answer 1

Вы можете использовать WMemoryProfiler, который предоставляет класс MDbg (управляемый отладчик, который в основном является Windbg + SOS Loaded) и использует управляемое приложение для управления отладчиком и выполнения comamnds на нем.

Или вы используете ClrMD, что позволяет выполнять команды SOS без Windbg в реальном процессе из управляемого процесса, который также поддерживается в будущем.

Чтобы найти утечки ручек, я использовал альтернативный маршрут. Вы можете подключить вызовы Api, которые выделяют и освобождают дескрипторы (e..g EasyHook, чтобы подключить любой Api с управляемым кодом). В вашем крюке вы можете затем выпустить событие ETW, которое можно активировать, например. через xperf инструментария производительности Windows. Холодность этого подхода заключается в том, что вы можете зарегистрировать свое событие ETW, чтобы дескриптор выделил и освободил звонки, и получите файл журнала, который вы можете проанализировать, чтобы найти непогашенные вызовы, которые являются вашими утечками. Поскольку я регистрировал его через событие ETW, я получаю полные стеки вызовов из ядра в метод RtlThreadStart, включая полный стек управляемых вызовов, который намного полезнее, если вы отслеживаете утечки дескриптора в управляемых приложениях. Например, что вы можете сделать с ним, проверьте this. Этот подход является лучшим, что я нашел до сих пор, потому что он не замедляет работу приложения, как Windbg, и вы можете контролировать свое приложение, в основном, ударяя очень долгое время.