Time Travel Debugging — записывать и перематывать ошибки, которые не воспроизводятся в долгоживущих приложениях

«Падает раз в месяц, только глубокой ночью.» «Та же операция на моей машине никогда не воспроизводится.» «Дамп получили, но по месту сбоя не понять, почему значение стало таким.» Среди расследований ошибок долгоживущих приложений Windows именно эти случаи съедают больше всего времени. В более ранней статье «Как читать аварийные дампы в WinDbg + SOS — практика анализа после сбора» мы смотрели, как читать аварийный дамп, который является одной фотографией. Эта статья продолжает оттуда и покрывает инструмент для ситуаций, где фотографии недостаточно: Time Travel Debugging (TTD).

TTD — функция WinDbg, которая записывает всё исполнение процесса и позволяет позже воспроизвести его вперёд и назад. Вместо того чтобы снова и снова пытаться воспроизвести ошибку, можно «перемотать» сеанс отладчика.¹ Читатели — разработчики и сопровождающие приложений Windows, .NET и C++, которые уже прошли свою долю расследования дампов и журналов и всё ещё имеют случаи, до причины которых не доходят. Предпосылка среды — Windows 10/11 или Windows Server 2016 или новее с текущим WinDbg, и запись требует прав администратора.¹² Сложность средняя.

Предпосылки этой статьи

1. Сначала вывод

• Дамп сохраняет «состояние»; TTD сохраняет «путь». Официальная документация указывает, что дампы склонны упускать состояние и путь исполнения, которые привели к сбою.¹ Если фотография момента сбоя не говорит причину, дальше нужны не ещё фотографии, а запись.
• Запись тяжела. Во время записи целевой процесс работает в 5–20 раз медленнее или хуже, а файл трассировки растёт на 5–50 МБ в секунду, пока процесс активен, без потолка.²⁴ Это не инструмент, который безусловно прикрепляют к долгоживущему приложению.
• Для долгоживущих приложений проектируйте «что записывать». Глава 5 покрывает четыре входа, которые даёт TTD.exe: -ring/-maxFile (оставлять только последние N МБ), -module (записывать только пока исполняется свой модуль), -recordmode Manual (пусть приложение задаёт интервал записи) и -monitor (записывать каждый запуск).²
• Воспроизведение крутится вокруг трёх вещей: позиций (!tt), событий (dx @$curprocess.TTD.Events) и запросов (TTD.Calls / TTD.Memory). Сочетайте ba (точку останова по доступу) с g- (обратным исполнением), и отладчик напрямую отвечает «кто последним записал это значение?».⁵
• Трассировка содержит содержимое памяти. Туда могут входить персональные и конфиденциальные сведения вроде путей файлов, данных реестра и содержимого памяти и файлов.¹ Проектируйте обмен и хранение как для конфиденциального файла.
• Знайте, чего TTD не умеет, прежде чем начинать. Нельзя записывать режим ядра, нельзя внедряться в защищённые процессы (PPL), нельзя самому отсоединиться после прикрепления, и во время воспроизведения нельзя менять память.³²

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 32, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Где дампа недостаточно

Аварийный дамп — копия памяти и регистров в момент, когда процесс упал (или его остановили). Как описано в статье об анализе SOS, !clrstack показывает, где упало, а !dumpheap -stat — что поедает кучу. Чего он не показывает — что произошло по пути к этому состоянию.

flowchart TB
    accTitle: Что фиксирует дамп и что фиксирует TTD
    accDescr: Аварийный дамп фиксирует только состояние в момент сбоя, а не путь, который к нему привёл. TTD сохраняет всё исполнение инструкций от начала записи до конца, поэтому путь сохраняется вместе с состоянием
    dump["Аварийный дамп: состояние в момент сбоя"] --> q1["Не показывает, почему значение стало таким"]
    ttd["Трассировка TTD: исполнение инструкций записанного интервала"] --> q2["Можно вернуться к позиции, где значение записали"]
    q1 -.-> gap["Этот разрыв и затягивает расследования долгоживущих приложений"]

Рис. 1: Дамп — это состояние, TTD — путь. В ошибках долгоживущих приложений обычно нужен второй.

Типичные случаи выглядят так.

• Одно поле структуры в куче держит невозможное значение. Дамп показывает испорченное значение, но не кто его записал и когда.
• Место исключения известно, но не ясно, почему переданный аргумент был неверным. Поднимаясь выше по вызывающим, функция, которая по пути произвела значение, уже нет на стеке.
• Хендлы или память растут в течение месяца. Один дамп может сказать только «растёт»; пути вызовов, который это вырастил, нет.

flowchart TB
    accTitle: Что дамп упускает в типичных долгоживущих случаях
    accDescr: Испорченное значение зафиксировано, но не кто его записал; позиция исключения зафиксирована, но функции, которая произвела аргумент, уже нет на стеке; рост ресурса зафиксирован, но не путь, который его вырастил; три вида случаев разделяют это
    c1["Испорченное поле"] --> m1["Нет записи, кто и когда записал"]
    c2["Исключение на неверном аргументе"] --> m2["Функции, которая произвела значение, уже нет на стеке"]
    c3["Ресурс, который растёт месяц"] --> m3["Нет записи пути вызовов, который его вырастил"]
    m1 --> same["Общее: состояние есть, пути нет"]
    m2 --> same
    m3 --> same

Рис. 2: Во всех трёх случаях «состояние есть, пути нет». Больше фотографий путь не заполняют.

Документация Microsoft сравнивает сильные и слабые стороны методов расследования так.¹

Есть ещё одно важное свойство, на которое указывает официальный обзор TTD. Когда отладчик останавливается в точке отказа, эта точка часто находится внутри кода обработки ошибок на несколько шагов дальше настоящей причины.⁵ Дамп всегда снимается в этой позиции «на несколько шагов позже». С TTD оттуда можно шагнуть назад по одной инструкции.

flowchart TB
    accTitle: Разрыв между точкой отказа и настоящей причиной
    accDescr: Точка отказа, где снимается дамп, часто находится внутри обработки ошибок на несколько шагов дальше настоящей причины, и с TTD можно перемотать от этой точки инструкция за инструкцией обратно к причине
    cause["Настоящая причина (инструкция, которая испортила значение)"] --> steps["Несколько шагов вперёд"]
    steps --> fail["Точка отказа (исключение, обработка ошибок)"]
    fail -->|"Дамп"| photo["Здесь фиксируется"]
    fail -->|"TTD"| back["Назад через p- / t- / g-"]
    back --> cause

Рис. 3: Дамп заморожен в точке отказа. TTD может пройти от точки отказа обратно к причине.

3. Как устроен TTD и чем приходится платить

3.1 Что записывается

TTD внедряет движок записи в целевой процесс и записывает исполненные инструкции, инструкция за инструкцией. Словами официальной документации, он «кодирует полную трассировку на уровне инструкций в среднем менее чем в один байт на инструкцию»; на практике это попадает в диапазон от одного бита до одного байта на инструкцию. Программы, которые исполняют мало видов функций и обрабатывают мало данных, дают меньшие трассировки; наоборот — большие.²⁴

Запись даёт два файла.¹

