Symbols что это за папка windows 7
Обновление MS Windows 7 Starter 32-bit
Надо обновить MS Windows 7 Starter 32-bit до sp1.
Windows у меня стоит лицензионный, но Центр обновления Windows не показывает доступного обновления на sp1.
Я зашел на сайт Майкрософт (а) [ссылка заблокирована по решению администрации проекта]. com/downloads/ru-ru/details.aspx?FamilyID=C3202CE6-4056-4059-8A1B-3A9B77CDFDDA
скачал с сайта два файла
Windows_Win7SP1.7601.17514.101119-1850.X86CHK.Symbols.msi
Windows_Win7SP1.7601.17514.101119-1850.X86FRE.Symbols.msi
Сначала установил первый файл, надеясь, что он и обновит мне windows.
Потом этот установщик создает папку «Symbols» (причем ему не важно где она будет располагаться)
Собственно, когда заканчивается установка, появляется папка «Symbols» в которой сие файлы
И ВСЁ, больше ничего не произошло
В папке нет ни одного exe файла (я надеялся, что может эта программа просто распечатала установщик)
После перезагрузки ничего не изменилось, система как была не sp1 так и осталась
Со вторым загруженным файлом та же история
Не могу понять почему не вышло установить sp1? ведь и винда лицензионная и файл (якобы для обновления на sp1) скачан с оф. сайта?
И цент обновления не показывает, что есть обновление на sp1&
Надо было скачать этот файл
Отладочные символы
В дополнение ко всему прочему, изрядные проблемы при освоении логики продолжает создавать оптимизация кода, которую выполняют компилятор и компоновщик, окончательно запутывая и раздувая код. Единственное, что могли делать в свое время реверсивные инженеры, это создавать в дизассемблированном листинге собственные комментарии, пытаясь этот самый листинг документировать, тем самым хоть как-то «оживив» исходный код. Вероятно, на каком-то из этапов решено было упростить столь нелегкий процесс отладки программного обеспечения и некоторые вендоры операционных систем начали предоставлять специальные файлы, называемые отладочными символами, для системных файлов своих операционных систем и различных продуктов. Не стала исключением и корпорация Microsoft, поэтому данное нововведение заметно упростило процесс отладки закрытого кода Windows.
Символы абсолютно не применимы в ходе штатного выполнения программы, но крайне полезны в процессе её отладки. Люди, которые не по наслышке знакомы с программированием, могут подтвердить, что компилятор, конвертируя исходный код программы в машинный код, выбрасывает имена функций. Другими словами, в получившемся исполняемом модуле Вы не увидите никаких имен. Единственный вариант получить связь между адресами и именами, это сгенерировать файл отладочных символов. Однако отладочные символы, в большинстве случаев, по умолчанию не генерируются, а могут быть созданы лишь при указании дополнительных опций компиляции.
Если пояснить данное понятие простым языком, то отладочные символы требуются (что очевидно по названию), для удобства отладки кода, а именно с целью понять что есть что в структуре изучаемого приложения. В общем случае, в файле отладочных символов хранятся:
При наличии этой информации отладчик по адресу памяти легко находит соответствующую функцию по ближайшему предыдущему адресу. Да и исследователю эта информация позволяет видеть «символические» данные об исследуемом двоичном файле, что в свою очередь в значительной мере упрощает исследование алгоритма приложения в процессе статического дизассемблирования либо интерактивной отладки. Исследователю кода гораздо удобнее просматривать значения переменных, а не безликих ячеек памяти. Отладочные символы часто используются в процессе поиска ошибок в исходном коде, отладке программы и разного рода отказах. По методу размещения отладочная информация может:
Это имеет под собой достаточно простую подоплеку, ведь отладочные символы жестко привязаны к конкретному исходному коду, и если в исходном коде что-либо меняется (строка, процедура, переменная), то старое соответствие перестает быть актуальным и требуется сгенерировать новый файл символов, который в точности соответствует уже новому, измененному исходному коду. С точки зрения разработчика стоит учесть и тот факт, что потенциально любое изменение проекта вызывает полную несовместимость между файлов символов и компонентом, поэтому файлы символов и бинарные файлы нужно строить одновременно. С точки зрения исследователя необходимо помнить, что файлы отладочных символов меняются при каждой новой сборке (build), поэтому процесс обновления системы требует также и обновления файлов отладочных символов, относящихся к системным модулям. Вот почему достаточно удобно использовать автоматизированный процесс запроса символов, дабы не отвлекаться на ручную синхронизацию.
Нужны ли символы
Отладчик WinDbg корпорации Microsoft можно сконфигурировать на автоматический запрос отладочной информации, если в ней есть необходимость. Вот как раз основной вопрос, на который я хотел сам себе ответить, нужны ли эти самые отладочные символы или нет? Я провел простейший эксперимент, который состоял в том, что я нашел завалявшийся у меня на тестовой станции дамп падения в синий экран (BSOD) и подключил его сначала в WinDbg с доступными символами, а затем в том же WinDbg без символов, и вот результат:
Честно говоря, результат меня удивил. На момент ошибки мы имеем довольно скудную информацию о сбое, такую как адрес возникновения ошибки и стек вызовов момента падения. Отладчик пытается выполнить автоматический разбор стека, и что же получается, мало того, что отладчик при отсутствии отладочных символов не может сопоставить имена и параметры функций, так он еще и не может правильно выполнить трассировку стека вызовов момента падения. Выходит, что без символов становится практически невозможно (в некоторых случаях) проследить последовательность вызовов функций, и в дополнение осложняется понимание того, какой именно модуль вызвал ошибку. Именно так! Всё только что сказанное актуально для ситуации с 32-битным кодом, поскольку:
Я думаю, тут можно особо ничего не комментировать, поскольку практически все могли заметить, что листинг справа намного более «читабелен», без дополнительных проверок кода можно визуально без труда определить, какие именно функции используются в том или ином месте исходного кода. В итоге, становится очевидным, что:
Распространение
Понятное дело, что если возникло желание символы официально предоставлять, то их необходимо каким-то образом распространять, для того, что бы конечные потребители программного продукта имели возможность (при остром на то желании конечно же) этот самый продукт отлаживать, то есть в случае возникновения ошибок иметь возможность быстро находить вероятную причину возникновения. Каким же образом отладочные символы предоставляют своей целевой аудитории? До некоторых пор разработчики, перед которыми стояла задача предоставления отладочных символов своим клиентам, передавали подобную информацию для своих продуктов на оптических носителях, дисках CD/DVD. Исключением не стала и операционная система Windows, которая может поставляться с отладочными символами, традиционно размещаемыми на дополнительном диске дистрибутива, либо в составе Driver Development Kit ( DDK ). Однако, с определенного времени популярным стал метод распространения символов через сеть Интернет. В сети для этой цели Microsoft размещает собственные сервера символов, которые и предоставляют отладочные символы, однако, чтобы работать с сервером символов, необходимо использовать специализированный протокол обмена.
Публичные и приватные (частные) символы
Публичные символы, так же, не включают информацию для помощи по отображению параметров большинства функций, информацию по локальным переменным, типам локальных переменных. Тем не менее, они содержат достаточно информации для ключевых отладочных сценариев, что зачастую является достаточным. Таким образом, можно сделать утешительный вывод:
Символьные файлы, распространяемые корпорацией Microsoft (посредством серверов символов), включают в себя исключительно публичные функции, глобальные переменные и их типы данных, то есть являются публичными. В противоположность этому, некоторые разработчики программного обеспечения (Mozilla) распространяют полную отладочную информацию (публичные символы и приватные символы). Приватные (полные, закрытые) символы (private symbols) содержат значительно больше информации, включающей в себя путь и номера строк исходного кода, имена и типы параметров функций и переменных, и если сравнивать приватные и публичные символы с точки зрения процесса отладки, то последние делают его слегка сложнее, тем не менее достаточны для большинства сценариев отладки.
Сервер символов Microsoft
Многие компоненты, разрабатываемые корпорацией Microsoft, такие как файлы, входящие в состав операционных систем, офисных приложений и прочих продуктов, компилируются вместе с символами, которые затем распространяются через сервер символов Microsoft (Microsoft Symbol Server). Сервер символов представляет собой онлайновый репозиторий публичных символов для продуктов Microsoft, который доступен для запроса посредством протокола HTTP по визуально-неотображаемому пути (URL):
Формат PDB
Со времени того, как отладочные символы стали массово востребованы сообществом специалистов, многие разработчики программного обеспечения озаботились созданием разнообразных методов хранения информации об исходных файлах в модулях символов. В связи с чем, в природе появились всевозможные форматы записи символов. Нас же, в контексте данной статьи, интересуют форматы хранения символов для продуктов Microsoft.
В общем случае, символы могут быть предоставлены в следующих форматах:
Однако мы будем рассматривать в данной статье лишь формат PDB, который является самым современным, соответственно и предпочтительным форматом для различных средств разработки от Microsoft.
Все данные, которые PDB файл может содержать:
PDB файл служит для:
Выводы
Знакомство с WinDBG – Часть 1
WinDBG – прекрасный отладчик. Возможно, у него не очень дружественный интерфейс и нет по умолчанию черного фона, но это один из самых мощных и стабильных отладчиков в ОС Windows в настоящее время. В этой статье я познакомлю вас с основами WinDBG, чтобы вы могли начать с ним работу.
Автор: Брэд Антониевич (Brad Antoniewicz)
WinDBG – прекрасный отладчик. Возможно, у него не очень дружественный интерфейс и нет по умолчанию черного фона, но это один из самых мощных и стабильных отладчиков в ОС Windows в настоящее время. В этой статье я познакомлю вас с основами WinDBG, чтобы вы могли начать с ним работу.
Эта первая статья из цикла, посвященного WinDBG. Перечень всех статей, входящих в этот цикл:
По сравнению с Windows 7 процесс установки WinDBG в Windows 8 претерпел небольшие изменения. В этом разделе мы рассмотрим установку отладчика для обеих операционных систем.
Установка WinDBG в Windows 8
В Windows 8 WinDBG включается в пакет Windows Driver Kit (WDK). Вы можете установить Visual Studio и WDK или установить отдельно пакет «Debugging Tools for Windows 8.1», который включает WinDBG.
Программа установки спросит, хотите ли вы установить WinDBG локально или загрузить весь пакет разработчика для другого компьютера. Последнее, по сути, является эквивалентом автономного установщика, что очень удобно, если в будущем вы захотите установить пакет в других системах.
Рисунок 1: Выбор типа установки
В следующем окне вам необходимо снять флажки со всех пунктов кроме «Debugging Tools for Windows» и нажать на кнопку «Download».
Как только установщик закончит свою работу, зайдите в директорию, куда загрузился пакет (по умолчанию это c:\Users\Username\Downloads\Windows Kits\8.1\StandaloneSDK) и пройдите процедуру установки.
Установка WinDBG в Windows 7 и более ранних версиях
Во время установки я выбираю опцию «Debugging Tools» в разделе «Redistributable Packages», чтобы создать автономный инсталлятор для облегчения последующих установок.
Рисунок 2: Выбор опций установки для создания автономного инсталлятора
По завершению установки, у вас должны появиться инсталляторы WinDBG для различных платформ (в директории c:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\ ).
Рисунок 3: Папка с инсталляторами WinDBG для различных платформ
Далее процесс установки довольно прост. Вам нужно лишь скопировать соответствующий файл на ту машину, где вы собираетесь проводить отладку, и пройти процедуру установки.
Рисунок 4: Внешний вид WinDBG
Как только вы впервые увидите внешний вид WinDGB, то поймете, что отладчик пугающе прост. Большинство функций WinDBG узнаются во время отладки процесса. Вместо того чтобы тратить время на описание интерфейса, в последующих разделах мы рассмотрим только самые важные моменты.
Рисунок 5: Командное окно WinDBG
Чтобы настроить WinDBG на использование Microsoft Symbol Server зайдите в раздел File:Symbol File Path и установите путь SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols. Конечно, немного странно, что звездочки используются в качестве разделителя. После того, как вы настроите Microsoft Symbol Server, символы загрузятся в папку C:\Symbols.
Рисунок 6: Настройка Microsoft Symbol Server
WinDBG автоматически загрузит символы для бинарных файлов, когда это будет необходимо. Вы также можете добавить свою собственную папку с символами, например, так:
Добавление символов во время отладки
Будет не лишним выполнить перезагрузку символов после добавления или изменения путей:
Проверка загруженных символов
Чтобы увидеть, для каких модулей загружены символы, вы можете воспользоваться командой x*!. Хотя WinDBG загружает символы только по мере надобности, команда x*! покажет символы, которые могут быть загружены. Можно принудительно загрузить символы при помощи команды ld * (на это может уйти некоторое время, и вы можете остановить этот процесс, зайдя в Debug:Break).
Рисунок 7: Принудительная загрузка символов
Теперь мы можем увидеть символы для каждого модуля.
Рисунок 8: Перечень символов
Отладка локального процесса
При отладке локального процесса у вас есть два пути:
У каждого способа есть свои преимущества и недостатки. Если, допустим, вы запустили программу через WinDBG, то вам доступны некоторые специальные отладочные опции (например, отладка кучи), которые могут привести к краху приложения. С другой стороны, существуют также и программы, которые аварийно заканчиваются свою работу, когда вы цепляете к ним отладчик. Некоторые приложения (в особенности, вредоносы) во время запуска проверяют присутствие отладчика в системе и, соответственно, в этом случае имеет смысл цепляться к уже запущенному процессу. Иногда происходит отладка службы под управлением ОС Windows, которая устанавливает некоторые параметры во время запуска, так что для упрощения процесса отладки, также лучше подцепляться к запущенному процессу, а не запускать службу через отладчик. Некоторые люди утверждают, что запуск процесса через отладчик серьезно сказывается на производительности. Короче говоря, попробуйте и то и другое и выберите то, что подходит вам лучше всего. Если вы по каким-то причинам предпочитаете какой-то конкретный способ, поделитесь своими соображениями в комментариях!
Если вы отлаживаете отдельное приложение, которое запущено локально и не работает с сетью, возможно, вы захотите запустить его через WinDBG. Однако это не означает, что вы не можете подцепиться к уже запущенному процессу. Выбирайте наиболее удобный для вас способ.
Запустить процесс не составляет труда. Зайдите в «File:Open Executable» и выберите тот исполняемый файл, который хотите отладить. Вы также можете указать аргументы или установить стартовую директорию:
Рисунок 9: Выбор исполняемого файла для отладки
Подключение к процессу
Подключение к уже запущенному процессу также не составляет особого труда. Однако следует обратить внимание на то, что в некоторых случаях может потребоваться время для того, чтобы найти именно тот процесс, который вы хотите отладить. К примеру, некоторые браузеры создают один родительский процесс, а затем еще несколько процессов для каждой вкладки. Таким образом, в зависимости от крэш-дампа, который вы отлаживаете, возможно, вы захотите подцепиться не к родительскому процессу, а к процессу, связанному с вкладкой.
Чтобы подцепиться к уже запущенному процессу зайдите в «File:Attach to a Process», а затем выберите PID или имя процесса. Помните о том, что вам необходимо иметь соответствующие права, чтобы подцепиться к процессу.
Рисунок 10: Выбор процесса, к которому нужно подцепиться
Если после подключения, приложения приостановило свою работу, вы можете использовать режим «Noninvaise», поставив соответствующий флажок.
Отладка удаленного процесса
Возможно, иногда вам будет требоваться отладка процесса на удаленной системе. Было бы намного более удобно решать эту задачу при помощи локального отладчика, вместо использования виртуальной машины или RDP. Или, быть может, вы отлаживаете процесс LoginUI.exe, который доступен только в случае, когда система заблокирована. В подобных ситуациях вы можете использовать локальную версию WinDBG и удаленно подключаться к процессам. Для решения этих задач существует два наиболее распространенных способа.
Существующие отладочные сессии
После запуска вышеупомянутой команды вы можете увидеть такое предупреждение:
Рисунок 11: Сообщение с предупреждением, которое может возникнуть после запуска команды по создания «слушателя»
Затем WinDBG сообщит, что сервер запущен:
Теперь вы может подключиться с удаленного хоста к уже существующей отладочной сессии, зайдя в «File:Connect to a Remote Session» и введя в текстовое поле примерно следующее: tcp:Port=5005,Server=192.168.127.138
Рисунок 12: Удаленное подключение к отладочной сессии
После подключения вы получите подтверждение на удаленном клиенте:
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
и сообщение в локальной версии отладчика:
MACHINENAME\User (tcp 192.168.127.138:13334) connected at Mon Dec 16 09:03:03 2013
Создание удаленного сервера
Вы также можете создать отдельный сервер с WinDBG, удаленно подключаться к нему и выбирать процесс для отладки. Это можно сделать, используя файл dbgsrv.exe там, где вы планируете отлаживать процессы. Для запуска подобного сервера запустите следующую команду:
Рисунок 13: Запуск удаленного сервера
И опять же вы можете получить предупреждение о безопасности, которое вам следует принять:
Рисунок 14: Сообщение безопасности, которое может возникнуть во время запуска отладочного сервера
К серверу отладки вы можете подключиться, если зайдете в файл «File: Connect to Remote Stub» и введете в текстовое поле следующую строку: tcp:Port=5005,Server=192.168.127.138
Рисунок 15: Подключение к отладочному серверу
После подключения вы не получите каких-то сигналов о том, что вы подключились, однако если вы зайдете в «File:Attach to a Process», то увидите перечень процессов отладочного сервера (там, где запущен dbgsrv.exe). Теперь вы можете подцепляться к процессу, как если бы делали это локально.
Или просто зайдите в раздел «Help:Contents».
Во время работы программы импортируются различные модули, обеспечивающие функциональность приложения. Следовательно, если вы будете знать, какие модули импортированы приложением, то сможете лучше понять алгоритм его работы. Во многих случаях, вы будете отлаживать конкретный модуль, загруженный программой, а не сам исполняемый файл.
После подключения к процессу WinDBG автоматически отобразит загруженные модули. К примеру, ниже показаны модули, после того, как я подключился к calc.exe:
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00a70000 00b30000 C:\Windows\system32\calc.exe
ModLoad: 77630000 7776c000 C:\Windows\SYSTEM32\ntdll.dll
ModLoad: 77550000 77624000 C:\Windows\system32\kernel32.dll
ModLoad: 75920000 7596a000 C:\Windows\system32\KERNELBASE.dll
ModLoad: 76410000 77059000 C:\Windows\system32\SHELL32.dll
ModLoad: 77240000 772ec000 C:\Windows\system32\msvcrt.dll
ModLoad: 76300000 76357000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 75cd0000 75d1e000 C:\Windows\system32\GDI32.dll
ModLoad: 75fa0000 76069000 C:\Windows\system32\USER32.dll
ModLoad: 777b0000 777ba000 C:\Windows\system32\LPK.dll
ModLoad: 774b0000 7754d000 C:\Windows\system32\USP10.dll
ModLoad: 73110000 732a0000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_
6595b64144ccf1df_1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
ModLoad: 75a80000 75bdc000 C:\Windows\system32\ole32.dll
ModLoad: 76360000 76401000 C:\Windows\system32\RPCRT4.dll
ModLoad: 777c0000 77860000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 75be0000 75bf9000 C:\Windows\SYSTEM32\sechost.dll
ModLoad: 76270000 762ff000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 74590000 745d0000 C:\Windows\system32\UxTheme.dll
ModLoad: 74710000 748ae000 C:\Windows\WinSxS\x86_microsoft.windows.common-
controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.dll
ModLoad: 703d0000 70402000 C:\Windows\system32\WINMM.dll
ModLoad: 74c80000 74c89000 C:\Windows\system32\VERSION.dll
ModLoad: 77770000 7778f000 C:\Windows\system32\IMM32.DLL
ModLoad: 75c00000 75ccc000 C:\Windows\system32\MSCTF.dll
ModLoad: 74130000 7422b000 C:\Windows\system32\WindowsCodecs.dll
ModLoad: 74260000 74273000 C:\Windows\system32\dwmapi.dll
ModLoad: 756d0000 756dc000 C:\Windows\system32\CRYPTBASE.dll
ModLoad: 75e60000 75ee3000 C:\Windows\system32\CLBCatQ.DLL
ModLoad: 6ef10000 6ef4c000 C:\Windows\system32\oleacc.dll
Позже в процессе отладки вы можете вновь вывести этот список при помощи команды lmf:
0:005> lmf
start end module name
00a70000 00b30000 calc C:\Windows\system32\calc.exe
6ef10000 6ef4c000 oleacc C:\Windows\system32\oleacc.dll
703d0000 70402000 WINMM C:\Windows\system32\WINMM.dll
73110000 732a0000 gdiplus C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_
1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
74130000 7422b000 WindowsCodecs C:\Windows\system32\WindowsCodecs.dll
74260000 74273000 dwmapi C:\Windows\system32\dwmapi.dll
74590000 745d0000 UxTheme C:\Windows\system32\UxTheme.dll
74710000 748ae000 COMCTL32 C:\Windows\WinSxS\x86_microsoft.windows.common-
controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.dll
74c80000 74c89000 VERSION C:\Windows\system32\VERSION.dll
756d0000 756dc000 CRYPTBASE C:\Windows\system32\CRYPTBASE.dll
75920000 7596a000 KERNELBASE C:\Windows\system32\KERNELBASE.dll
75a80000 75bdc000 ole32 C:\Windows\system32\ole32.dll
75be0000 75bf9000 sechost C:\Windows\SYSTEM32\sechost.dll
75c00000 75ccc000 MSCTF C:\Windows\system32\MSCTF.dll
75cd0000 75d1e000 GDI32 C:\Windows\system32\GDI32.dll
75e60000 75ee3000 CLBCatQ C:\Windows\system32\CLBCatQ.DLL
75fa0000 76069000 USER32 C:\Windows\system32\USER32.dll
76270000 762ff000 OLEAUT32 C:\Windows\system32\OLEAUT32.dll
76300000 76357000 SHLWAPI C:\Windows\system32\SHLWAPI.dll
76360000 76401000 RPCRT4 C:\Windows\system32\RPCRT4.dll
76410000 77059000 SHELL32 C:\Windows\system32\SHELL32.dll
77240000 772ec000 msvcrt C:\Windows\system32\msvcrt.dll
774b0000 7754d000 USP10 C:\Windows\system32\USP10.dll
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll
77630000 7776c000 ntdll C:\Windows\SYSTEM32\ntdll.dll
77770000 7778f000 IMM32 C:\Windows\system32\IMM32.DLL
777b0000 777ba000 LPK C:\Windows\system32\LPK.dll
777c0000 77860000 ADVAPI32 C:\Windows\system32\ADVAPI32.dll
Также вы можете узнать адрес загрузки для конкретного модуля при помощи команды «lmf m»:
0:005> lmf m kernel32
start end module name
77550000 77624000 kernel32 C:\Windows\system32\kernel32.dll
File Type: DLL
FILE HEADER VALUES
14C machine (i386)
4 number of sections
4A5BDAAD time date stamp Mon Jul 13 21:09:01 2009
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL
SECTION HEADER #1
.text name
C44C1 virtual size
1000 virtual address
C4600 size of raw data
800 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60000020 flags
Code
(no align specified)
Execute Read
Debug Directories(2)
Type Size Address Pointer
cv 25 c549c c4c9c Format: RSDS, guid, 2, kernel32.pdb
( 10) 4 c5498 c4c98
SECTION HEADER #2
.data name
FEC virtual size
C6000 virtual address
E00 size of raw data
C4E00 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0000040 flags
Initialized Data
(no align specified)
Read Write
SECTION HEADER #3
.rsrc name
520 virtual size
C7000 virtual address
600 size of raw data
C5C00 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40000040 flags
Initialized Data
(no align specified)
Read Only
SECTION HEADER #4
.reloc name
B098 virtual size
C8000 virtual address
B200 size of raw data
C6200 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42000040 flags
Initialized Data
Discardable
(no align specified)
Read Only
Сообщения и исключения
После подключения к процессу вначале отображается список модулей, а затем могут появиться другие сообщения. Например, когда мы цепляемся к calc.exe, WinDBG автоматически устанавливает точку останова (которая является просто маркером, используемым для остановки приложения). Информация о точке останова выводится на экран:
Конкретно это сообщение является исключением, а именно first-chance исключением. По сути, исключение – это особое состояние, возникающее во время выполнения программы. First-chance исключение означает, что программа остановилась сразу же после появления исключения. Second-chance исключение означает, что после возникновения исключения будут выполнены некоторые операции, а потом программа остановит свою работу.
После отображения сообщений и исключений отладчик выводит состояние регистров процессора. Регистры – это специальные переменные внутри процессора, которые хранят небольшие куски информации или следят за состоянием чего-либо в памяти. Процессор может обрабатывать информацию в этих регистрах очень быстро. Это намного быстрее, чем каждый раз получать информацию по шине из RAM.
После подключения к calc.exe WinDBG автоматически отображает информацию о следующих регистрах:
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
Позже можно продублировать эту информацию еще раз при помощи команды r:
0:005> r
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77663540 cc int 3
Если мы хотим получить значение конкретного регистра, то можем выполнить такую команду:
0:005> r eax
eax=7ffd9000
Информацию одновременно из нескольких регистров можно получить так:
0:005> r eax,ebp
eax=7ffd9000 ebp=02affdc8
Указатель на инструкцию
Последняя команда посвящена запускаемым инструкциям. Здесь информация также выводится на экран, как и в случае с командой r, того, что содержит регистр EIP. EIP – это регистр, содержащий местонахождение следующей инструкции, которую должен выполнить процессор. То, что отображает WinDBG, – эквивалент команды u eip L1, после выполнения которой WinDBG идет по адресу, указанному в регистре EIP, преобразует этот участок в ассемблерный код и отображает его на экране.
ntdll!DbgBreakPoint:
77663540 cc int 3
Оставайтесь на связи
В следующих статьях мы рассмотрим, как использовать WinDBG в боевых условиях: точки останова, пошаговую отладку и просмотр памяти. Не переключайтесь! J.