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

ВУЗ: Не указан

Категория: Книга

Дисциплина: Операционные системы

Добавлен: 29.10.2018

Просмотров: 32981

Скачиваний: 742

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

Сообщения об ошибках  

Глава 16  403 

После нескольких попыток пользователь скопировал журнал загрузки и 

отправил его службе поддержки Microsoft. Проверив журнал, инженеры об-
наружили, что нарушение общего доступа возникает при попытке Winlogon 
загрузить пользовательский куст реестра  (рис. 16-31). После просмотра опе-
раций, предшествовавших ошибке, стало ясно, что именно Ssonsvr.exe был 
процессом, открывавшим куст реестра. Оставался вопрос: почему Ssonsvr.
exe делал это?

Рис. 16-31.  Ssonsvr.exe открывает ntuser.dat, что вызывает нарушение общего доступа 
при открытии куста процессом Winlogon.exe

Для ответа на этот вопрос инженеры воспользовались трассировкой стека 

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

Просмотр стека для операции открытия файла Ntuser.dat процессом 

Ssonsvr.exe (рис. 16-32) показал, что в действительность операцию иниции-
ровал не Ssonsvr.exe, а Windows Logical Prefetcher.

Рис. 16-32.  Код Prefetcher, вызывающий loCreateFile для загрузки Ntuser.dat

Logical Prefetcher, появившийся в Windows XP, представляет собой ком-

понент ядра, который отслеживает процесс в течение первых 10 секунд после 
запуска и регистрирует каталоги и порции файлов, к которым процесс об-
ращается, в файле %SystemRoot%\Prefetch. Чтобы различать исполняемые 
файлы с одинаковыми именами, но расположенные в разных папках, Logical 
Prefetcher дает им имена, составленные из имени файла и хеш-строки пути 
к нему, например, NOTEPAD.EXE-D8414F97.pf. Для просмотра файлов и 
папок, помеченных Logical Prefetcher для упреждающего чтения в ходе по-
следнего запуска приложения удобна утилита Strings от Sysinternals:

SIN_ch_16.indd   403

27.12.2011   14:52:47


background image

404  Часть 

III   

Поиск и устранение сбоев: загадочные случаи

strings prefetch-file

При следующем запуске приложения Logical Prefetcher, исполняемый в 

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

Тем не менее, причастность Logical Prefetcher к проблеме с профилями 

вызвала новые вопросы. Почему программа решила заранее прочесть файл 
куста пользователя в контексте Ssonsvr.exe, когда сам Ssonsvr.exe не об-
ращается к профилям в реестре? Работники службы поддержки Microsoft 
обратились за ответом к разработчикам Logical Prefetcher. Те прежде всего 
отметили, что реестр загружается в память Windows XP с использованием 
операций кешируемого ввода-вывода. Это означает, что поток упреждаю-
щего чтения заранее читает части кустов. Поскольку этот поток работает в 
процессе System, а Logical Prefetcher связывает активность процесса System 
с процессом, работающим в данный момент, определенная последователь-
ность запуска и действия процессов во время загрузки и входа в систему 
могут привести к тому, что Logical Prefetcher припишет обращение к кусту 
реестра процессу Ssonsvr.exe. Если во время следующей загрузки и входа 
в систему порядок событий будет иным, Winlogon будет конфликтовать с 
Logical Prefetcher, что и видно в журнале загрузки.

Оказывается, вопреки его предназначению, операции Logical Prefetcher 

могут приводить к нарушениям совместного доступа, как в данном случае 
с Windows XP (в серверных ОС Logical Prefetcher проводит упреждающее 
чтение только для операций во время загрузки, и делает это синхронно, до 
начала загрузки). По этой причине в системах под управлением Windows 
Vista и Windows 7 Logical Prefetcher использует мини-драйвер фильтра файло-
вой системы Fileinfo (%SystemRoot%\System32\Drivers\Fileinfo.sys). Этот 
драйвер отслеживает возможные нарушения совместного доступа и устра-
няет риск неудачи последующих операций с файлом, прочитанным Logical 
Prefetcher, пока последний не закроет этот файл.

Когда ситуация прояснилась, Microsoft и Citrix принялись усиленно 

искать временные решения для клиентов. Одним из вариантов стало от-
ключение Prefetcher, а другим — написание сценария выхода, удаляюще-
го файлы Prefetcher для Ssonsvr.exe. Компания Citrix опубликовала эти 
решения в статье Citrix Knowledge Base

3

, а компания Microsoft — в статье 

