Выполнение Агента DebugView

Чтобы вручную запустить DebugView в режиме агента, определите /a как параметр командной строки. DebugView выводит на экран "Ожидание соединения" диалоговое окно, показанное в рисунке 7-17, пока монитор DebugView не соединяется с этим. Диалоговое окно тогда указывает "Соединенный". Отметьте, что в режиме агента, DebugView не получает или сохраняет вывод отладки, если не соединенный с монитором DebugView. Когда соединено, агент DebugView всегда получает вывод отладки Win32 в текущем терминальном сеансе служб. Чтобы иметь вывод отладки ядра получения агента, добавьте /k к командной строке; чтобы получить многословный вывод отладки ядра, также добавьте /v к командной строке. Чтобы получить глобальную переменную (сеанс 0) вывод, добавьте /g к командной строке.

Рис. 7-17. DebugView Удаленное окно Агента.

Если разъединения монитора или соединение иначе повреждаются, окно состояния агента возвращается к "Ожиданию соединения", и DebugView ждет другого соединения. Добавляя /e к командной строке агента DebugView, можно решить вывести на экран сообщение об ошибке, когда это происходит, и не принимают новое соединение, пока сообщение об ошибке не отклоняется.

Можно скрыть окно состояния агента и вместо этого вывести на экран значок в области уведомлений панели задач, добавляя/t к командной строке. Значок является серым, когда агент не соединяется с монитором и красится, когда это соединяется. Можно открыть окно состояния, ­дважды щелкая по значку и возвратить это значку, минимизируя окно состояния. Можно скрыть пользовательский интерфейс агента DebugView полностью, добавляя/s к командной строке DebugView. В этом режиме DebugView остается активным, пока пользователь не выходит из системы, тихо принимая ­соединения от мониторов DebugView. Отметьте, что/s переопределяет/e: если средство просмотра разъединится, то DebugView будет тихо ждать и принимать новое соединение, не выводя на экран уведомление.

Вручную запущенный агент DebugView прислушивается к соединениям на порту TCP 2020. Windows Firewall мог бы вывести на экран предупреждение в первый раз, когда Вы выполняете DebugView в режиме агента. Если Вы будете хотеть предоставлять доступ, обозначенный в предупреждающем сообщении, то Windows создаст исключение программы для DebugView в брандмауэре. Это или исключение порта для TCP 2020 позволят вручную запущенному агенту DebugView работать. Отметьте, что соединения являются анонимными и не аутентифицируемые.

 

 

Агент, автоматически установленный и, запускался на удаленном компьютере средством просмотра, реализуется как служба Windows. Поэтому, это работает в терминальном сеансе служб 0, где это может контролировать только ядро и глобальный вывод отладки Win32; это не может контролировать ­вывод отладки ­от интерактивных пользовательских сеансов за пределами сеанса 0. Кроме того, это прислушивается к соединению на случайном высоком порту, который не практичен при использовании основанного на узле брандмауэра. В большинстве случаев вручную запущенный агент DebugView обычно будет намного более надежным и является рекомендуемым способом контролировать вывод отладки удаленно.

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

LiveKd

LiveKd позволяет Вам использовать отладчики ядра, чтобы исследовать снимок живой системы, не загружая систему в режиме отладки. Это может быть полезно, когда ­поиск и устранение неисправностей уровня ядра ­требуется на машине, которая не была загружена в режиме отладки. Определенные вопросы могло бы быть трудно воспроизвести, так перезагрузка системы может быть подрывной. Вдобавок ко всему, начальная загрузка компьютера в режиме отладки изменяется, как некоторые подсистемы ведут себя, который может далее ­усложнить анализ. В дополнение к не требованию начальной загрузки с включенным режимом отладки LiveKd позволяет отладчикам ядра Microsoft выполнять некоторые действия, которые не обычно возможны с локальной отладкой ядра, таковы как создание полного файла дампа памяти.

В дополнение к исследованию локальной системы LiveKd поддерживает отладку гостевых виртуальных машин Hyper-V (VMs) внешне от узла Hyper-V. В этом режиме отладчик работает на узле Hyper-V а не на госте VMs, таким образом нет никакой потребности скопировать любые файлы в целевой VM или сконфигурировать VM всегда.

LiveKd создает файл дампа снимка памяти ядра, фактически не останавливая ядро, в то время как снимок получается. LiveKd тогда представляет этот моделируемый файл дампа отладчику ядра Вашего выбора. Можно тогда использовать отладчик, чтобы выполнить любые операции на этом снимке живой памяти ядра, что Вы могли на любом нормальном файле дампа.

Поскольку LiveKd полагается на физическую память, чтобы поддержать моделируемый дамп, отладчик ядра мог бы столкнуться с ситуациями, в которых структуры данных находятся в середине того, чтобы быть измененным системой и непоследовательны. Каждый раз, когда отладчик запускается, он запускается с нового представления системного состояния. Если Вы хотите обновить снимок, выйти из отладчика (с q ­командой), и LiveKd спросит Вас, хотите ли Вы запустить это снова. Если отладчик вводит цикл в печать вывода, нажмите Ctrl+C, чтобы прервать вывод, выйдите, и запустите повторно это. Если это зависает, нажмите Ctrl + Повреждение, которое завершит процесс отладчика и спросит Вас, хотите ли Вы выполнить отладчик снова.

 