flowchart TB
    accTitle: Поток от записи TTD к воспроизведению
    accDescr: Движок записи внедряется в целевой процесс и исполнение инструкций записывается в файл .run; когда WinDbg открывает .run, он создаёт индекс .idx и воспроизводит вперёд и назад через позиции, события и запросы
    proc["Целевой процесс"] --> inj["Внедрение движка записи (TTDRecordCPU)"]
    inj --> run[".run (запись исполнения инструкций)"]
    run --> open["Открыть в WinDbg"]
    open --> idx["Сгенерировать .idx (индекс)"]
    idx --> play["Воспроизвести вперёд и назад через позиции, события и запросы"]

Рис. 4: Записывают TTD.exe или WinDbg; читает WinDbg. Достаточно делиться только файлом .run.

Время внутри файла .run выражается как «позиция» (position). Форма — два шестнадцатеричных числа, разделённых двоеточием, например 12:0 или 1A0:12F; первая половина — номер секвенирования (соответствует событию секвенирования), вторая — приблизительное число инструкций с этого события.⁶ FFFFFFFFFFFFFFFE:0 означает конец трассировки.⁷ Позиции выходят на первый план в главе 6.

flowchart TB
    accTitle: Как выражаются позиции в трассировке
    accDescr: Позиция — шестнадцатеричный номер секвенирования и счётчик шагов, разделённые двоеточием; начало около 0, конец выражается как FFFFFFFFFFFFFFFE:0, и можно также перейти к приблизительной позиции по проценту
    pos["Позиция xx:yy (шестнадцатеричная)"] --> seq["xx: номер секвенирования"]
    pos --> step["yy: инструкции с этого события"]
    seq --> tail["Конец — FFFFFFFFFFFFFFFE:0"]
    step --> pct["Проценты вроде !tt 50 тоже работают"]

Рис. 5: Позиция — это «номер события:число инструкций». Это не настенные часы, но в главе 6 показано, как перевести её в реальное время.

3.2 Цена

Сама официальная документация описывает TTD как «инвазивную технологию».² Цена в цифрах.

flowchart TB
    accTitle: Цена записи и её влияние на долгоживущие приложения
    accDescr: Замедление во время записи, рост файла, тихое ожидание при исчерпании диска и невозможность отсоединиться после прикрепления — четыре цены, из-за которых нельзя безусловно прикрепить TTD к долгоживущему приложению
    cost["Запись TTD"] --> slow["В 5–20 раз медленнее"]
    cost --> grow["Растёт на 5–50 МБ в секунду, без потолка"]
    cost --> disk["Тихо ждёт, когда диск исчерпан"]
    cost --> stuck["После прикрепления нельзя отсоединиться"]
    slow --> no["Безусловная постоянная запись невозможна"]
    grow --> no
    disk --> no
    stuck --> no

Рис. 6: Любая из четырёх цен сама по себе исключает постоянную запись. Поэтому нужно «проектирование записи» главы 5.

3.3 Чего оно не умеет

• Только пользовательский режим. Записывается только пользовательское исполнение процесса; код, который исполняется в режиме ядра, например драйверы, отладить нельзя.³
• Защищённые процессы. TTD не может внедриться в защищённые процессы Windows вроде Protected Process Light (PPL).³
• Воспроизведение только для чтения. Можно вернуться в прошлое, но историю изменить нельзя. Команды, которые читают память, работают; команды, которые её меняют, — нет.³
• Несовместимость с антивирусом и ПО мониторинга памяти. Поскольку TTD ставит хуки в процесс, он конфликтует с ПО, которое отслеживает или зеркалирует системные вызовы к памяти. Если запись даёт ошибку, похожую на недостаток прав, временно отключите такое ПО, чтобы локализовать проблему. Фреймворк Electron — известный конфликт; даже если запись удалась, целевой процесс может зайти в взаимную блокировку или упасть.³
• Приложения UWP нельзя запустить и записать (прикрепиться к уже работающему приложению UWP можно). «Необычные процессы», работающие в другом сеансе или другом контексте безопасности, сейчас тоже не поддерживаются.⁸

flowchart TB
    accTitle: Что TTD не может записать или сделать
    accDescr: Код режима ядра, защищённые процессы, запись запуска приложений UWP и процессы в другом сеансе или контексте безопасности записать нельзя; во время воспроизведения нельзя менять память; антивирус и Electron могут конфликтовать
    no["Ограничения TTD"] --> g1["Нельзя записать"]
    no --> g2["Ограничения и конфликты"]
    g1 --> k["Код режима ядра (драйверы и т. д.)"]
    k --> ppl["Защищённые процессы (PPL)"]
    ppl --> uwp["Запись запуска UWP (прикрепление возможно)"]
    uwp --> sess["Другие сеансы и контексты безопасности"]
    g2 --> ro["Воспроизведение только для чтения"]
    ro --> av["Может конфликтовать с антивирусом и Electron"]

Рис. 7: Ограничения двух видов: «нельзя записать» и «конфликтует». Второе нужно локализовать в каждой среде.

Последний пункт спотыкает тех, кто хочет записать службу. Документация TTD.exe описывает -attach как предназначенный для «расследования служб и долгоживущих приложений», а -monitor — как запись «каждый раз, когда запускается программа или служба»,² что не просто стыкуется с формулировкой на странице устранения неполадок. На практике безопасный порядок — проверять в каждой среде так: сначала подтвердить, что ping.exe или cmd.exe записываются в той же конфигурации, что производство, затем попробовать целевой процесс.⁸

4. Запись — UI WinDbg и TTD.exe

У записи два входа: UI WinDbg или командная строка TTD.exe.

4.1 Запись из UI WinDbg

Запустите WinDbg от имени администратора (для TTD повышение прав обязательно¹), выберите File > Start debugging > Launch executable (advanced), укажите исполняемый файл и отметьте Record with Time Travel Debugging. Выбор Configure and Record позволяет задать расположение файла трассировки и Record subset of execution (ограничить записываемые модули списком через запятую, например notepad.exe,kernelbase.dll). Для уже работающего процесса выберите File > Start debugging > Attach to process и так же отметьте Record Process with Time Travel Debugging.⁹

Во время записи появляется маленький диалог с кнопками «Stop and Debug» и «Cancel». Когда приложение завершается (или падает), трассировка закрывается, WinDbg открывает её автоматически и строит индекс.⁵

flowchart TB
    accTitle: Поток записи из UI WinDbg
    accDescr: В WinDbg, запущенном от имени администратора, выберите Launch executable (advanced) или Attach to process, отметьте Record with Time Travel Debugging, задайте место сохранения и фильтр модулей в Configure and Record, пройдите диалог записи, и когда приложение завершится, трассировка закроется и проиндексируется автоматически
    adm["Запустить WinDbg от имени администратора"] --> pick["Launch executable (advanced) / Attach to process"]
    pick --> chk["Отметить Record with Time Travel Debugging"]
    chk --> cfg["Configure and Record: место сохранения, фильтр модулей"]
    cfg --> rec["Диалог записи (Stop and Debug)"]
    rec --> fin["Приложение завершается, трассировка закрывается и индексируется автоматически"]

Рис. 8: Запись из UI — пять шагов. Пропустите «запуск от имени администратора» — и остановитесь на первом диалоге.

