Задачи отладки x64: от журнала сбоя до проверенного исправления

Что делает StatusRivet

• Файлыread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep и glob работают внутри рабочей папки чата, а счётчик показывает количество созданных, изменённых и прочитанных файлов.
• Shellзапускает сборки, линтеры, тесты и командную строку вашего отладчика в Windows, WSL или по SSH на сервере, которым вы владеете; успех определяется реальным кодом выхода, а опасные команды блокируются.
• Вебweb_search находит страницы, а http_get читает одну страницу официальной документации, например, чтобы узнать значение кода исключения перед тем, как действовать.
• Скриншоты и изображенияocr считывает текст с сохранённого скриншота, например, диалога ошибки, а gen_image сохраняет реальные файлы изображений.
• Оркестрацияtask запускает параллельные подагенты, run_on_model отправляет сложный шаг более крупной модели, а skill хранит повторно используемые сценарии, включая контроль версий.
• Режимы одобренияAuto-run действует немедленно, Ask first приостанавливается перед действиями, изменяющими что-либо, а Plan only записывает план и ничего не запускает.
• Cronзапускает промпт по расписанию, например, запуск тестов на лабораторной машине, а результат появляется в чате так же, как и любое другое действие, с теми же карточками и тем же выводом.
• Моделиоблачный ИИ-провайдер через стандартную конечную точку API, модель на вашем ПК или встроенная модель; кнопка Test проверяет конечную точку и показывает время отклика и размер контекстного окна.

Четыре задачи отладки по шагам

Чтение стека вызовов при сбое

Задача: ваше приложение упало на тестовой машине, и у вас есть стек вызовов, который ваш x64-отладчик сохранил в текстовом виде. read_file загружает stack.txt, а grep ищет код исключения в журнале, например 0xC0000005 для нарушения доступа. Затем агент перечисляет верхние кадры потока, вызвавшего сбой, и открывает исходный файл, соответствующий первому кадру. Каждое действие появляется в чате в виде карточки, и вы можете развернуть карточку, чтобы прочитать полный вывод. Если при загрузке bsod оставляет запись об ошибке 41 в журнале событий, дамп, созданный в это время (если он есть), содержит нужное состояние. Начинайте с начала. Прочитайте кадры самостоятельно, так как агент работает на основе текстового вывода, затем примите или отклоните предлагаемый diff в режиме Ask first.

Исправление переполнения стека

Задача: в журнале показан код исключения 0xC00000FD, означающий переполнение стека, и вы хотите найти функцию, которая вызвала рекурсию. grep ищет в исходном коде имя функции из верхних кадров, а read_file открывает его, чтобы агент увидел, как заканчивается рекурсия. edit_file предлагает минимальный diff, например, недостающее условие остановки, и показывает, какие именно строки изменятся. Затем Shell запускает команду сборки и команду тестирования, и каждая карточка сообщает реальный код выхода. bsod с кодом остановки управления памятью — это другой вид сбоя, но метод тот же: найдите исключение, прочитайте стек, тестируйте одно изменение за раз. Делайте каждое изменение небольшим. Просмотрите diff и результат тестирования перед тем, как сохранить что-либо, и запустите тест ещё раз после финального редактирования.

Проверка настройки JIT-отладки

Задача: прежде чем полагаться на отладчик во время сбоя, проверьте значение JIT-отладки на тестовой машине. JIT означает just-in-time: Windows автоматически запускает отладчик при сбое приложения, и это системная настройка. Shell выполняет команду, которую вы ему даёте, для чтения текущего значения, а write_file сохраняет это значение в settings-before.txt, чтобы старое значение было записано. Изменяйте его только на тестовой машине, никогда на вашем основном ПК, и восстановите сохранённое значение afterwards. В режиме Ask first агент приостанавливается перед каждым действием, изменяющим что-либо, так что вы отдельно одобряете изменение и восстановление. Запишите значение. Прочитайте сохранённый файл перед началом и прочитайте его снова перед восстановлением значения.

Отладка драйвера на лабораторной цели

Задача: драйвер, который вы написали, вызывает сбой тестовой цели, и вам нужно найти функцию, вызвавшую сбой. Работа на уровне ядра обычно требует двух машин или виртуальной машины: одна с отладчиком, другая как тестовая цель, соединённых отладочным соединением, а цель остаётся в лаборатории. Shell выполняет команды по SSH на лабораторной машине, которой вы владеете, read_file читает текст, сохранённый отладчиком, а grep сопоставляет имя модуля с вашим исходным кодом. На новом компьютере bsod с нарушением таймаута dpc может быть вызван драйвером, который вы пишете, поэтому стек зависшего потока — это первое, что нужно прочитать. Держите её в лаборатории. Вы проверяете каждое найденное значение перед тем, как изменить строку, и запускаете тест на цели снова afterwards.