№ 969100 Microsoft Knowledge Base (http://support.microsoft.com/kb/969100). 

3

 http://support.citrix.com/artide/CTX118226

SIN_ch_16.indd   404

27.12.2011   14:52:47


background image

Сообщения об ошибках  

Глава 16  405 

Обновление клиента ICA, появившееся несколько дней спустя, откладывало 
загрузку DLL провайдера на 10 секунд после запуска Ssonsvr.exe, т.е. делало 
это до возврата управления Mpnotify.exe. Поскольку Winlogon ожидает за-
вершения Mpnotify перед входом пользователя в систему, Logical Prefetcher 
не связывает обращение Winlogon к кусту реестра пользователя с загрузкой  
Ssonsvr.exe.

Как сказано выше, этот случай показался мне особенно интересным, по-

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

!

SIN_ch_16.indd   405

27.12.2011   14:52:47


background image

Глава 17

Зависание и плохая производительность

В этой главе описаны случаи зависания приложений и низкой производи-
тельностью системы. Для решения проблем в этих случаях использовались, 
в основном, средства анализа стека вызовов, предоставляемые Procexp, 
Procmon и ProcDump.
•  Случай с IExplore, перегружавшем процессор, демонстрирует исполь-

зование стеков потоков в Procexp для выявления причины проблемы.

•  Случай со сбоем в ReadyBoost описывает использование Procexp для 

выдвижения гипотезы о причинах проблемы и Procmon для ее подтверж-
дения.

•  Случай с медленной демонстрацией — еще одно подтверждение извест-

ного правила: если что-то может пойти не так, оно непременно пойдет не 
так, а вероятность неудачи при демонстрации пропорциональна числен-
ности аудитории. Трассировка Procmon позволила найти причину этой 
проблемы.

•  Случай медленного открытия файлов Project демонстрирует исполь-

зование окна Procmon File Summary (Сводка по файлам), которое по-
могает быстро найти файлы с наибольшим числом обращений и файлы, 
обращение к которым занимает больше всего времени. Дальнейший ана-
лиз стеков вызовов позволяет выявить модуль, вызывающий проблемы с 
производительностью.

•  Сложный случай с зависанием Outlook — пара связанных между со-

бой проблем, описанных службой поддержки Microsoft и разрешенных 
с помощью утилиты ProcDump, которую я написал специально для этой 
службы.

Случай с IExplore, перегружавшим процессор

Однажды, установив Adobe Reader и закрыв Internet Explorer, я заметил, что 
значок Procexp в области уведомлений («трее») показывает аномально вы-
сокое использование ЦП. Я навел указатель мыши на этот значок и увидел во 
всплывающей подсказке, что процесс Iexplore.exe потребляет 50% ресурсов 

SIN_ch_17.indd   406

27.12.2011   14:41:22


background image

Зависание и плохая производительность  

Глава 17  407 

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

Рис. 17-1.  Значок Procexp в области уведомлений и сообщение о высокой загруженности 
ЦП процессом Iexplore.exe

Я открыл Procexp, нашел процесс Iexplore.exe, открыл окно его свойств 

и перешел на вкладку Threads (Потоки). Как я и ожидал, один поток был 
привязан к процессору (рис. 17-2). Это демонстрирует одно из преимуществ 
многопроцессорных систем: максимум ресурсов, потребляемых вышедшим 
из-под контроля потоком, не может превышать времени одного процессора 
(т.е. 50% общих ресурсов двухпроцессорной системы), что оставляет доста-
точно ресурсов ЦП для других задач, включая решение возникшей пробле-
мы. На однопроцессорной системе вышедший из-под контроля поток бло-
кирует всю систему.

Рис. 17-2.  Вышедший из-под контроля поток перегрузил один из процессоров 
в двуядерной системе

Стартовый адрес потока, вышедшего из-под контроля, не дал никаких 

намеков, это был просто стандартная точка входа потока в DLL исполняю-
щей среды Windows C. Чтобы понять, какой код он запускал, я выбрал его 
в списке потоков и щелкнул на кнопке Stack (Стек). В стеке вызовов был 
показан код, полученный из gp.ocx (строки 21-25 на рис. 17-3).

Я никогда не слышал о gp.ocx, поэтому я открыл представление DLL 

и начал искать его в процессе Iexplore.exe. Этот файл представился как 
«getPlus(R) ActiveX Control» компании NOS Microsystems Ltd (рис. 17-4).

SIN_ch_17.indd   407

27.12.2011   14:41:23