Файл: Руссинович М., Маргозис А. Утилиты Sysinternals. Справочник администратора 2012.pdf

Основные понятия Windows  

Глава 2  27 

груженных модулей и диапазоны их адресов. Но компилятор, конвертируя 
исходный код разработчика в машинные коды, выбрасывает имена функ-
ций. Единственным исключением является ситуация, когда DLL включает 
таблицу экспорта со списком имен и смещений функций, доступную другим 
модулям. В таблице экспорта, однако, нет имен внутренних функций библи-
отеки, равно как и имен точек входа, определяемых во время выполнения.

 Примечание 

Исполняемые файлы, загруженные в процессы пользовательского ре-

жима, как правило, являются EXE-файлами, позволяющими запускать новые процес-
сы, либо DLL, загружаемыми в существующий процесс. Бывают исполняемые файлы 
и с другими расширениями. Так, файлы с расширениями COM или SCR фактически 
являются EXE-файлами, в то время как файлы с расширениями ACM, AX, CPL, DRV и 
OCX являются разновидностями DLL. Программы установки обычно распаковывают и 
запускают EXE-файлы с расширением TMP.

При создании исполняемых файлов компиляторы и компоновщики мо-

гут также генерировать соответствующие файлы символов (их расширение 
по умолчанию — PDB). Файлы символов содержат данные, которые не нуж-
ны при запуске исполняемого кода, но могут быть полезны при отладке. Это 
имена и смещения для точек входа функций, содержащихся в модуле. Имея 
эту информацию, отладчику легко, взяв адрес в памяти, найти соответствую-
щую функцию по ближайшему предыдущему адресу. В отсутствие символов 
отладчику приходится пользоваться экспортируемыми функциями (если 
таковые есть), которые могут и не иметь никакого отношения к коду, кото-
рый нужно исследовать. В целом, чем больше смещение адреса возврата, тем 
меньше вероятность того, что вы нашли нужное имя функции.

 Примечание 

Утилиты Sysinternals способны использовать только «родные» (неу-

правляемые) файлы символов при чтении стеков вызовов. Они не определяют имена 
функций внутри сборок .NET, созданных с помощью JIT-компилятора.

Символьный файл должен генерироваться одновременно с соответству-

ющим исполняемым файлом, иначе подсистема отладки откажется исполь-
зовать его. Прежние версии Microsoft Visual C++ создавали файлы символов 
только для отладочных сборок, пока разработчик не отключал эту функцию 
вручную. Более новые версии в настоящее время создают символьные фай-
лы и для окончательных сборок, записывая их в одну папку с исполняемыми 
файлами. Microsoft Visual Basic 6 может создавать символьные файлы, но не 
делает этого по умолчанию.

Информация в файле символов может быть в разной степени подробной. 

Полные символьные файлы (иногда называемые закрытыми файлами сим-
волов) содержат сведения, отсутствующие в открытых файлах символов, 
включая путь и номер строки файла исходного кода, в которой определен со-
ответствующий символ, имена и типы параметров функции, а также имена и 
типы переменных. Компании — производители программного обеспечения, 
публикующие файлы символов, раскрывают только открытые символьные 
файлы, оставляя полные (закрытые) символьные файлы для внутреннего 
использования.

SIN_ch_02.indd   27

27.12.2011   14:12:06

28  Часть 

I   

Приступая к работе

Средства отладки Windows позволяют загружать нужные файлы симво-

лов по требованию с веб-сервера. На сервере могут быть символьные файлы 
для множества версий данного исполняемого файла, и средства отладки за-
гружают именно символы, подходящие к отлаживаемому файлу. (При этом 
проверяется временная метка и контрольная сумма в заголовке исполняе-
мого файла и уникально его идентифицирующие.)

У Microsoft есть веб-сервер, с которого можно скачать открытые сим-

вольные файлы Windows. Установив средства отладки Windows и настроив 
утилиты Sysinternals для использования сервера символов Microsoft, вы без 
труда узнаете, какие функции Windows вызывают ваши процессы. 