4.2 Запись через TTD.exe

Когда нужно записывать на ПК, куда нельзя поставить WinDbg, или автоматизировать запись, используйте TTD.exe отдельно. Он ставится через App Installer с https://aka.ms/ttd/download, после установки проверяется командой ttd.exe -help. Для офлайн-сред Microsoft также даёт официальную процедуру (со скриптом PowerShell) ручной распаковки пакета MSIX и извлечения только двоичных файлов.² Для записи нужны права администратора, обычно запускают из командной строки администратора.²

Режимов записи три.²

flowchart TB
    accTitle: Три режима записи TTD.exe
    accDescr: launch запускает новый процесс с аргументами и записывает его, но он работает с повышенными правами. attach прикрепляется к работающему процессу по PID. monitor записывает каждый раз, когда стартует указанная программа, и запуск идёт с обычными правами
    m["Режимы записи TTD.exe"] --> l["-launch: запустить и записать"]
    m --> a["-attach: прикрепиться к работающему PID"]
    m --> mo["-monitor: записывать каждый запуск"]
    l -.-> lp["Запускается с правами администратора"]
    a -.-> ap["Сохраняет обычные права"]
    mo -.-> mp["Обычный путь запуска, подходит для автоматизации"]

Рис. 9: Аргументы можно передать только через -launch, но он работает с повышенными правами. Чтобы записать поведение, близкое к производству, используйте -attach или -monitor.

:: Запустить и записать (режим по умолчанию; -launch можно опустить)
TTD.exe -out C:\traces MyApp.exe --config prod.json

:: Прикрепиться к работающему процессу (сначала создайте каталог вывода)
TTD.exe -attach 21440 -out C:\traces\MyApp.run

:: Записывать каждый запуск (Ctrl+C завершает мониторинг; -out требует полный путь)
TTD.exe -out C:\traces\ -monitor MyApp.exe

• -launch — единственный режим, который может передать аргументы, но программа запускается с теми же (администраторскими) правами, что и TTD.exe. Для приложений, чьё поведение меняется с правами, записывайте через -attach или -monitor, чтобы сохранить обычные права.²
• -attach требует, чтобы каталог вывода уже существовал. Если указываете имя файла, файла с таким именем ещё не должно быть.²
• -monitor ставит драйвер мониторинга запуска процессов и записывает каждый раз, когда стартует указанная программа (можно задать несколько). Действует до перезагрузки и останавливается Ctrl+C. Преимущества: не нужно собирать запуск самому, цель работает с обычными правами, подходит для автоматизации скриптами. Добавление -cmdLineFilter "string" записывает только запуски, командная строка которых содержит эту строку.²
• -children записывает и дочерние процессы, но каждый процесс получает свой файл .run, а WinDbg открывает только один за раз.²

Во время записи появляется маленький UI с двумя кнопками: «Tracing Off» (остановить запись и дать приложению продолжить) и «Exit App» (закрыть приложение и закончить запись). Для автоматизации спрячьте его через -noUI и примите EULA через -accepteula.² Журнал записи хранится в файле .out там же, где .run: там читаются настенные время начала и конца записи, длина сеанса записи (simulation time), запуск это был или прикрепление, и версия ОС. Когда запись срывается, часть сообщений об ошибках появляется только в .out.²

5. Проектирование записи для долгоживущих приложений

Это сердце статьи. Исходя из цены главы 3, чтобы поймать ошибку, которая случается в неизвестный момент в процессе, работающем днями, нужно проектирование записи. TTD.exe даёт четыре средства; выбирайте по характеру симптома.

flowchart TB
    accTitle: Выбор охвата записи по симптому долгоживущего приложения
    accDescr: Если неизвестно, когда случится, оставляйте только конец кольцевым буфером; если подозреваемый модуль ясен, записывайте только его; если приложение можно менять, задайте интервал API ручной записи; если проявляется только при запуске или на отдельных запусках, записывайте каждый запуск режимом монитора
    q{"Характер симптома?"} -->|"Неизвестно, когда случится"| ring["-ring / -maxFile: оставить только конец"]
    q -->|"Только при запуске или на отдельных запусках"| mon["-monitor: записывать каждый запуск"]
    ring -->|"Подозреваемый модуль ясен"| mod["Добавить -module"]
    ring -->|"Приложение можно менять"| man["Задать интервал через -recordmode Manual"]

Рис. 10: Четыре не взаимоисключающие. Сочетание -ring с -module — самая практичная комбинация для долгоживущих приложений.

5.1 Кольцевой буфер — оставить только последние N МБ

С -ring трассировка пишется в кольцевой буфер размера, заданного -maxFile, и файл никогда не растёт сверх этого предела. Остаётся только последняя часть записи, которая влезает в этот размер.² Единица -maxFile — МБ; в режиме кольцевого буфера по умолчанию 2 048 МБ, минимум 1 МБ, максимум 32 768 МБ (по умолчанию для кольца в памяти 32-разрядного процесса — 256 МБ).²

:: Прикрепиться к работающему приложению мониторинга и оставить только последние 4 ГБ исполнения
TTD.exe -accepteula -noUI -attach 21440 -ring -maxFile 4096 -out C:\traces\MyApp.run

:: Когда симптом обнаружен, остановить запись (приложение продолжает работать)
TTD.exe -stop 21440

-stop принимает имя процесса, PID или all и останавливает эту запись. -wait <seconds> ждёт, пока на системе закончится каждый сеанс записи (-1 — бесконечно), и в скриптах автоматизации задаёт порядок «остановить, затем забрать файл».²

flowchart TB
    accTitle: Временная шкала записи в кольцевой буфер
    accDescr: Запись начинается при прикреплении, старые части выталкиваются из кольцевого буфера, и когда появляется симптом и выдаётся stop, остаётся только объём последних maxFile как трассировка
    s["Начать запись через -attach -ring"] --> old["Старые интервалы выталкиваются"]
    old --> sym["Появляется симптом"]
    sym --> stop["Остановить запись через -stop"]
    stop --> keep["Остаётся только объём последних maxFile"]
    keep -.-> note["Размерьте так, чтобы моменты до симптома влезли в буфер"]

Рис. 11: Кольцевой буфер — устройство, которое хранит «моменты до симптома». -maxFile считайте назад от «времени от обнаружения симптома до остановки, умноженного на рост в секунду».

Два пункта проектирования.

1. Сделайте буфер достаточно большим, чтобы поглотить время от обнаружения до остановки. В активном процессе трассировка растёт на 5–50 МБ в секунду,⁴ поэтому кольцо 4 ГБ соответствует одной-двум минутам при высокой нагрузке и чуть больше десяти минут при низкой. Нужен механизм, который удерживает лаг между обнаружением симптома (конкретная строка журнала, порог счётчика, оповещение мониторинга) и -stop внутри этого окна.
2. Остановка не отсоединяет. -stop останавливает запись, но TTD сам не отсоединяется от целевого процесса.² Чтобы полностью закончить запись, нужно завершить процесс, поэтому включите в эксплуатацию «перезапустить в следующее окно обслуживания после сбора трассировки».