Требования LiveKd

LiveKd поддерживает весь x86 и x64 версии Windows. Это должно быть выполнено с административными правами, включая полномочие Отладки.

LiveKd зависит от Средств отладки для Windows, который должен быть установлен на той же самой машине прежде, чем Вы выполните LiveKd. URL для Средств отладки для Windows http://www.microsoft.com/whdc/devtools/debugging/default.mspx. Установщик Средств отладки, используемый, чтобы быть автономной загрузкой, но это теперь включается в SDK Windows. Чтобы получить Средства отладки, следует выполнить установщик SDK и выбрать опции Debugging Tools, которые Вы хотите. Среди опций распространяемые файлы Средств отладки, которые являются автономными установщиками Средств отладки, доступными для x86, x64, и IA64. Они работают хорошо, если Вы хотите установить Средства отладки на других машинах, не выполняя установщик SDK.

LiveKd требует, чтобы файлы символа ядра были доступны. Они могут быть загружены как необходимый с сервера символа общественности Microsoft. Если у системы, которая будет проанализирована, нет Интернет-соединения, см., что "Онлайновый Дамп Памяти Ядра Использует LiveKd" боковая панель, чтобы изучить, как получить необходимые файлы символа.

Выполнение LiveKd

Синтаксис командной строки LiveKd

livekd [-w |-k путь отладчика |-o dumpfile ] [[-hvl] | [-hv VMName] [-p]] [опции отладчика ].

Таблица 7-3 суммирует параметры командной строки LiveKd, которые тогда обсуждаются более подробно.

 

По умолчанию LiveKd берет снимок локального компьютера и выполнений Kd.exe. -w и -k опции, которым позволяют Вы определить WinDbg.exe или любой другой отладчик вместо Kd.exe. LiveKd передает любые дополнительные параметры командной строки, которые Вы определяете на отладчике, сопровождаемом -z и путем к моделируемому файлу дампа.

Чтобы отладить виртуальную машину Hyper-V от узла, определите -hv и или дружественное имя или GUID VM. Чтобы перечислить имена и GUIDs доступного VMs, выполните LiveKd с -hvl опцией. Отметьте, что можно отладить только один VM на узле за один раз.

С -o опцией LiveKd только сохраняет дамп ядра целевой системы к указанному dumpfile и не запускает отладчик. Эта опция полезна для получения системных дампов для офлайнового анализа. Если цель - Hyper-V VM, можно также добавить -p к командной строке, чтобы приостановить VM, в то время как снимок получается, чтобы получить абсолютно непротиворечивый снимок.

Если Вы запустите отладчик и не определите -k и путь к отладчику, то LiveKd найдет Kd.exe или WinDbg.exe если это будет в одном из следующих расположений:

■                Текущий каталог, когда Вы запускаете LiveKd.

■                Тот же самый каталог как LiveKd.

■                Установка по умолчанию соединяет каналом для Средств отладки (" %ProgramFiles %\Debugging Инструменты для Windows (x86)" на x86 или "%ProgramFiles %\Debugging Инструменты для Windows (x64)" на x64).

■                Каталог определяется в переменной ПУТИ.

Если _NT_SYMBOL_PATH переменная окружения не была сконфигурирована, LiveKd спросит, хотите ли Вы, чтобы это сконфигурировало систему, чтобы использовать сервер символа Microsoft, и затем это попросит локальную папку, в которой можно загрузить файлы символа (C:\Symbols по умолчанию).

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

Отметьте, что отладчик будет жаловаться, что не может найти символы для LiveKdD.SYS. Это ожидается, потому что я не сделал символы для LiveKdD.SYS доступными. Нехватка этих символов не влияет на поведение отладчика.

Примеры LiveKd

Эта командная строка отлаживает снимок локального компьютера, передавая параметры к WinDbg, чтобы записать файл системного журнала а не вывести на экран Рабочее пространство Сохранения? диалоговое окно:

livekd-w-Q - логотип C:\dbg.txt.

 

Эта командная строка получает дамп ядра локального компьютера и не запускает отладчик:

livekd-o C:\snapshot.dmp.

Когда работающийся узел Hyper-V, эта команда перечисляет виртуальные машины, доступные для отладки; это тогда показывает демонстрационный вывод:

C: \> 1ivekd-hv!.

 

Можно тогда использовать или GUID или имя VM из перечисления, чтобы определить VM, чтобы отладить. Эта команда приостанавливает "Win7 Окончательный x64" VM от примера и получает дамп ядра той системы, возобновляя VM после того, как дамп был получен:

livekd-p-o C:\snapshot.dmp-hv DFA26971-62D7-4190-9ED0-61D1B910466B.

Наконец, эта команда отлаживает снимок "WinXP x86 (SP3)" VM, использующий Kd.exe:

livekd-hv "WinXP x86 (SP3)".