Рис. 2-5.  Стек вызовов в Process Monitor с информацией из символьных файлов

На рис. 2-5 показан стек вызовов для события, захваченного утилитой 

Process Monitor. Присутствие в стеке MSVBVM60.DLL (фреймы 15 и 17-21) 
указывает на то, что это Visual Basic 6, поскольку MSVBVM60.DLL является 
библиотекой времени выполнения Visual Basic 6. Большие смещения фрей-
мов MSVBVM60 говорят о том, что для этого модуля символы не доступны, 
а отображаемые имена не являются реальными именами вызываемых функ-
ций. Фрейм 14 отражает вызов функции Forml::cmdCreate. Щелкните глав-
ный исполняемый файл (LuaBugs_VB6.exe). Этот фрейм также содержит 
путь к исходному файлу. Это говорит о том, что перед нами полные данные 
символов для данного модуля, созданного сторонним разработчиком. Затем 
эта функция вызывает CWshShelbRegWrite из Wshom.ocx (фрейм 13), зна-
чит эта программа, написанная на Visual Basic 6, использует Windows Script 
Host и ActiveX для записи в реестр. CWshShelkRegWrite вызывает вну-
треннюю функцию из того же модуля (фрейм 12), а тот — документирован-
ную API-функцию Windows RegCreateKeyExA из Kernel32.dll (фрейм 11). 

SIN_ch_02.indd   28

27.12.2011   14:12:07

Основные понятия Windows  

Глава 2  29 

Управление передается через внутренние функции Kernel32 (фреймы 8-10) 
системной API-функции ZwCreateKey из Ntdll.dll (фрейм 7). Таким образом, 
все эти функции были выполнены в пользовательском режиме, о чем свиде-
тельствует буква U в столбце фреймов, однако во фрейме 6 программа пере-
ключилась в режим ядра, о чем свидетельствует буква K. Двухбуквенные 
префиксы функций ядра (фреймы 0-6) обозначают компоненты исполняю-
щей системы, к которым они принадлежат. Например, Cm относится к дис-
петчеру конфигураций, отвечающему за реестр, а Ob — к диспетчеру объек-
тов. Трассировка стека была записана во время обработки CmpCallCallBacks 
(фрейм 0). Обратите внимание, что символы в фреймах 0-13 были взяты ис-
ключительно из открытых символов Windows, загруженных по требованию 
программой Process Monitor с сервера символов Microsoft.

Настройка символов

Утилиты Sysinternals, использующие символы, требуют два вида инфор-
мации (рис. 2-6): путь к файлу Dbghelp.dll и путь к символам. Утилиты 
Sysinternals, которые могут использовать полную символьную информацию 
для отображения исходных файлов, запрашивают также пути к исходным 
кодам.

Dbghelp.dll — это одна из библиотек механизма отладки Microsoft. Она 

обеспечивает поддержку прохода по стеку, загрузки системных файлов и 
разрешения адресов памяти в имена функций. Только версия Dbghelp.dll, по-
ставляемая со средствами отладки Windows, поддерживает загрузку файлов 
с серверов символов. Версия Dbghelp.dll, которая поставляется с Windows в 
каталоге %SystemRoot%\System32, может использовать только локальные 
символьные файлы. При первом запуске утилиты Sysinternals проверяют 
пути по умолчанию к средствам отладки и, обнаружив файл Dbghelp.dll, ис-
пользуют его, либо, в противном случае, файл из %SystemRoot%\System32.

Рис. 2-6.  Диалоговое окно настройки символов в Process Explorer

Вот URL для загрузки средств отладки (Debugging Tools) Windows: http://

www.microsoft.com/whdc/devtools/ debugging/defaultmspx. Раньше установ-
щик средств отладки был доступен для загрузки в виде отдельного файла, но 
сейчас он входит в пакет Windows SDK. Для использования средств отладки 
нужно запустить скачанный установщик и выбрать нужные средства отлад-