sequenceDiagram
    accTitle: Остановка записи в кольцевой буфер в связке с мониторингом
    accDescr: Когда сторона мониторинга обнаруживает симптом через журналы или счётчики, она вызывает TTD.exe stop, забирает готовый файл .run и перезапускает процесс в следующее окно обслуживания, чтобы снять TTD
    participant W as Мониторинг (журналы, счётчики)
    participant T as TTD.exe
    participant P as Целевой процесс
    W->>W: Обнаружить симптом
    W->>T: -stop PID
    T->>P: Остановить запись (процесс продолжается)
    T-->>W: .run готов
    W->>W: Забрать .run, зашифровать и сохранить
    W->>P: Перезапустить в следующее окно обслуживания

Рис. 12: Только когда лаг между обнаружением и -stop влезает в буфер, моменты до симптома остаются в трассировке. Перезапуск — часть эксплуатации.

5.2 Фильтр модуля — записывать только пока исполняется свой код

-module <module name> записывает только указанный модуль (сам исполняемый файл или загруженную DLL; можно задать несколько) и код, который этот модуль вызывает. Целевой процесс работает на полной скорости, пока не исполнится код указанного модуля; запись начинается, когда исполнение входит в модуль, останавливается, когда выходит, и процесс снова идёт на полной скорости. Включение и выключение записи дорого, поэтому запись остаётся включённой, пока указанный модуль вызывает другие модули в процессе.²

:: Записывать только пока работает наша DLL измерительной логики (вместе с кольцом)
TTD.exe -accepteula -noUI -attach 21440 -module MeasureCore.dll -ring -maxFile 2048 -out C:\traces\

Трассировка, сделанная так, просто пропускает интервалы, где запись была выключена, считая «следующей инструкцией» первую инструкцию после возобновления записи, и отлаживается ничем не иначе, чем трассировка всего процесса.² В долгоживущих приложениях цикл простоя UI и внутренняя обработка фреймворка обычно дают большую часть исполненных инструкций, поэтому ограничение записи своим модулем само по себе заметно снижает накладные расходы и размер файла.

flowchart TB
    accTitle: Как ведёт себя запись с фильтром модуля
    accDescr: Целевой процесс работает на полной скорости вне указанного модуля; запись начинается, когда входят в код указанного модуля, продолжается, пока этот модуль вызывает другие модули, и останавливается, когда исполнение покидает модуль
    out1["Вне указанного модуля: полная скорость"] --> in1["Вход в указанный модуль: запись начинается"]
    in1 --> callee["Другие модули, которые он вызывает: запись продолжается"]
    callee --> out2["Выход из указанного модуля: запись останавливается"]
    out2 --> out1

Рис. 13: Поскольку Win32 API и среда выполнения, которые вызывает ваша DLL, тоже записываются, этого достаточно, чтобы проследить «что наш код передал ОС».

5.3 Ручная запись — пусть приложение задаёт интервал

С -recordmode Manual процесс продолжает работать на полной скорости даже после внедрения TTD, и запись идёт только когда программа вызывает внутрипроцессный API записи TTD (по умолчанию Automatic записывает с момента внедрения).² Документация API и образцы лежат в репозитории WinDbg-Samples на GitHub.¹⁰

Если приложение можно менять, это наименее расточительный способ. Можно встроить логику, которая начинает запись, когда само приложение знает, что аномалия близка, и останавливает, когда всё возвращается к норме: «три подряд повторные попытки связи не удались», «очередь превысила порог» и так далее. В конфигурации процесса-наблюдателя вроде той, что разобрана в статье о Job Object, интервал может задать наблюдатель.

5.4 Режим монитора — записывать каждый запуск

Для ошибок, которые проявляются только сразу после запуска или на отдельных запусках, подходит -monitor. Официальная таблица сравнения тоже описывает режим монитора как предназначенный «ловить прерывистые проблемы и проблемы запуска».² Когда одну и ту же программу записывают много раз, имена файлов по умолчанию с порядковыми номерами (MyApp01.run, MyApp02.run и так далее) становятся неэффективными, потому что приходится сканировать существующие файлы, поэтому используйте -timestampFilename для имён с меткой времени. Число одновременных записей можно ограничить через -maxConcurrentRecordings.²

flowchart TB
    accTitle: Как ведёт себя режим монитора
    accDescr: Параметр monitor ставит драйвер мониторинга запуска процессов, каждый раз при старте указанной программы сужает цель фильтром командной строки, записывает её, создаёт отдельный файл трассировки на запуск и продолжается до Ctrl+C или перезагрузки
    drv["Установить драйвер мониторинга запуска"] --> launch["Обнаружить запуск указанной программы"]
    launch --> filt{"Совпадает с -cmdLineFilter?"}
    filt -->|"Да"| rec["Записать этот запуск (отдельный файл на запуск)"]
    filt -->|"Нет"| skip["Не записывать"]
    rec --> next["Ждать следующего запуска (до Ctrl+C или перезагрузки)"]
    skip --> next

Рис. 14: Режим монитора «подстерегает запуск». Он подходит ошибкам, которые проявляются на каждом запуске, и ошибкам, которые можно сузить условиями запуска.

5.5 Куда класть диск

Для долгоживущих записей кладите трассировки на выделенный том и включите рост файла .run в мониторинг. Как отмечено в разделе 3.2, когда диск заполняется, запись просто тихо ждёт без ошибки. Официальный обходной путь столь же примитивен: «смотреть свободное место в Проводнике» и «проверять, что файл .run регулярно растёт».⁴ Без мониторинга свободного места вы получаете неполную трассировку, в которой самый нужный момент так и не был записан.

flowchart TB
    accTitle: Как исчерпание диска даёт неполную трассировку
    accDescr: Когда диск заканчивается во время записи, TTD пишет последнюю страницу и тихо ждёт без ошибки и предупреждения, поэтому симптом, который случается после, не записывается, оставляя неполную трассировку, которая открывается, но без ключевой части. Предотвращайте выделенным томом и мониторингом роста .run
    full["Диск заканчивается"] --> wait["Пишет последнюю страницу и тихо ждёт"]
    wait --> none["Ни ошибки, ни предупреждения"]
    none --> sym["После этого случается симптом"]
    sym --> inc["Неполная трассировка без симптома"]
    guard["Выделенный том + мониторинг роста .run"] -.->|"предотвращает"| full

Рис. 15: Трассировка, которая «открывается, но без ключевой части», рождается из дыры в мониторинге диска.

6. Воспроизведение — позиции, события и перемотка

6.1 Открытие

Когда вы открываете файл .run в WinDbg, если индекса нет, автоматически выполняется !index и строится файл .idx, считая keyframe (позиции в трассировке, которые автоматически генерируются для индексации; в больших трассировках их больше). Чем больше трассировка, тем дольше это занимает.⁵ Состояние индекса проверяется через !index -status; если там что угодно кроме «Index file loaded», пересоберите через !index -force. Если и это не помогает, закройте отладчик, удалите файл .idx и снова откройте .run. Пересборка индекса не меняет файл .run, поэтому данные не теряются.⁸

Оговорка: когда в TTD 1.11.611 улучшили индексацию больших трассировок, формат индекса изменился, и существующие трассировки нужно переиндексировать.¹¹ Если вы таскаете старые файлы .idx, спотыкаетесь здесь.

flowchart TB
    accTitle: Проверка и пересборка индекса
    accDescr: После открытия трассировки проверьте состояние через !index -status; если это что угодно кроме Index file loaded, пересоберите через !index -force, и если это всё ещё не удаётся, закройте отладчик, удалите файл .idx и снова откройте .run. Пересборка не меняет файл .run
    open["Открыть трассировку"] --> st["!index -status"]
    st -->|"Index file loaded"| ok["Перейти к анализу"]
    st -->|"Что угодно другое"| force["Пересобрать через !index -force"]
    force -->|"Неудача"| del["Закрыть, удалить .idx, снова открыть .run"]
    del --> ok
    force -->|"Успех"| ok

Рис. 16: Пересборка индекса не трогает файл .run. Если сомневаетесь, удалите и откройте снова.

6.2 Перемещение по позиции

Передача позиции в !tt перемещает к этому моменту времени.⁶

!tt 0          ; начало трассировки
!tt 50         ; примерно позиция 50%
!tt 100        ; конец трассировки
!tt 1A0:12F    ; к позиции 1A0:12F

Позиция — пара шестнадцатеричных чисел, номер секвенирования:счётчик шагов.⁶ У объекта Position есть свойства Percent (доля трассировки), Sequence и Steps, плюс SeekTo(), который перемещает к этой позиции, и ToSystemTime(), который возвращает приблизительное настенное время (UTC).⁷ В расследованиях долгоживущих приложений именно ToSystemTime() делает разницу, потому что позволяет сопоставить метки времени в журнале приложения с позициями в трассировке. Результаты TTD.Calls тоже несут SystemTimeStart / SystemTimeEnd.¹²

flowchart TB
    accTitle: Сопоставление позиций с метками времени журнала
    accDescr: От метки времени в журнале приложения пройдите приблизительное настенное время объекта Position, чтобы найти позицию в трассировке, переместитесь туда через SeekTo и прочитайте исполнение вокруг неё
    log["Журнал приложения: время аномалии"] --> match["Найти позицию, чей ToSystemTime близок"]
    match --> seek["Переместиться туда через SeekTo"]
    seek --> read["Прочитать окружающие вызовы и значения"]

Рис. 17: «Что оно делало непосредственно перед этой строкой журнала?» можно найти через соответствие позиций и настенного времени.

Позиции также полезны для обмена. Когда передаёте трассировку коллеге, приложите позицию !tt x:y — и собеседник начнёт смотреть с того же момента. Писать диапазоны позиций в отчётах об ошибках тоже официально рекомендуется.²

6.3 Перемотка

Если к обычным командам пошагового исполнения добавить - в конец, время идёт назад.¹³

События, которые останавливают g-, те же, что останавливают прямой g.¹³ Иными словами, поставьте ba (точку останова по доступу) или bp и выполните g- — и вы сразу вернётесь к «последней позиции, где это условие выполнялось». Это базовый ход главы 7.

flowchart TB
    accTitle: Выбор среди обратных команд
    accDescr: p- идёт назад на один шаг через вызовы функций, t- идёт назад на одну инструкцию внутрь функций, а g- идёт сразу назад до точки останова, события или начала трассировки. Что останавливает прямой g, останавливает и g-
    cur["Текущая позиция"] -->|"p-"| over["Назад на один шаг через вызовы"]
    cur -->|"t-"| into["Назад на одну инструкцию внутрь функций"]
    cur -->|"g-"| run["Сразу назад до следующего условия остановки"]
    run -.-> stop["ba / bp / событие / начало трассировки"]

Рис. 18: Чтобы внимательно смотреть рядом, используйте t-; чтобы прыгнуть к далёкой причине, используйте ba + g-.

6.4 Вход через события

Если неясно, откуда начинать читать, начните со списка событий. @$curprocess.TTD.Events перечисляет как события создание и завершение потоков, загрузку и выгрузку модулей и исключения.¹⁴

dx -g @$curprocess.TTD.Events
dx @$curprocess.TTD.Events.Where(t => t.Type == "Exception").Select(e => e.Exception)

Событие исключения содержит позицию, тип (Software / Hardware), код исключения и счётчик команд на тот момент; щелчок по ссылке [Time Travel] в выводе перемещает к этой позиции.¹⁵ Официальный обзор идёт по этому потоку: прыгает к позиции нарушения доступа (0xc0000005), подозревает порчу стека, потому что указатель стека и базовый указатель не совпадают, и шагает назад на три инструкции через t-, чтобы проверить значения.⁵ Окно Timelines в WinDbg визуализирует исключения, точки останова, обращения к памяти и вызовы функций как шкалу времени; двойной щелчок по исключению выдаёт тот же SeekTo().¹⁶

6.5 Потоки и позиции

!positions показывает каждый активный поток в текущей позиции вместе с позицией каждого потока в трассировке.¹⁷ Здесь есть ловушка. Переключение потоков через ~<number>s не двигает позицию в трассировке. Позиция, которую отладчик использует для чтения памяти, не меняется, поэтому чтобы посмотреть память другого потока «в тот момент», переместитесь туда ссылкой позиции в выводе !positions или через !tt x:y.¹³

flowchart TB
    accTitle: Базовый путь через воспроизведение
    accDescr: Откройте трассировку и постройте индекс, от списка событий перейдите к позиции исключения, шагайте назад к причине и при необходимости переместитесь к позиции другого потока через positions
    open["Открыть трассировку и проиндексировать"] --> ev["Найти исключение в TTD.Events"]
    ev --> seek["Переместиться к позиции через [Time Travel]"]
    seek --> back["Назад через t- / p- / g-"]
    back --> th["Проверить позиции других потоков через !positions"]
    th -.-> caution["~s не двигает позицию трассировки"]

Рис. 19: «Войти через событие, идти назад» — базовый путь через воспроизведение. Переключение потоков — не перемещение позиций.

7. Искать «когда» запросами — TTD.Calls и TTD.Memory

Настоящая сила воспроизведения в том, что можно запросить всю трассировку. Объекты TTD выставлены через модель данных отладчика (команда dx), и их можно фильтровать, сортировать и агрегировать в стиле LINQ.¹⁸

7.1 TTD.Calls — поиск вызовов функций

@$cursession.TTD.Calls("module!symbol") собирает вызовы указанной функции со всей трассировки. Допускаются подстановочные знаки, и каждый вызов несёт позиции начала и конца (TimeStart / TimeEnd), идентификатор потока (с UniqueThreadId, который никогда не переиспользуется), аргументы (Parameters[]), возвращаемое значение (ReturnValue) и адрес возврата (ReturnAddress).¹²

Пример в официальной документации — GetLastError. Соберите вызовы с ненулевым возвращаемым значением по коду ошибки — и получите список, какие ошибки сколько раз случились за трассировку.¹⁸

dx -g @$cursession.TTD.Calls("kernelbase!GetLastError").Where(x => x.ReturnValue != 0).GroupBy(x => x.ReturnValue).Select(x => new { ErrorNumber = x.First().ReturnValue, ErrorCount = x.Count() }).OrderByDescending(p => p.ErrorCount),d

Для «откуда последний раз вызывали MessageBox?» возьмите последний вызов через OrderBy(c => c.TimeStart).Last() и переместитесь туда ссылкой [Time Travel] его TimeStart.¹⁸

flowchart TB
    accTitle: Сборка запроса TTD.Calls
    accDescr: Соберите вызовы по имени функции, отфильтруйте по возвращаемому значению или аргументам, агрегируйте по коду ошибки и тому подобному, отсортируйте по времени и переместитесь к позиции нужного вызова через ссылку Time Travel
    calls["TTD.Calls (имя функции, подстановочные знаки)"] --> where["Where: фильтр по возвращаемому значению или аргументам"]
    where --> group["GroupBy: агрегировать по коду ошибки и т. д."]
    group --> order["OrderBy: сортировать по времени"]
    order --> jump["Переместиться через [Time Travel] на TimeStart"]

Рис. 20: Запросы используют так: начинать не с «где», а с «когда, сколько раз и с какими аргументами».

Слово о символах. TTD определяет число и типы аргументов функции, тип возвращаемого значения и соглашение о вызове из сведений символов PDB. С закрытыми символами (private symbols) вы получаете имя функции и верные аргументы. Только с открытыми символами (public symbols) — имя функции и аргументы по умолчанию (четыре 64-разрядных беззнаковых целых). Модуль без символов вовсе получает имя функции UnknownOrMissingSymbols.¹²¹⁸ О видах PDB и о том, как их хранить, см. «Что такое PDB (Program Database) — отладочная информация, символы и Source Link».

flowchart TB
    accTitle: Наличие символов и результаты TTD.Calls
    accDescr: С закрытыми символами получаете имя функции и верные аргументы; только с открытыми символами — имя функции и четыре 64-разрядных целых аргумента по умолчанию; без символов имя функции становится UnknownOrMissingSymbols
    sym{"Символы модуля?"} -->|"private symbols"| full["Имя функции + верные аргументы и возвращаемое значение"]
    sym -->|"public symbols"| pub["Имя функции + аргументы по умолчанию (4 x 64-разрядных целых)"]
    sym -->|"нет"| unk["UnknownOrMissingSymbols"]

Рис. 21: Храните ли вы PDB своих модулей, напрямую определяет, насколько полезны запросы.

Calls связан с вычислениями, поэтому чем больше трассировка, тем дольше это занимает и тем выше загрузка CPU. Результаты кэшируются в памяти, поэтому второй и последующие запросы к той же функции быстрее.¹² Когда запрос ничего не возвращает, причин четыре: как записан вызов (проверьте имя модуля командой x; если вернулось в верхнем регистре, используйте его), целевая DLL на этой позиции ещё не загружена (перейдите к позиции после загрузки и выполните снова), функция встроена (inlined, отследить нельзя) или подстановочный знак слишком широкий (сузьте).¹⁸

7.2 TTD.Memory — поиск обращений к памяти

@$cursession.TTD.Memory(start address, end address, "access type") собирает обращения к указанному диапазону памяти со всей трассировки. Типы: r (чтение), w (запись), rw, e (исполнение), rwe и ec (исполнение/изменение).¹⁹ На «кто последним записал эту переменную?» отвечают, собрав с "w", взяв .Last() и переместившись к этой позиции.⁵

dx -g @$cursession.TTD.Memory(0x00a4fca0, 0x00a4fca4, "w")
dx @$cursession.TTD.Memory(0x00a4fca0, 0x00a4fca4, "w").Last().TimeStart.SeekTo()

Если нужно искать только вперёд или назад от текущей позиции, @$curprocess.TTD.PrevMemoryAccess("w", address, size) / NextMemoryAccess легче и принимают несколько диапазонов сразу. Позицию, где изменился регистр, можно найти через @$curthread.TTD.PrevRegisterWrite("rcx").⁶

7.3 ba + g- — заставить отладчик ответить «кто испортил?»

Сжав процедуру официального обзора в форму, пригодную для расследований долгоживущих приложений, получаем следующее.⁵

1. Перейдите к позиции исключения через TTD.Events
2. Шагайте назад через t- и предположите, какая переменная держит испорченное значение
3. Возьмите адрес этой переменной через dx &variable
4. Поставьте точку останова на запись через ba w4 <address>
5. Выполните g-, чтобы сразу вернуться к позиции, где эту переменную записали последней
6. Проверьте, является ли эта точка (или несколько инструкций раньше) причиной. Если записанное значение пришло из другой переменной, поставьте ba на ту переменную и снова выполните g-
7. Повторяйте, пока не дойдёте до инструкции, которая испортила значение

flowchart TB
    accTitle: Прослеживание происхождения значения через ba и g-
    accDescr: Поставьте точку останова на запись по адресу испорченного значения и исполняйте в обратную сторону, остановитесь на инструкции, которая записала его последней, и если это значение пришло из другой переменной, повторяйте те же шаги, пока не дойдёте до инструкции, которая испортила значение
    bad["Определить адрес испорченного значения"] --> ba["Поставить точку останова на запись через ba w"]
    ba --> gb["Исполнять в обратную сторону через g-"]
    gb --> writer["Остановиться на инструкции, которая записала последней"]
    writer --> q{"Значение пришло из другой переменной?"}
    q -->|"Да"| bad
    q -->|"Нет"| found["Инструкция, которая испортила = причина"]

Рис. 22: Расследование, которое на дампе заканчивается на «испорчено», с TTD механически идёт до «кто испортил».

В TTD 1.11.553 и новее также добавлен @$curframe.TTD.VariableHistory(), который возвращает историю значений локальных переменных кадра. Он показывает таблицу имён переменных и какие значения каждая переменная держала на каких диапазонах позиций.¹¹ В ситуациях вроде порчи стека, где нужно знать «с какого момента значение неверно», это полезно, чтобы сузить, куда сначала ставить ba.

8. Применить к ошибкам долгоживущих приложений

Теперь применим эти инструменты к трём видам случаев, перечисленным в начале.

flowchart TB
    accTitle: Типы ошибок долгоживущих приложений и точка входа TTD для каждого
    accDescr: Для прерывистых исключений и порчи данных идите назад от события через ba и g-; для роста ресурсов сопоставляйте вызовы получения и освобождения через TTD.Calls; для «не отвечает» и цепочек ожиданий следите за позициями и настенным временем вызовов API ожидания
    t1["Прерывистые исключения, порча данных"] --> a1["TTD.Events, затем ba + g-"]
    t2["Рост хендлов и памяти"] --> a2["Сопоставить получение и освобождение через TTD.Calls"]
    t3["Не отвечает, цепочки ожиданий"] --> a3["!positions и настенное время API ожидания"]
    a2 -.-> pre["Записывать через -module, ограниченный своей DLL"]

Рис. 23: Точка входа зависит от типа. Общее — сузить охват записи, прежде чем начинать читать.

Тип 1: прерывистые исключения и порча данных. Оставьте моменты до симптома кольцевым буфером раздела 5.1, прыгните к позиции исключения из списка событий раздела 6.4 и проследите происхождение значения через ba + g- раздела 7.3. Отличие от расследования дампа в том, что расследование не заканчивается, когда вы находите «испорченную переменную»; оттуда вы механически идёте назад.

