EreTIk's Box » Заметки о WinDbg » WinDbg 6.3.9600: новые возможности отладки


Перед тем как я расскажу о некоторых новых возможностях, стоит пару слов сказать о новой системе версий WinDbg. Изначально существовал отдельный продукт "Debugging Tools for Windows". Он имел свою линейку версий. Затем Microsoft интегрировали "Debugging Tools for Windows" в WDK и Platform SDK, убрав возможность скачивания отдельного дистрибутива отладчика (что толкнуло меня на ведение коллекции отдельных дистрибутивов "Debugging Tools for Windows"). Следующим шагом (с выходом preview-версии Windows 8) стало появление версии 6.2.xxx.yyy после 6.12.xxx.yyy. То есть Microsoft лишили "Debugging Tools for Windows" собственной версии, а версия WinDbg теперь совпадает с версией операционной системы. Последняя версия (на момент написания) - 6.3.9600.16384, что соответствует Windows 8.1.


Так что же нового предоставляет отладчик версии 6.3.9600 по сравнению с 6.12.xxx.yyy? Для начала стоит ознакомится с официальной документацией:


Так же стоит отметить, что старый отладчик упорно обзывает системы Windows 8 семерками. Плюс, как я писал ранее, отладчик 6.12.xxx.yyy не открывает полные дампы с Windows 8.


Но самое вкусное - расширения. Самые интересные (на мой взгляд), доступные только в новом отладчике:

  • !findhandle-поиск описателей на указанный объект. Первый обязательный параметр - адрес объекта. Второй необязательный параметр - адрес процесса, в котором будет происходить поиск. Если второй параметр не задан, то будет произведен поиск во всех процессах.

1: kd> !object \PowerMonitorPort Object: 847615c8 Type: (8466d5e0) ALPC Port ObjectHeader: 847615b0 (new version) HandleCount: 1 PointerCount: 32 Directory Object: 81601188 Name: PowerMonitorPort 1: kd> !findhandle 847615c8 [8467acc0 System] 18: Entry 81605030 Granted Access 1f0001
  • !joblist - команда перечисляет все созданные в системе job-объекты. Для каждого job-объекта выводтся информация, аналогичная результату работы команды !job для этого объекта.

1: kd> !joblist Job at 8751d518 Basic Accounting Information TotalUserTime: 0x0 TotalKernelTime: 0x0 TotalCycleTime: 0x0 ThisPeriodTotalUserTime: 0x0 ThisPeriodTotalKernelTime: 0x0 TotalPageFaultCount: 0x0 TotalProcesses: 0x0 ActiveProcesses: 0x0 FreezeCount: 0 BackgroundCount: 1 TotalTerminatedProcesses: 0x0 PeakJobMemoryUsed: 0x0 PeakProcessMemoryUsed: 0x0 Job Flags [background] [empty job notified] Limit Information (LimitFlags: 0x0) Limit Information (EffectiveLimitFlags: 0x0) ... Job at a2e673c8 Basic Accounting Information TotalUserTime: 0x4c4b4 TotalKernelTime: 0x0 TotalCycleTime: 0xb94f9f7 ThisPeriodTotalUserTime: 0x4c4b4 ThisPeriodTotalKernelTime: 0x0 TotalPageFaultCount: 0x9ac TotalProcesses: 0x4 ActiveProcesses: 0x1 FreezeCount: 0 BackgroundCount: 0 TotalTerminatedProcesses: 0x0 PeakJobMemoryUsed: 0x18c PeakProcessMemoryUsed: 0xf3 Job Flags Limit Information (LimitFlags: 0x2000) Limit Information (EffectiveLimitFlags: 0x2000) JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE
  • !ptetree - отображения дерева структур памяти.

USAGE: !ptetree [Levels | PteVa] Dump the tree of valid and non-zero paging structures. Note: This relies on the particulars of NT PTE management Levels - Optional depth of the tree to dump. PteVa - Optional VA of a paging structure below which structures should be dumped

Есть у нового отладчика и неприятные моменты. Появилась проблема зависания при выходе из отладчика, если в этот момент исполняющееся расширение читает пользовательский ввод. Поясню на примере, исходный код расширения:


extern "C" __declspec(dllexport)
HRESULT CALLBACK echo(IDebugClient4 *pClient, PCSTR)
{
    CComQIPtr< IDebugControl > pControl(pClient);
    for(; ; )
    {
        char buf[MAX_PATH] = {0};
        pControl->Input(&buf[0], _countof(buf), NULL);
        pControl->Output(DEBUG_OUTPUT_NORMAL, ">> %s\n", &buf[0]);
    }
}
                

Дальше запускаем расширения (!echo) и закрываем отладчик. Старый отладчик закрывается, а новый - зависает. Это приводит к известным проблемам использования !pycmd. Проблема была признана Microsoft'ом, но так до сих пор и не исправлена.


ΞρεΤΙκ