SIN_ch_02.indd   29

27.12.2011   14:12:07

30  Часть 

I   

Приступая к работе

ки. Пакет содержит свободно распространяемые средства (в виде отдельных 
файлов для платформ x86, x64 и IA64). Свободно распространяемые пакеты 
удобны для установки отладчика на другие компьютеры по сети, т.к. они по-
зволяют не запускать установку полного SDK на каждом компьютере.

Путь к символам указывает механизму отладки, где искать символьные 

файлы, если их нет в каталогах по умолчанию. По умолчанию механизм 
отладки ищет символьные файлы в каталоге, в котором находится испол-
няемый файл, а также в каталоге, в котором был исходно сгенерирован сим-
вольный файл (если эти каталоги указаны в исполняемом файле).

Путь к символам может включать системные папки и директивы сервера 

символов. При первом запуске утилиты Sysinternals получают путь к фай-
лам символов из переменной окружения _NT_SYMBOL_PATH. Если эта 
переменная не определена, используется путь srv*http://msdl.microsoft.com/
download/symbols, т.е. сервер открытых символов Microsoft, но загруженные 
символьные файлы при этом не сохраняются в локальном кеше.

Системные папки и директивы сервера символов могут присутствовать 

в пути одновременно, будучи разделенными точкой с запятой. Очередность 
просмотра элементов пути определяется их порядком. Так, директивы сер-
вера символов имеют следующий вид: srv*DownstreamStore*SymbolServer, 
а вот пример пути к файлам символов:

C:\MySyms;srv*C:\MSSymbols*http://msdl.microsoft.com/download/symbols

Механизм отладки сначала ищет символы в каталогах по умолчанию, за-

тем в C:\MySyms (там удобно хранить закрытые файлы символов созданных 
вами программ). Если символьный файл не найден, механизм отладки ищет 
его в C:\MSSymbols, если файла нет и там, он отправляет запрос серверу 
символов. Если нужный файл есть на сервере символов, механизм отладки 
загружает его в C:\MSSymbols.

Подробнее о путях, серверах символов, исходных путях и переменных 

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

  Совет 

Если вам нужны только открытые символы, установите такой путь:

 srv*c:\symbols*http://msdl.mi 

crosoft.com/download/symbols

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

Сеансы, оконные станции, рабочие столы 
и оконные сообщения

В описании ряда утилит Sysinternals, в том числе Process Explorer, Process 
Monitor, PsExec, Adlnsight, Desktops и LogonSessions, упоминаются сеансы 

SIN_ch_02.indd   30

27.12.2011   14:12:07

Основные понятия Windows  

Глава 2  31 

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

Для начала рассмотрим схему на рис. 2-7, а затем определимся с термина-

ми. На внешнем уровне находятся сеансы служб терминалов (TS). Каждый 
сеанс содержит одну или более оконных станций, содержащих рабочие сто-
лы. Каждый из этих защищаемых объектов располагает ресурсами, предна-
значенными для его индивидуального использования. Эти объекты связаны 
произвольными отношениями с сеансами, которые создаются LSA после 
локального входа в систему. Хотя в документации Windows не всегда прово-
дится четкое различие между сеансами LSA и сеансами служб терминалов, 
они являются совершенно разными объектами.

mswindowstation

Сеанс

0

Services-0x0-3E7$

Services-0x0-3E5$

Services-0x0-3E4$

WinSta0

Default

Default

Disconnect

Winlogon

MsrestrictedDesk

Default

Default

Default

Disconnect

Winlogon

Desktop1

Disconnect

Winlogon

Default

WinSta0

WinSta0

Сеанс

1

Сеанс

2

Рис. 2-7.  Сеансы, оконные станции и рабочие столы

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

Службы терминалов поддерживают интерактивные пользовательские сеан-
сы на одном компьютере. Впервые представленные в Windows NT 4.0 Terminal 

SIN_ch_02.indd   31

27.12.2011   14:12:07