Тип 2: рост хендлов и памяти. Это тот вид случая, который разобран в «Утечка хендлов: почему приложение промышленной камеры падает после месяца работы». Месяц записать нельзя, поэтому ограничьте запись своей DLL через -module раздела 5.2, совместите с -ring и оставьте «несколько минут, пока растёт». На трассировке соберите TTD.Calls("kernelbase!CreateFileW") и TTD.Calls("kernelbase!CloseHandle") и сопоставьте возвращаемое значение CreateFileW (значение хендла) с первым аргументом CloseHandle (Parameters[0]). ReturnValue у CloseHandle — булев флаг успеха, поэтому для сопоставления он бесполезен. Если значение хендла осталось незакрытым, ReturnAddress (вызывающий) этого вызова CreateFileW даёт вызывающего, который утекает.¹² При этом наблюдать, есть ли утечка и насколько она велика, дешевле через Application Verifier или счётчики хендлов; правильное разделение труда — выносить TTD на этап, когда нужно закрепить, какой путь утекает. Заметьте: запись при включённом Application Verifier заметно ухудшает производительность воспроизведения из-за того, как используется память, поэтому на время записи отключайте его.⁸

Тип 3: «не отвечает» и цепочки ожиданий. Как написано в ««Не отвечает»: как Windows определяет зависание и как проектировать так, чтобы оно не возникало», зависание — вопрос, кто кого ждёт. Трассировка не растёт в простое,⁴ поэтому время ожидания потока, который ждёт в ядре, не появляется как инструкции. Что появляется — вызов непосредственно перед входом в ожидание и инструкции после возврата. Смотрите позицию каждого потока через !positions¹⁷ и выстройте «какой поток начал ждать чего и когда» из SystemTimeStart / SystemTimeEnd у TTD.Calls("kernelbase!WaitForSingleObject") и подобных; сопоставление с метками времени журнала позволяет восстановить цепочку ожиданий.¹² «Ошибки, зависящие от порядка», вроде DllMain и блокировки загрузчика или ложных пробуждений условных переменных, — область, где TTD, который записывает сам порядок, хорошо подходит.

9. TTD в приложениях .NET

Официальная документация TTD указывает, что управляемый код можно отлаживать через TTD в WinDbg с расширением SOS (sos.dll), работающим в 64-разрядном режиме.¹ Загрузка та же, что в главе 3 статьи об анализе SOS (.loadby sos coreclr или автоматическая загрузка), и !clrstack и !pe работают в каждой позиции трассировки. Базовый путь — переместиться к позиции исключения через TTD.Events, затем прочитать управляемый стек через !clrstack.

flowchart TB
    accTitle: Настройка чтения трассировки TTD приложения .NET
    accDescr: Откройте трассировку TTD в WinDbg, загрузите 64-разрядное расширение SOS, переместитесь к позиции события исключения и прочитайте управляемое состояние через !clrstack и !pe. Используйте TTD.Calls для вызовов через нативные границы
    run["Трассировка TTD (.run)"] --> wd["WinDbg"]
    wd --> sos["Расширение SOS (64-разрядное)"]
    sos --> ev["Переместиться к позиции исключения через TTD.Events"]
    ev --> clr["Читать через !clrstack / !pe"]
    wd -.-> calls["TTD.Calls для вызовов через нативные границы"]

Рис. 24: Управляемое состояние через SOS, поиск вызовов на нативных границах. Разделите роли — и не заблудитесь.

Две оговорки. Первая: Microsoft гарантирует «SOS в 64-разрядном режиме». Про приложения .NET, собранные под x86, ничего не сказано, поэтому по возможности запускайте объект расследования как x64. Вторая: TTD.Calls опирается на сведения символов PDB.¹² Не рассчитывайте искать JIT-скомпилированные управляемые методы по имени; надёжное использование — следить за вызовами через нативные границы вроде целей P/Invoke в нативных DLL, COM и Win32 API. Проблемы управляемой кучи вроде тех, что в «.NET: как отличить ожидание GC от утечки памяти», сначала преследуют через dotnet-counters / dotnet-gcdump / !gcroot на дампе, а TTD выносят на этап, где задействована нативная граница.

10. Выбор между дампами, журналами, ETW и TTD

TTD — не панацея и не заменяет существующие инструменты. Здесь он выстроен рядом с инструментами, которые мы разбирали в статьях.

flowchart TB
    accTitle: Выбор метода расследования
    accDescr: Сначала схватите состояние лёгкими дампами и журналами, сбойные API разбирайте ProcMon, производительность — ETW, и переходите к TTD только когда всё ещё нужно, кто, когда и что передал
    start["Симптом"] --> light["Схватить состояние дампами и журналами (легко)"]
    light --> api["Сбойные API: ProcMon"]
    light --> perf["Производительность: WPR/WPA, PerfView"]
    light --> need{"Нужно, кто, когда и что передал?"}
    need -->|"Да"| ttd["Спроектировать охват записи и записать через TTD"]
    need -->|"Нет"| done["Разобрались лёгкими инструментами"]

Рис. 25: Сначала схватите «результат» лёгкими инструментами и выносите TTD только на те случаи, где оказывается нужен «путь».

Порядок — «сначала самое лёгкое». Дампы и журналы почти ничего не стоят при сборе, поэтому держите их постоянно; TTD выносите, после проектирования главы 5, на случаи, где чтение дампа показало, что нужен путь. Учитывая накладные расходы TTD и то, что трассировки содержат конфиденциальные сведения, нет причины разворачивать этот порядок.

11. Замечания по эксплуатации

• Обращайтесь с трассировками как с конфиденциальными файлами. Запись содержит содержимое памяти и может включать персональные и связанные с безопасностью сведения вроде путей файлов, данных реестра и содержимого памяти и файлов.¹² Когда записываете в среде заказчика, заранее поймите, что может войти (строки подключения, токены, данные клиентов), и решите зашифрованный канал передачи, место хранения и срок хранения.
• Делитесь только файлом .run. Файл .idx примерно такого же размера, как .run, и генерируется автоматически, когда WinDbg его открывает. Файлы .run хорошо сжимаются. Когда сообщаете об ошибке в самом TTD, приложите и файл .out.²
• Выравнивайте версии. TTD продолжают обновлять вместе с WinDbg; в 1.11.611 есть исправление сбоев записи в программах, которые используют AVX/AVX512, и смена формата индекса.¹¹ Смешение старой версии на стороне записи или воспроизведения означает переиндексацию или повторную запись.
• Проверяйте -replayCpuSupport, когда воспроизводите на другом CPU. По умолчанию приоритет у переносимости, а MostConservative предусмотрен для случаев, когда CPU записи и CPU воспроизведения различаются (например, воспроизведение трассировки Intel на arm64). Наоборот, если известно, что CPU воспроизведения равен или лучше, можно выбрать меньшую и более быструю запись.²
• Windows Server тоже можно записывать. TTD.exe поддерживает Windows Server 2016/2019/2022/2025.²
• Локализация сбоя записи. Сначала попробуйте, записываются ли ping.exe или cmd.exe; если нет, подозревайте конфликт с инвазивным ПО вроде антивируса или виртуализации приложений.⁸

