DbgShell

Интерфейс PowerShell для отладчика Windows.

Готовы табулировать свой путь к успеху? Для быстрого знакомства посмотрите Начало работы.

Отказ от ответственности

1. Этот проект не создан, не одобрен и не контролируется командой отладчика Windows.
   Команда отладчика приветствует обратную связь по своему API и интерфейсам (windbg, kd и др.), но они не имеют никакого отношения к этому проекту. Не отправляйте ошибки или отзывы команде отладчика касательно этого проекта.

2. Это не финансируемый проект: ему не выделены официальные ресурсы, над ним работают только добровольцы. Не берите на себя производственные зависимости от этого проекта, если вы не готовы полностью поддерживать его самостоятельно. Не стесняйтесь оставлять Issues и отправлять Pull Requests, но имейте в виду, что из-за ограниченных волонтёрских ресурсов обработка ваших вкладов может занять некоторое время.

3. Это экспериментальный проект: он не до конца проработан, и вы должны ожидать, что критические изменения будут вноситься часто.

Следствие из вышеуказанных отказов: я бы избегал подключения DbgShell к живым целям высокой ценности.

Бинарные файлы

https://aka.ms/dbgshell-latest

Мотивация

Вы когда-нибудь пытались автоматизировать что-то в отладчике? (cdb/ntsd/kd/windbg) Как успехи?

Основная движущая сила DbgShell — это то, что автоматизировать что-либо в отладчике слишком сложно. Конечно, на сегодняшний день существуют средства для автоматизации отладчика. Но, на мой взгляд, они не удовлетворяют потребностям людей.

• Использование встроенного языка сценариев — это архаично, ограниченно, трудно сделать правильно и сложно получить помощь.
• Написание полноценной DLL расширения отладчика — это очень мощно, но это значительная инвестиция — слишком дорого для быстрых «одноразовых» задач при отладке случайных реальных проблем. Несмотря на затраты, существует огромное количество расширений отладчика. Я считаю, что их не должно быть так много; единственная причина, по которой их так много, — отсутствие жизнеспособных альтернатив.
• Существующие попытки предоставить лучший интерфейс (например, PowerDbg) основаны на «скрапинге» и текстовом анализе, что крайне ограничивает (не говоря уже об идеологической раздражающей сути) и поэтому они не могут выполнить обещание действительно лучшего интерфейса (в лучшем случае они лишь немного лучше).
• Существующие попытки упростить написание расширения отладчика — это лишь временная мера, решающая боль разработки расширения; они не решают более крупную проблему. (например, два основных недостатка: они всё ещё слишком низкоуровневые (приходится работать с COM API dbgeng), и нет REPL)
• Команда отладчика недавно представила скриптинг на JavaScript. JavaScript — гораздо лучший (и более чётко определённый) язык, чем старый язык сценариев windbg, но я считаю, что PowerShell имеет некоторые преимущества, самое большое из которых — никто на самом деле не использует оболочку JavaScript — PowerShell гораздо лучше как комбинированная оболочка и язык сценариев.

Цель проекта DbgShell — принести все преимущества объектно-ориентированного мира PowerShell в мир отладки. Когда вы выполняете 'dt' для дампа 'объекта', вы должны получить реальный объект. Скриптинг должен быть таким же простым, как написание скрипта PowerShell.

Проект DbgShell предоставляет интерфейс PowerShell для dbgeng.dll, включая:

• управляемую "объектную модель" (используемую из C#, если хотите), которая является более высокоуровневой, чем COM API dbgeng,
• "провайдер навигации" PowerShell, который предоставляет аспекты цели отладки в виде иерархического пространства имён (так что можно "cd" к определённому потоку, ввести "dir" для просмотра стека, "cd" в кадр, снова выполнить "dir" для просмотра локальных переменных/регистров и т.д.),
• командлеты для управления целью,
• пользовательский хост PowerShell, который обеспечивает лучший контроль над CLI-интерфейсом отладчика, а также предоставляет функции, недоступные в стандартном хосте powershell.exe (а именно, поддержка цветовой раскраски текста с использованием управляющих последовательностей ANSI (в соответствии с ISO/IEC 6429)).

Пользовательский хост по-прежнему является программой на основе командной строки (conhost.exe) (аналогично ntsd/cdb/kd), но его можно вызвать из windbg (!DbgShell).

Помимо значительного упрощения и расширения возможностей автоматизации, он будет решать и другие проблемы, такие как удобство использования для людей, которым не приходится часто использовать отладчики. (одна из жалоб, которую я слышал: «когда мне в конце концов приходится использовать windbg, я провожу всё время в .CHM»)

Для опытных пользователей windbg, с другой стороны, ещё одна цель — сделать переход максимально плавным. Так, например, провайдер пространства имён — не единственный способ доступа к данным; вы по-прежнему можете использовать традиционные команды, такие как "~3 s", "k" и т.д.

Что вы имеете в виду под «автоматизацией» и «скриптингом»?

Я имею в виду не только то, когда вы открываете текстовый редактор и пишете большой скрипт для выполнения чего-то сложного — я также имею в виду возможность создавать относительно простые вещи прямо в командной строке. Есть много ситуаций, когда вам хотелось бы использовать немного логики, но это не настолько большое или повторно используемое, что вы захотели бы его сохранять. Должно быть легко создавать «однострочники» вроде «остановиться на CreateFile, если открываемый файл находится на рабочем столе пользователя, а функция Blah находится в стеке».

Почему PowerShell?

Позвольте мне внести ясность: мне потребовалось примерно 4 года, чтобы «согреться» к PowerShell. Я считаю, что у него есть острые углы, аспекты, которые просто сложны, и множество ошибок как в дизайне, так и в реализации. Иногда это меня очень раздражает. Однако преимущества PowerShell убедительны и убедили меня, что это лучший выбор для этого проекта: