Что такое отладка ядра. Средства отладки режима ядра операционной системы Windows
Отладчики режима ядра находятся между CPU и операционной системой. Это означает, что, когда вы останавливаете отладчик режима ядра, операционная система также полностью останавливается. Нетрудно сообразить, что переход операционной системы к резкому останову полезен, когда вы работаете с таймером и над проблемами синхронизации. Все-таки, за исключением одного отладчика, о котором будет рассказано ниже (в разделе "Отладчик SoftlCE" данной главы), нельзя отлаживать код пользовательского режима с помощью отладчиков режима ядра.
Отладчиков режима ядра не так много. Вот некоторые из них: Windows 80386 Debugger (WDEB386), Kernel Debugger (1386KD), WinDBG и SoftlCE. Каждый из этих отладчиков кратко описан в следующих разделах.
Отладчик WDEB386
WDEB386 - это отладчик режима ядра Windows 98, распространяемый в составе Platform SDK. Этот отладчик полезен только для разработчиков, пишущих драйверы виртуальных устройств Windows 98 (VxD). Подобно большинству отладчиков режима ядра для операционных систем Windows, отладчик WDEB386 требует для работы две машины и нуль-модемный кабель. Две машины необходимы потому, что часть отладчика, которая выполняется на целевой машине, имеет ограниченный доступ к ее аппаратным средствам, так что он посылает свой вывод и получает команды от другой машины.
Отладчик WDEB386 имеет интересную историю. Он начинался как внутренний фоновый инструмент Microsoft в эпоху Windows 3.0. Его было трудно использовать, и он не имел достаточной поддержки для отладки исходного кода и других приятных свойств, которыми нас испортили отладчики Visual C++ и Visual Basic.
"Точечные" (DOT) команды - наиболее важная особенность WDEB386. Через прерывание INT 41 можно расширять WDEB386 с целью добавления команд. Эта расширяемость позволяет авторам VxD-драйверов создавать заказные отладочные команды, которые дают им свободный доступ к информации в их виртуальных устройствах. Отладочная версия Windows 98 поддерживает множество DOT-команд, которые позволяют наблюдать точное состояние операционной системы в любой точке процесса отладки.
Отладчик I386KD
Windows 2000 отличается от Windows 98 тем, что реально действующая часть отладчика режима ядра является частьюNTOSKRNL. EXE - файла главного ядра операционной системы Windows 2000. Этот отладчик доступен как в свободных (выпускных), так и в проверенных (отладочных) конфигурациях операционной системы. Чтобы включить отладку в режиме ядра, установите параметр загрузчика /DEBUG в BOOT. INI и, дополнительно, опцию загрузчика /DEBUGPORT, если необходимо установить значение коммуникационного порта отладчика режима ядра, отличающееся от умалчиваемого (СОМ1). I386KD выполняется на своей собственной машине и сообщается с машиной Windows 2000 через кабель нуль-модема.
Отладчик режима ядра NTOSKRNL. EXE делает только то, что достаточно для управления CPU, так чтобы операционная система могла быть отлажена. Большая часть отладочной работы - обработка символов, расширенные точки прерывания и дизассемблирование - выполняется на стороне 1386KD. Одно время Windows NT 4 Device Driver Kit (DDK) документировал протокол, используемый в кабеле нуль-модема. Однако Microsoft больше его не документирует.
Мощь 1386KD очевидна, если посмотреть на все команды, которые он предлагает для доступа к внутреннему состоянию Windows 2000. Знание механизма работы драйверов устройств в Windows 2000 поможет программисту следить за выводом многих команд. Не смотря на всю свою мощь, i386KD почти никогда не применяется, потому что это консольное приложение, которое очень утомительно использовать для отладок исходного уровня.
Введение
1. Типы Windows-отладчиков
2. Отладчики режима пользователя
3. Отладчики режима ядра
3.1 Отладчик WDEB386
3.2 Отладчик I386KD
3.3 Отладчик Win DBG
3.4 Отладчик SoftICE
4. Общий вопрос отладки
5. Автоматический запуск приложений в отладчике
5.1 Быстрые клавиши прерываний
Заключение
Литература
Введение
Изучение механизма работы программных инструментов - наиболее трудная часть отладочного процесса. Только понимая возможности и ограничения инструментов, можно получать от них большую отдачу и тратить меньше времени на отладку. Как правило, отладчики чрезвычайно полезны, но могут привести к довольно тонким проблемам, заводящим программиста в тупик. В этой главе показано, что такое отладчик и как различные отладчики работают в операционных системах Win32 (32-разрядных операционных системах Windows фирмы Microsoft).
При этом сосредоточимся на тех специальных свойствах отладчиков вообще, которые включены, когда под управлением последних выполняется какой-то программный процесс. Кроме того, здесь поясняются возможности усиления некоторых свойств 32-разрядных операционных систем Windows, позволяющие облегчить процесс отладки. Будут представлены два авторских отладчика, исходный код которых можно найти на сопровождающем компакт-диске. Первый (MinDBG) имеет достаточные возможности для того, чтобы его называли отладчиком. Второй (WDBG) - пример отладчика Microsoft Windows, который делает почти все, что и реальный системный отладчик, включая манипулирование таблицами символов, обработку точек прерывания, генерацию кода дизассемблера и координирование с графическим интерфейсом пользователя (GUI). При обсуждении WDBG мы покажем, как работают точки прерывания, и обсудим, что представляют собой различные файлы символов (symbol files).
Прежде чем переходить к основному материалу этой главы, определим два стандартных термина, которые будут часто использоваться в этой книге: основной (или базовый) отладчик (debugger) и подчиненный отладчик (debuggee). Проще говоря, основной отладчик - это процесс, который в отладочном отношении может контролировать другой процесс, а подчиненный отладчик - это процесс, запускаемый под основным отладчиком. В некоторых операционных системах основной отладчик называют родительским процессом, а подчиненный - дочерним.
Отла́дчик (деба́ггер, англ. debugger от bug) - компьютерная программа, предназначенная для поиска ошибок в других программах, ядрах операционных систем, SQL-запросах и других видах кода. Отладчик позволяет выполнять трассировку, отслеживать, устанавливать или изменять значения переменных в процессе выполнения кода, устанавливать и удалять контрольные точки или условия остановки и т.д.
Большинству разработчиков больше знакомы отладчики
пользовательского режима. Не удивительно, что отладчики этого режима
предназначены для отладки приложений пользовательского режима (user-mode applications). Главный пример
отладчика режима пользователя - отладчик Microsoft Visual C++. Отладчики режима
ядра, как следует из их названия, - это такие отладчики, которые позволяют
отлаживать ядро операционной системы. Они используются главным образом теми,
кто пишет (и отлаживает, конечно) драйверы устройств.
2. Отладчики режима пользователя
Отладчики режима пользователя предназначены для отладки любого приложения, выполняющегося в режиме пользователя, включая любые GUI-программы, а также такие не совсем обычные приложения, как службы (services) Windows 2000. В общем случае, отладчики этого типа поддерживают графический интерфейс пользователя (GUI1). Главный признак таких отладчиков - они используют отладочный интерфейс прикладного программирования (отладочный API) Win32. Поскольку операционная система помечает подчиненный отладчик как "выполняющийся в специальном режиме", то, чтобы выяснить, выполняется ли ваш процесс под отладчиком, можно использовать API-функцию IsDebuggerPresent.
При поставке отладочного API Win32 подразумевается следующее соглашение: раз процесс выполняется под отладочным API (и делает его, таким образом, подчиненным процессом), основной отладчик не может отделиться от данного процесса. Эти симбиозные отношения означают, что если основной отладчик завершает работу, то завершается также и подчиненный отладчик. Основной отладчик ограничивается отладкой только подчиненного отладчика и любых порожденных им процессов (если основной отладчик поддерживает процессы-потомки).
GUI - Graphical User Interface. - Пер.
Для интерпретируемых языков и исполнительных (run-time) систем, которые используют подход виртуальной машины, полную отладочную среду обеспечивают сами виртуальные машины, и они не используют отладочный API Win32. Вот некоторые примеры таких типов сред: виртуальные Java-машины (JVM) фирм Microsoft или Sun, среда сценариев для Web-приложений фирмы Microsoft, и интерпретатор р-кода в системе Microsoft Visual Basic.
отладчик ядро операционная система
Мы доберемся до отладки в Visual Basic в главе 7, но знайте, что интерфейс р-кода Visual Basic не документирован. Не будем вникать в отладочные интерфейсы Java и сценариев, эти темы выходят за рамки данной книги. Дополнительную информацию по отладке и профилированию Microsoft JVM ищите в разделе "Debugging and Profiling Java Applications" (Отладка и профилирование приложений Java) на MSDN. Набор таких интерфейсов весьма богат и разнообразен и позволяет полностью управлять работой JVM. Информацию о написании отладчика сценария можно найти в разделе MSDN "Active Script Debugging API Objects" (Активные объекты отладочных API-сценариев). Подобно JVM, объекты отладчика сценариев обеспечивают богатый интерфейс для сценариев доступа и документирования.
Отладочный API Win32 использует удивительно много программ. К ним
относятся: отладчик Visual C++, который подробно рассматривается в главах 5 и 6; отладчик
Windows (WinDBG), который обсуждается в
следующем разделе (посвященном отладчику режима ядра); программа BoundsChecker фирмы Compuware NuMega; программа Platform SDK HeapWalker; программа Platform SDK Depends; отладчики Borland Delphi и C++ Builder, а также символический
отладчик NT Symbolic Debugger (NTSD). Я уверен, что их намного больше.
3. Отладчики режима ядра
Отладчики режима ядра находятся между CPU и операционной системой. Это означает, что, когда вы останавливаете отладчик режима ядра, операционная система также полностью останавливается. Нетрудно сообразить, что переход операционной системы к резкому останову полезен, когда вы работаете с таймером и над проблемами синхронизации. Все-таки, за исключением одного отладчика, о котором будет рассказано ниже (в разделе "Отладчик SoftlCE" данной главы), нельзя отлаживать код пользовательского режима с помощью отладчиков режима ядра.
Отладчиков режима ядра не так много. Вот некоторые из них: Windows 80386 Debugger (WDEB386), Kernel Debugger (1386KD), WinDBG и SoftlCE. Каждый из этих отладчиков
кратко описан в следующих разделах.
3.1 Отладчик WDEB386
WDEB386 - это отладчик режима ядра Windows 98, распространяемый в составе Platform SDK. Этот отладчик полезен только для разработчиков, пишущих драйверы виртуальных устройств Windows 98 (VxD). Подобно большинству отладчиков режима ядра для операционных систем Windows, отладчик WDEB386 требует для работы две машины и нуль-модемный кабель. Две машины необходимы потому, что часть отладчика, которая выполняется на целевой машине, имеет ограниченный доступ к ее аппаратным средствам, так что он посылает свой вывод и получает команды от другой машины.
Отладчик WDEB386 имеет интересную историю. Он начинался как внутренний фоновый инструмент Microsoft в эпоху Windows 3.0. Его было трудно использовать, и он не имел достаточной поддержки для отладки исходного кода и других приятных свойств, которыми нас испортили отладчики Visual C++ и Visual Basic.
"Точечные" (DOT) команды - наиболее
важная особенность WDEB386. Через прерывание INT 41 можно расширять WDEB386 с целью добавления
команд. Эта расширяемость позволяет авторам VxD-драйверов создавать
заказные отладочные команды, которые дают им свободный доступ к информации в их
виртуальных устройствах. Отладочная версия Windows 98 поддерживает
множество DOT-команд, которые позволяют наблюдать точное состояние операционной
системы в любой точке процесса отладки.
3.2 Отладчик I386KD
Windows 2000 отличается от Windows 98 тем, что реально действующая часть отладчика режима ядра является частьюNTOSKRNL. EXE - файла главного ядра операционной системы Windows 2000. Этот отладчик доступен как в свободных (выпускных), так и в проверенных (отладочных) конфигурациях операционной системы. Чтобы включить отладку в режиме ядра, установите параметр загрузчика /DEBUG в BOOT. INI и, дополнительно, опцию загрузчика /DEBUGPORT, если необходимо установить значение коммуникационного порта отладчика режима ядра, отличающееся от умалчиваемого (СОМ1). I386KD выполняется на своей собственной машине и сообщается с машиной Windows 2000 через кабель нуль-модема.
Отладчик режима ядра NTOSKRNL. EXE делает только то, что достаточно для управления CPU, так чтобы операционная система могла быть отлажена. Большая часть отладочной работы - обработка символов, расширенные точки прерывания и дизассемблирование - выполняется на стороне 1386KD. Одно время Windows NT 4 Device Driver Kit (DDK) документировал протокол, используемый в кабеле нуль-модема. Однако Microsoft больше его не документирует.
Мощь 1386KD очевидна, если посмотреть на все команды, которые
он предлагает для доступа к внутреннему состоянию Windows 2000. Знание механизма
работы драйверов устройств в Windows 2000 поможет программисту следить за выводом
многих команд. Не смотря на всю свою мощь, i386KD почти никогда не
применяется, потому что это консольное приложение, которое очень утомительно
использовать для отладок исходного уровня.
3.3 Отладчик Win DBG
WinDBG - это отладчик, который поставляется в составе Platform SDK. Можно также загрузить его с#"897008.files/image001.gif">
Рис 1. Вывод программы GFLAGS. EXE
Листинг 4-1. Пример разрушения heap-области Windows 2000
void main (void)
HANDLE hHeap = HeapCreate (0, 128, 0);
// Распределить память для блока размером в 10 байтов.
LPVOID pMem = HeapAlloc (hHeap, 0,10);
// Записать 12 байт в 10-байтовый блок (переполнение heap-области).
memset (pMem, OxAC,
// Распределить новый блок размером 20 байт.
LPVOID pMem2 = HeapAlloc (hHeap, 0, 20);
// Записать 1 байт во второй блок.
char * pUnder = (char *) ((DWORD) pMem2 - 1);
// Освободить первый блок. Это обращение к HeapFree будет
// инициировать точку прерывания в коде отладочной heap-области
// операционной системы.
HeapFree (hHeap, 0, pMem);
// Освободить второй блок. Заметим, что этот вызов не будет
// выдавать соообщения о неполадке
HeapFree (hHeap, 0, pMem2);
// Освободить фиктивный блок. Заметим, что этот вызов не будет
// выдавать сообщения о неполадке
Если установить те же флажки, что на рис.4.1, и повторить выполнение HEAPER. EXE, то будет получен следующий, более многословный вывод:
PAGEHEAP: process 0x490 created debug heap 00430000
(flags 0xl, 50, 25, 0, 0): process 0x490 created debug heap 00CF0000
(flags Oxl, 50, 25, 0, - 0): process 0x490 created debug heap 01600000
(flags Oxl, 50, 25, 0, 0): Tail fill corruption detected:at 0x01606FF0size 0x0000000Asize 0x00000010at Ox01606FFA: Attempt to reference block which is not allocated
Содержимое листинга объясняют названия флажков, установленных панелью Global Flags.
Обсуждая программу GFLAGS. EXE, я хочу указать на одну очень полезную опцию - Show Loader Snaps. Если вы установите этот
флажок и выполните приложение, то увидите то, что называют снимком (snap) приложения, в котором
видно, где Windows 2000 загружает DLL-файлы и как она начинает организацию импорта.
Если необходимо точно видеть, что делает загрузчик Windows 2000 при загрузке
приложения (особенно в том случае, когда в нем обнаружена проблема), то
включение этой опции может оказаться весьма полезным мероприятием. Дополнительную
информацию по снимкам загрузчика можно получить в колонке Мэта Пьетрека "Under the Hood" в сентябрьском
выпуске Microsoft Systems Journal за 1999 год.
5. Автоматический запуск приложений в отладчике
Самыми трудными для отладки типами приложений являются те приложения, которые запускаются другим процессом. В эту категорию нападают службы Windows 2000 и внепроцессные (out-of-process) СОМ-серверы (СОМ out-of-process servers). Чтобы заставить отладчик прикрепиться к процессу, во многих случаях можно использовать API-функцию DebugBreak. В двух случаях, однако, эта функция работать не будет. Во-первых, она иногда не работает со службами Windows 2000. Если нужно отладить запуск службы, то вызов DebugBreak присоединит отладчик, но к тому времени, когда отладчик запустится, может быть исчерпан интервал тайм-аута службы, и Windows 2000 остановит ее. Во-вторых, DebugBreak не будет работать, когда нужно отлаживать внепроцессный СОМ-сервер. Если вы вызовете DebugBreak, обработчик СОМ-ошибок отловит исключение точки прерывания и завершит СОМ-сервер. К счастью, Windows 2000 позволяет указать, что приложение должно стартовать в отладчике. Это свойство позволяет начать отладку прямо с первой инструкции. Однако, прежде чем вы включите это свойство для службы Windows 2000, удостоверьтесь, что в этой службе сконфигурирована возможность взаимодействия с рабочим столом Windows 2000.
Свойство запуска с отладчиком можно включить двумя способами. Самый легкий - запустить утилиту GFLAGS. EXE и выбрать переключатель Image File Options (см. рис.4.1). После ввода в редактируемое поле Image File Name имени двоичного файла программы установите флажок Debugger в группе Image Debugger Options ) и введите в редактируемое поле рядом с этим флажком полный путь к отладчику.
Более трудный способ: нужно вручную установить необходимые параметры з подходящие разделы реестра (с помощью редактора RegEdit). В разделе_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NTXCurrent Version\Image Tile Execution Options
создайте подраздел, имя которого совпадает с именем файла вашего приложения. Например, если имя приложения - FOO. EXE, то имя подраздела реестра тоже FOO. EXE. В этом подразделе создайте новый строковый параметр с именем Debugger. В диалоговом окне Изменение строкового параметра введите с клавиатуры полное (вместе с путем к каталогу) имя файла выбранного вами отладчика. Если вы указали GFLAGS. EXE и установили некоторые глобальные опции, то сможете заметить в ключе вашего приложения строчное значение GiobaiFiag.
Теперь при запуске вашего приложения автоматически
загружается и запускается и отладчик. Опции командной строки для отладчика
также можно определить в строковом параметре Debugger (вслед за именем
программы отладчика). Например, для того чтобы использовать отладчик WinDBG и автоматически
инициировать отладку, как только стартует WinDBG, нужно в диалоговом окне
изменения строкового параметра Debugger ввести значение d: \platform sdk\bin\windbg. exe - g.
5.1 Быстрые клавиши прерываний
Иногда нужно быстро войти в отладчик. Если вы отлаживаете
консольные приложения, то нажатие клавиш
Полезным свойством как Windows 2000, так и Windows NT 4 является возможность в
любое время переходить в отладчик также и в GUI-приложениях. При
выполнении под отладчиком нажатие клавиши
В Windows NT 4 быстрая клавиша прерывания
HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\WindowsNT\CurrentVersion\AeDebug
установите для параметра userDebuggerHotKey значение кода клавиши (VK_*). Например, чтобы
использовать клавишу
Заключение
Мы рассмотрели основные черты отладки, его типы и виды, общий вопрос отладки, а также ошибки и способы их обнаружения.
Существующие отладчики играют важную роль в разработке ПО при поиске логических ошибок, предоставляя широкий набор средств, включающих поддержку исходных текстов, трассировку выполнения приложения, динамическую модификацию памяти, и. т.д.
Литература
1.. aspx?.aspx?id=553022>
2. https:
// ru. wikipedia.org/wiki/%D0%9E%D1%82%D0%BB%D0%B0%D0%B4%D1%87%D0%B8%D0%BA
Http://bourabai.
kz/alg/debug4. htm
4. Костюхин К. - ОТЛАДКА СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ. Обзор
- Авторы:
Баринов С.С., Шевченко О.Г.
- Год:
- Источник:
Информатика и компьютерные технологии / Материалы VI международной научно-технической конференции студентов, аспирантов и молодых ученых - 23-25 ноября 2010 г., Донецк, ДонНТУ. - 2010. - 448 с.
Аннотация
Приведен сравнительный анализ отладки режима пользователя и режима ядра применительно к операционной системе Microsoft Windows, выделены отличия и проблемы организации отладки последнего. На основе полученных результатов сформулированы основные требования к построению отладчиков режима ядра в случае аварийной и интерактивной отладки. Проведен анализ существующих решений на предмет соответствия требованиям. В частности, особое внимание уделено отладчику Microsoft Windows Debugger.
Основная часть
Отладка - это процесс определения и устранения причин ошибок в программном обеспечении. В некоторых проектах отладка занимает до 50 % общего времени разработки . Отладка может быть значительно упрощена при использовании специализированных инструментов, которые постоянно совершенствуются. Основным таким инструментом является отладчик, позволяющий контролировать выполнение ПО, наблюдать за его ходом и вмешиваться в него. Средства отладки ядра преимущественно используются разработчиками драйверов .
Инструментарий разработки прикладного программного обеспечения предлагает программисту широкий спектр возможностей. Любая интегрированная среда разработки включает в себя и возможность отладки без необходимости использования сторонних утилит. Если же речь идет о системном программном обеспечении и разработке драйверов в частности, то в силу его специфики процесс разработки чрезвычайно затруднен и мало автоматизирован. Все фазы разработки, в числе которых и отладка, являются раздельными. Для проведения каждой из них требуются особые условия: написание программного кода выполняется на полноценной компьютерной системе, отладка - на отладочной системе, тестирование - в зависимости от обстоятельств и т.д. Сам же отладчик режима ядра более сложен в освоении и, соответственно, менее дружественен.
В целом можно говорить о недостатке средств отладки ядра. Хотя таковые средства имеются в наличии, зачастую говорить об альтернативах не приходится. Например, отладчик Microsoft Windows Debugger имеет слишком высокий порог вхождения. Многие программисты говорят о первом негативном опыте при знакомстве с ним, а большинство его возможностей остаются незатребованными.
Исходя из структуры виртуального адресного пространства, если в приложении допущена ошибка, вследствие которой приложение выполнит запись данных в произвольное место памяти, то приложение повредит только собственную память и не повлияет на работу других приложений и операционной систему. Тогда как программный код режима ядра в состоянии повредить важные структуры данных операционной системы, что неминуемо приведет к общему сбою. Неэффективно написанный драйвер также может стать причиной серьезной деградации всей операционной системы.
-
Современные отладчики обеспечивают следующие базовые функции:
- отладка на уровне исходного кода;
- управление выполнением;
- просмотр и изменение памяти;
- просмотр и изменение содержимого регистров процессора;
- просмотр стека вызовов.
Для облегчения работы с дизассемблированным кодом применяются т.н. отладочные символы. Во время работы компоновщика, кроме образа исполняемого файла также может быть создан файл данных, содержащий информацию, которая не требуется при выполнении программы, но чрезвычайно полезна при ее отладке: имена функций, глобальных переменных, описание структур. Отладочные символы доступны для всех исполняемых файлов операционной системы Windows .
Под управлением выполнением подразумевается способность прерывать и возобновлять выполнение программного кода по достижению заданной команды в программном коде. Если программный код исполняется в пошаговом режиме - прерывание возникает для каждой лексемы языка программирования или при выходе из подпрограммы. При свободном исполнении прерывание выполнения возникает в заранее оговоренных участках кода - местах, в которых установлены точки останова.
При прерывании кода режима ядра возникают следующая дилемма. Отладчик для взаимодействия с программистом использует интерфейс пользователя. Т.е. как минимум видимая часть отладчика выполняется в пользовательском режиме и для его построения естественно использует интерфейс прикладного программирования (Windows API), который в свою очередь опирается на модули режима ядра. Таким образом, приостановка кода режима ядра может привести к взаимной блокировке: система перестанет отвечать на запросы пользователя.
Для доступа к памяти ядра составные части отладчика также должны выполняться в режиме ядра. Это ведет к возникновению сразу двух проблем, являющиеся очевидным следствием организации памяти в защищенном режиме процессора.
Первая проблема касается трансляции виртуальных адресов памяти. Драйвера постоянно взаимодействуют с приложениями пользовательского режима, выполняя обращение к их памяти. Операционная система Windows транслирует виртуальные адреса в физические, руководствуясь понятием контекста потока. Контекст потока - структура, отражающая состояние потока и включающая, в частности, набор регистров и некоторую другую информацию. Когда управление передается другому потоку, возникает переключение контекста, при котором сохраняется информация об одном потоке и восстанавливается информации о другом. При переключении контекста потока на поток другого процесса переключается также и каталог страниц, используемый для трансляции виртуальных адресов в физические .
Особенность заключается в том, что при диспетчеризации системных вызовов операционная система Windows не переключает контекст. Благодаря этому код режима ядра может использовать виртуальные адреса пользовательского режима.
Иначе дело обстоит при диспетчеризации прерываний или выполнении системных потоков. Прерывание может произойти в любой момент, поэтому нельзя предугадать, какой контекст потока будет использоваться. Системные же потоки не принадлежат какому-либо процессу и не могут транслировать виртуальные адреса пользовательского режима . Отсюда следует, что в этих ситуациях нельзя обратиться к памяти пользовательского режима.
Второй проблемой является обращение к перемещаемой памяти. Большая часть информации в памяти является перемещаемой и в любой момент может быть перемещена из физической памяти на жесткий диск в страничный файл. Если обратиться к странице, которая отсутствует в физической памяти, в нормальной ситуации процессор сгенерирует прерывание Page Fault, которое будет обработано диспетчером памяти, и в результате страница будет прочитана из страничного файла и загружена в физическую память.
Описанное поведение нарушается, если программный код отладчика вынужден использовать высокий уровень запросов прерываний (interrupt request levels, IRQL). При IRQL, совпадающем с или превышающем IRQL диспетчера памяти последний не сможет загрузить отсутствующую страницу, т.к. операционная система будет блокировать прерывание Page Fault. Это приведет к краху операционной системы .
Отладку принято разделять на интерактивную и аварийную. При интерактивной локальной отладке отладчик выполняется в той же системе, что и объект отладки. При интерактивной удаленной отладке отладчик и объект отладки выполняется в разных системах. При отладке кода ядра система должна контролироваться, начиная с первых этапов ее загрузки, когда сеть еще не функционирует, поэтому для связи систем применяют простые последовательные интерфейсы, такие как COM, FireWire, USB. В последнее время, благодаря тенденциям развития виртуализации ПО на разных уровнях абстракций, все чаще привлекают виртуальные машины. Гостевая ОС выступает в качестве отлаживаемой, размещенная ОС включает интерфейс пользователя отладчика.
Таким образом, для аварийной отладки не требуется установка средства отладки на тестовом компьютере. В дистрибутив операционной системы Windows включены механизмы для реализации аварийной отладки. Перед перезагрузкой операционная система может сохранять информацию о своем состоянии, которую разработчик может проанализировать и выяснить причину. Такая информация, сохраненная в файл, называется дампом памяти.
Основные средства отладки режима ядра предоставляются самим производителем операционной системы Windows в рамках свободно распространяемого пакета «Debugging Tools for Windows». Средства включают графический и консольный отладчики WinDbg и KD соответственно (далее Windows Debugger). Работа этих отладчиков опирается на механизмы, предусмотренные разработчиками операционной системы и заложенные в ее ядре.
Основным режимом для Windows Debugger является режим интерпретатора команд. Благодаря модульной структуре, наряду с поставляемыми разработчиками командами Windows Debugger поддерживает сторонние модули, называемыми расширениями. В действительности большинство встроенных команд также оформлено в виде расширений.
Windows Debugger ориентирован на удаленную интерактивную и аварийные отладки, при использовании которых раскрываются все его возможности. В тоже время полноценная локальная интерактивная отладка не поддерживается: отладчик позволяет только просматривать некоторые структуры ядра.
Существует модуль расширения для Windows Debugger под названием LiveKD, созданный Марком Руссиновичем, который в некотором смысле реализует локальную интерактивную отладку. LiveKD на ходу создает дамп памяти рабочей системы и использует его для отладки.
Пакет инструментов «Debugging Tools for Windows» регулярно обновляется и поддерживает все современные операционный системы Windows.
Отладчик ядра SoftICE, выпускавшийся компанией Compuware в пакете программ DriverStudio, традиционно выступал альтернативой пакету «Debugging Tools for Windows». Отличительной чертой SoftICE являлась реализация локальной интерактивной отладки на поддерживаемом аппаратном обеспечении. Отладчик практически полностью мог контролировать работу операционной системы.
С 3 апреля 2006 года продажа продуктов семейства «DriverStudio» было прекращена по причине «множества технических и деловых проблем, а также общего состояния рынка». Последней версией операционной системы, поддержка которой была реализована, является Windows XP Service Pack 2. Как правило, пакеты сервисных обновлений не изменяют прикладной интерфейс операционной системы, но номера системных вызовов и другая недокументированная информация может претерпевать изменение. Отладчик SoftICE опирался на жестко-прописанные адреса внутренних структур данных. Как следствие - с выходом Service Pack 3 совместимость была нарушена. Очевидно, что более поздние версии операционной системы Windows также не поддерживаются.
Syser Kernel Debugger создан небольшой китайской компанией Sysersoft как замена отладчику SoftICE. Первая финальная версия была выпущена в 2007 году. Как и SoftICE, Syser Kernel Debugger способен выполнять интерактивную отладку на работающей системе. Поддерживаемыми являются только 32-разрядные редакции современных версий Windows.
На данный момент Windows Debugger является основным инструментом среди разработчиков модулей ядра. Его также использует команда разработчиков ядра операционной системы Windows.
чПФ ОЕЛПФПТЩЕ ХЛБЪБОЙС РП ТБВПФЕ У ПФМБДЛПК СДТБ У БЧБТЙКОЩНЙ ДБНРБНЙ РБНСФЙ. лБЛ РТБЧЙМП, ЧБН ОХЦОП ВХДЕФ ЪБДБФШ ПДОП ЙЪ ХУФТПКУФЧ РПДЛБЮЛЙ, РЕТЕЮЙУМЕООЩИ Ч ЖБКМЕ /etc/fstab . уВТПУ ПВТБЪПЧ РБНСФЙ ОБ ХУФТПКУФЧБ, ОЕ СЧМСАЭЙЕУС ХУФТПКУФЧБНЙ РПДЛБЮЛЙ, ОБРТЙНЕТ, МЕОФЩ, Ч ДБООЩК НПНЕОФ ОЕ РПДДЕТЦЙЧБАФУС.
Note: йУРПМШЪХКФЕ ЛПНБОДХ dumpon (8) ДМС ХЛБЪБОЙС СДТХ НЕУФБ, ЗДЕ ОХЦОП УПИТБОСФШ БЧБТЙКОЩЕ ДБНРЩ. рПУМЕ ОБУФТПКЛЙ РП ЛПНБОДЕ swapon (8) ТБЪДЕМБ РПДЛБЮЛЙ ДПМЦОБ ВЩФШ ЧЩЪЧБОБ РТПЗТБННБ dumpon . пВЩЮОП ЬФП ЧЩРПМОСЕФУС ЪБДБОЙЕН РЕТЕНЕООПК dumpdev Ч ЖБКМЕ rc.conf (5) . еУМЙ ЪБДБОБ ЬФБ РЕТЕНЕООБС, ФП РПУМЕ УВПС РТЙ РЕТЧПК НОПЗПРПМШЪПЧБФЕМШУЛПК РЕТЕЪБЗТХЪЛЕ ВХДЕФ БЧФПНБФЙЮЕУЛЙ ЪБРХЭЕОБ РТПЗТБННБ savecore (8) . пОБ УПИТБОЙФ БЧБТЙКОЩК ДБНР СДТБ Ч ЛБФБМПЗ, ЪБДБООЩК Ч РЕТЕНЕООПК dumpdir ЖБКМБ rc.conf . рП ХНПМЮБОЙА ЛБФБМПЗПН ДМС БЧБТЙКОЩИ ДБНРПЧ СЧМСЕФУС /var/crash .
мЙВП ЧЩ НПЦЕФЕ ЪБДБФШ ХУФТПКУФЧП ДМС УВТПУБ ПВТБЪБ РБНСФЙ СЧОП ЮЕТЕЪ РБТБНЕФТ dump Ч УФТПЛЕ config ЛПОЖЙЗХТБГЙПООПЗП ЖБКМБ ЧБЫЕЗП СДТБ. фБЛПК УРПУПВ ЙУРПМШЪПЧБФШ ОЕ ТЕЛПНЕОДХЕФУС Й ПО ДПМЦЕО ЙУРПМШЪПЧБФШУС, ФПМШЛП ЕУМЙ ЧЩ ИПФЙФЕ РПМХЮБФШ БЧБТЙКОЩЕ ПВТБЪЩ РБНСФЙ СДТБ, ЛПФПТПЕ БЧБТЙКОП ЪБЧЕТЫБЕФ УЧПА ТБВПФХ РТЙ ЪБЗТХЪЛЕ.
Note: дБМЕЕ ФЕТНЙО gdb ПЪОБЮБЕФ ПФМБДЮЙЛ gdb , ЪБРХЭЕООЩК Ч ``ТЕЦЙНЕ ПФМБДЛЙ СДТБ"". рЕТЕИПД Ч ЬФПФ ТЕЦЙН ДПУФЙЗБЕФУС ЪБРХУЛПН gdb У РБТБНЕФТПН -k . ч ТЕЦЙНЕ ПФМБДЛЙ СДТБ gdb ЙЪНЕОСЕФ УЧПЈ РТЙЗМБЫЕОЙЕ ОБ (kgdb) .
Tip: еУМЙ ЧЩ ЙУРПМШЪХЕФЕ FreeBSD ЧЕТУЙЙ 3 ЙМЙ ВПМЕЕ ТБООАА, ЧЩ ДПМЦОЩ ЧЩРПМОЙФШ ХУЕЮЕОЙЕ ПФМБДПЮОПЗП СДТБ ЛПНБОДПК strip, Б ОЕ ХУФБОБЧМЙЧБФШ ВПМШЫПЕ ПФМБДПЮОПЕ СДТП:
# cp kernel kernel.debug # strip -g kernel
ьФПФ ЫБЗ ОЕ ФБЛ ХЦ Й ОЕПВИПДЙН, ОП ТЕЛПНЕОДХЕН. (чП FreeBSD 4 Й ВПМЕЕ РПЪДОЙИ ТЕМЙЪБИ ЬФПФ ЫБЗ ЧЩРПМОСЕФУС БЧФПНБФЙЮЕУЛЙ Ч ЛПОГЕ РТПГЕУУБ РПУФТПЕОЙС СДТБ make .) лПЗДБ СДТП ХУЕЮЕОП, БЧФПНБФЙЮЕУЛЙ ЙМЙ РТЙ РПНПЭЙ ЛПНБОД ЧЩЫЕ, ЧЩ НПЦЕФЕ ХУФБОПЧЙФШ ЕЗП ПВЩЮОЩН ПВТБЪПН, ОБВТБЧ make install .
ъБНЕФШФЕ, ЮФП Ч УФБТЩИ ЧЕТУЙСИ FreeBSD (ДП 3.1, ОЕ ЧЛМАЮБС ЬФПФ ТЕМЙЪ), ЙУРПМШЪХЕФУС СДТБ Ч ЖПТНБФЕ a.out, РПЬФПНХ ЙИ ФБВМЙГЩ УЙНЧПМПЧ ДПМЦОЩ ТБУРПМБЗБФШУС РПУФПСООП Ч РБНСФЙ. у ВПМШЫПК ФБВМЙГЕК УЙНЧПМПЧ Ч ОЕ ХУЕЮЕООПН ПФМБДПЮОПН СДТЕ ЬФП ЙЪМЙЫОСС ФТБФБ. рПУМЕДОЙЕ ТЕМЙЪЩ FreeBSD ЙУРПМШЪХАФ СДТБ Ч ЖПТНБФЕ ELF, ЗДЕ ЬФП ОЕ СЧМСЕФУС РТПВМЕНПК.
еУМЙ ЧЩ ФЕУФЙТХЕФЕ ОПЧПЕ СДТП, УЛБЦЕН, ОБВЙТБС ЙНС ОПЧПЗП СДТБ Ч РТЙЗМБЫЕОЙЙ ЪБЗТХЪЮЙЛБ, ОП ЧБН ОХЦОП ЪБЗТХЦБФШ Й ТБВПФБФШ У ДТХЗЙН СДТПН, ЮФПВЩ УОПЧБ ЧЕТОХФШУС Л ОПТНБМШОПНХ ЖХОЛГЙПОЙТПЧБОЙА, ЪБЗТХЦБКФЕ ЕЗП ФПМШЛП Ч ПДОПРПМШЪПЧБФЕМШУЛПН ТЕЦЙНЕ РТЙ РПНПЭЙ ЖМБЗБ -s , ХЛБЪЩЧБЕНПЗП РТЙ ЪБЗТХЪЛЕ, Б ЪБФЕН ЧЩРПМОЙФЕ ФБЛЙЕ ЫБЗЙ:
# fsck -p # mount -a -t ufs # so your filesystem for /var/crash is writable # savecore -N /kernel.panicked /var/crash # exit # ...to multi-user
ьФБ РПУМЕДПЧБФЕМШОПУФШ ХЛБЪЩЧБЕФ РТПЗТБННЕ savecore (8) ОБ ЙУРПМШЪПЧБОЙЕ ДТХЗПЗП СДТБ ДМС ЙЪЧМЕЮЕОЙС УЙНЧПМЙЮЕУЛЙИ ЙНЕО. йОБЮЕ ПОБ ВХДЕФ ЙУРПМШЪПЧБФШ СДТП, ТБВПФБАЭЕЕ Ч ДБООЩК НПНЕОФ Й, УЛПТЕЕ ЧУЕЗП, ОЙЮЕЗП ОЕ УДЕМБЕФ, РПФПНХ ЮФП БЧБТЙКОЩК ПВТБЪ РБНСФЙ Й УЙНЧПМЩ СДТБ ВХДХФ ПФМЙЮБФШУС.
б ФЕРЕТШ, РПУМЕ УВТПУБ БЧБТЙКОПЗП ДБНРБ, РЕТЕКДЙФЕ Ч ЛБФБМПЗ /sys/compile/WHATEVER Й ЪБРХУФЙФЕ ЛПНБОДХ gdb -k . йЪ РТПЗТБННЩ gdb УДЕМБКФЕ ЧПФ ЮФП:
Symbol-file kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 Й ЧХБМС - ЧЩ НПЦЕФЕ ПФМБЦЙЧБФШ БЧБТЙКОЩК ДБНР, ЙУРПМШЪХС ЙУИПДОЩЕ ФЕЛУФЩ СДТБ ФПЮОП ФБЛЦЕ, ЛБЛ ЧЩ ЬФП ДЕМБЕФЕ У МАВПК ДТХЗПК РТПЗТБННПК.
чПФ ЦХТОБМ ЛПНБОД УЕБОУБ ТБВПФЩ gdb , ЙММАУФТЙТХАЭЙК ЬФХ РТПГЕДХТХ. дМЙООЩЕ УФТПЛЙ ВЩМЙ ТБЪПТЧБОЩ ДМС ХМХЮЫЕОЙС ЮЙФБВЕМШОПУФЙ Й ДМС ХДПВУФЧБ УФТПЛЙ ВЩМЙ РТПОХНЕТПЧБОЩ. чУЕ ПУФБМШОПЕ СЧМСЕФУС ФТБУУЙТПЧЛПК ПЫЙВЛЙ, ТЕБМШОП ЧПЪОЙЛОХЧЫЕК ЧП ЧТЕНС ТБВПФЩ ОБД ДТБКЧЕТПН ЛПОУПМЙ pcvt.
1:Script started on Fri Dec 30 23:15:22 1994 2: # cd /sys/compile/URIAH 3: # gdb -k kernel /var/crash/vmcore.1 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel ...done. 5:IdlePTD 1f3000 6:panic: because you said to! 7:current pcb at 1e3f70 8:Reading in symbols for ../../i386/i386/machdep.c...done. 9: (kgdb) where 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) 11:#1 0xf0115159 in panic () 12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) 13:#3 0xf010185e in db_fncall () 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) 15:#5 0xf0101711 in db_command_loop () 16:#6 0xf01040a0 in db_trap () 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) 18:#8 0xf019d2eb in trap_fatal (...) 19:#9 0xf019ce60 in trap_pfault (...) 20:#10 0xf019cb2f in trap (...) 21:#11 0xf01932a1 in exception:calltrap () 22:#12 0xf0191503 in cnopen (...) 23:#13 0xf0132c34 in spec_open () 24:#14 0xf012d014 in vn_open () 25:#15 0xf012a183 in open () 26:#16 0xf019d4eb in syscall (...) 27: (kgdb) up 10 28:Reading in symbols for ../../i386/i386/trap.c...done. 29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ 31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ 33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ 34:ss = -266427884}) (../../i386/i386/trap.c line 283) 35:283 (void) trap_pfault(&frame, FALSE); 36: (kgdb) frame frame->tf_ebp frame->tf_eip 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) 40:403 return ((*linesw.l_open)(dev, tp)); 41: (kgdb) list 42:398 43:399 tp->t_state |= TS_CARR_ON; 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ 45:401 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) 47:403 return ((*linesw.l_open)(dev, tp)); 48:404 #else 49:405 return ((*linesw.l_open)(dev, tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ 51:407 } 52: (kgdb) print tp 53:Reading in symbols for ../../i386/i386/cons.c...done. 54:$1 = (struct tty *) 0x1bae 55: (kgdb) print tp->t_line 56:$2 = 1767990816 57: (kgdb) up 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) 60: return ((*cdevsw.d_open)(dev, flag, mode, p)); 61: (kgdb) up 62:#2 0xf0132c34 in spec_open () 63: (kgdb) up 64:#3 0xf012d014 in vn_open () 65: (kgdb) up 66:#4 0xf012a183 in open () 67: (kgdb) up 68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ 70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ 71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ 72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) 73:673 error = (*callp->sy_call)(p, args, rval); 74: (kgdb) up 75:Initial frame selected; you cannot go up. 76: (kgdb) quit 77: # exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994
лПННЕОФБТЙЙ Л ЧЩЫЕРТЙЧЕДЕООПНХ ЦХТОБМХ:
УФТПЛБ 6:
ьФП ДБНР, ЧЪСФЩК РТЙ РПНПЭЙ DDB (УНПФТЙ ОЙЦЕ), РПЬФПНХ ЛПННЕОФБТЙК Л БЧБТЙКОПНХ ПУФБОПЧХ ЙНЕЕФ ЙНЕООП ЧЙД ``because you said to!"" Й ФТБУУЙТПЧЛБ УФЕЛБ ЗМХВПЛБ; ПДОБЛП ЙЪОБЮБМШОПК РТЙЮЙОПК РЕТЕИПДБ Ч DDB ВЩМБ БЧБТЙКОБС ПУФБОПЧЛБ РТЙ ЧПЪОЙЛОПЧЕОЙА ПЫЙВЛЙ УФТБОЙГЩ РБНСФЙ.
УФТПЛБ 20:
ьФП НЕУФПОБИПЦДЕОЙЕ ЖХОЛГЙЙ trap() Ч ФТБУУЙТПЧЛЕ УФЕЛБ.
УФТПЛБ 36:
рТЙОХДЙФЕМШОПЕ ЙУРПМШЪПЧБОЙЕ ОПЧПК ЗТБОЙГЩ УФЕЛБ; ФЕРЕТШ ЬФП ОЕ ОХЦОП. рТЕДРПМБЗБЕФУС, ЮФП ЗТБОЙГЩ УФЕЛБ ХЛБЪЩЧБАФ ОБ РТБЧЙМШОПЕ ТБУРПМПЦЕОЙЕ, ДБЦЕ Ч УМХЮБЕ БЧБТЙКОПЗП ПУФБОПЧБ. зМСДС ОБ УФТПЛХ ЙУИПДОПЗП ЛПДБ 403, НПЦОП УЛБЪБФШ, ЮФП ЧЕУШНБ ЧЕТПСФОП, ЮФП МЙВП ЧЙОПЧБФ ДПУФХР РП ХЛБЪБФЕМА ``tp"", МЙВП ВЩМ ЧЩИПД ЪБ ЗТБОЙГЩ НБУУЙЧБ.
УФТПЛБ 52:
рПИПЦЕ, ЮФП ЧЙОПЧБФ ХЛБЪБФЕМШ, ОП ПО СЧМСЕФУС ДПРХУФЙНЩН БДТЕУПН.
УФТПЛБ 56:
пДОБЛП, ПЮЕЧЙДОП, ЮФП ПО ХЛБЪЩЧБЕФ ОБ НХУПТ, ФБЛ ЮФП НЩ ОБЫМЙ ОБЫХ ПЫЙВЛХ! (дМС ФЕИ, ЛФП ОЕ ЪОБЛПН У ЬФПК ЮБУФША ЛПДБ: tp->t_line УМХЦЙФ ДМС ИТБОЕОЙС ТЕЦЙНБ ЛБОБМБ ЛПОУПМШОПЗП ХУФТПКУФЧБ, Й ЬФП ДПМЦОП ВЩФШ ДПУФБФПЮОП НБМЕОШЛПЕ ГЕМПЕ ЮЙУМП.)