flowchart TB
    accTitle: Процедура обращения с трассировками
    accDescr: Поскольку записанная трассировка содержит содержимое памяти, поймите, какие сведения она может содержать, сожмите только файл .run и передайте через зашифрованный канал, решите место хранения и срок хранения, а на стороне анализа откройте той же версией WinDbg и постройте индекс
    rec["Запись завершена (.run / .idx / .out)"] --> know["Понять, какие сведения могут содержаться"]
    know --> share["Сжать только .run, зашифровать и передать"]
    share --> keep["Решить место хранения и срок хранения"]
    keep --> open["Открыть той же версией WinDbg и сгенерировать .idx"]

Рис. 26: Передача трассировки — передача конфиденциального файла. Решите процедуру до того, как записывать.

12. Итог

• Дамп — «состояние»; TTD — «путь». В случаях, где нужно происхождение испорченного значения или порядок вызовов, TTD превращает расследование в механическую работу
• Запись в 5–20 раз медленнее, растёт на 5–50 МБ в секунду и не отсоединяется. Для долгоживущих приложений сначала спроектируйте охват записи через -ring/-maxFile, -module, -recordmode Manual и -monitor
• Воспроизведение — «войти через событие, идти назад»: TTD.Events, затем [Time Travel], затем t-/g-, и ba + g-, чтобы отладчик ответил «кто испортил»
• TTD.Calls и TTD.Memory — запросы по всей трассировке. Сопоставляйте с метками времени журнала через ToSystemTime() и SystemTimeStart
• Для .NET читайте состояние 64-разрядным SOS, а TTD.Calls используйте на нативных границах
• Трассировка — конфиденциальный файл. Делитесь только файлом .run и сначала решите канал и хранение

Случаи, где дамп сняли, но до причины не доходят, или где работа встала, потому что ошибка не воспроизводится, довольно часто закрываются TTD, как только можно спроектировать охват записи. Мы также можем взять на себя всё от проектирования записи до анализа файла .run, поэтому обращайтесь со своими дампами и журналами.

Похожие статьи

• Как читать аварийные дампы в WinDbg + SOS — практика анализа после сбора
• Сбор дампов сбоев Windows — введение: WER, ProcDump, WinDbg
• Что такое PDB (Program Database) — отладочная информация, символы и Source Link
• Утечка хендлов: почему приложение промышленной камеры падает после месяца работы
• «Не отвечает»: как Windows определяет зависание и как проектировать так, чтобы оно не возникало
• Практическое руководство по Process Monitor (ProcMon) — за 10 минут находим «настройки не читаются» и ACCESS DENIED
• WPR/WPA на практике: как разбирать «весь ПК тормозит» по всей системе
• Как найти причину «тормозов» с PerfView и dotnet-trace — практика анализа производительности .NET
• Что остаётся после падения родителя ── дерево дочерних процессов в Job Object

Смежные области консультирования

KomuraSoft LLC занимается расследованием первопричин ошибок приложений Windows, которые проявляются только после долгой работы или прерывисто, сочетая аварийные дампы, журналы и трассировки TTD; построением постановки расследования, включая проектирование охвата записи; и локализацией сбоев, в которых задействованы нативные границы (COM, P/Invoke, SDK устройств). Обращайтесь уже на этапе «дамп есть, до причины не доходим».

• Расследование ошибок и анализ первопричин
• Техническое консультирование и ревью проектирования
• Разработка приложений Windows
• Контакты

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Чем Time Travel Debugging (TTD) отличается от аварийного дампа?

Аварийный дамп — фотография памяти в момент сбоя: показывает состояние в этот миг, но не путь, который к нему привёл. Трассировка TTD — полная запись исполнения инструкций процесса, которую позже можно воспроизвести вперёд и назад, поэтому можно перемотать и напрямую проверить, кто последним записал переменную или что вызывалось непосредственно перед исключением. Официальная документация Microsoft также указывает, что дампы склонны упускать состояние и путь исполнения, которые привели к сбою. Цена — процесс во время записи работает в 5–20 раз медленнее, а файл трассировки растёт примерно на 5–50 МБ в секунду, пока процесс активен.

Можно ли оставить TTD прикреплённым к производственному приложению, которое работает днями?

Как есть — нет. TTD сильно замедляет процесс во время записи, трассировка активного процесса растёт на 5–50 МБ в секунду, и потолка размера файла нет. Использование на долгоживущем приложении предполагает проект записи: кольцевой буфер TTD.exe -ring с -maxFile, чтобы оставлять только последние N МБ, -module, чтобы записывать только пока работает свой модуль, или -recordmode Manual, чтобы приложение задавало интервал записи. Также, однажды прикрепившись, TTD сам себя не отсоединяет, поэтому заранее нужно решить, как закончить запись, а это значит завершить (перезапустить) процесс.

Можно ли записывать службы и процессы в других сеансах?

Документация TTD.exe описывает -attach как предназначенный для расследования служб и долгоживущих приложений, а -monitor — как запись каждый раз, когда запускается программа или служба. С другой стороны, страница устранения неполадок указывает, что необычные процессы, работающие в другом сеансе или другом контексте безопасности, в настоящее время не поддерживаются для записи. Сработает ли на самом деле, зависит от среды, поэтому сначала запишите простой процесс вроде ping.exe или cmd.exe в той же конфигурации, что производство, затем попробуйте целевой процесс и только потом встраивайте в эксплуатацию.

Можно ли использовать TTD на трассировках приложений .NET?

Да. Официальная документация указывает, что расширение SOS (sos.dll), работающее в 64-битном режиме, можно использовать на трассировке TTD в WinDbg для отладки управляемого кода. Базовый шаблон — выполнять команды SOS вроде !clrstack и !pe на каждой позиции трассировки, переходя к позиции события исключения и затем читая управляемый стек. Запрос TTD.Calls, который ищет вызовы по имени символа, опирается на сведения символов PDB, поэтому в приложениях .NET надёжное использование — следить за вызовами через нативные границы вроде P/Invoke, COM и Win32 API.

Безопасно ли отправлять файл трассировки (.run) другой компании или за пределы организации?

Как есть — нет. Запись TTD содержит содержимое памяти процесса, и официальная документация прямо указывает, что туда могут входить персональные или конфиденциальные сведения вроде путей файлов, данных реестра и содержимого памяти и файлов. Если отправляете, сначала поймите, что записано (строки подключения, токены, данные клиентов и так далее), затем решите зашифрованный канал передачи и место хранения. Достаточно делиться только файлом .run; индексный файл (.idx) генерируется автоматически, когда WinDbg его открывает.

TTD.Calls ничего не возвращает, когда ищу функцию. Почему?

Есть четыре основные причины. Первая — символы: функции модуля без PDB называются UnknownOrMissingSymbols, и имя модуля может быть в верхнем регистре, поэтому проверьте фактическое имя символа командой x. Вторая — целевая DLL на этой позиции ещё может быть не загружена; перейдите к позиции после загрузки DLL и запросите снова. Третья — если функция встроена (inlined), движок запроса не может её отследить. Четвёртая — шаблон может быть слишком широким и совпадать со слишком многими функциями; сузьте его.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.