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

398  Часть 

III   

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

Рис. 16-23.  Сообщение об ошибке при попытке открыть папку

Сопоставления программ хранятся в улье реестра HKEY_CLASSES_

ROOT, поэтому пользователь предположил, что там мог быть отсутствую-
щий или поврежденный файл. Он решил, что лучше всего будет сравнить 
результаты Procmon на компьютере, где возникла проблема, и на компьюте-
ре, где такой проблемы нет.

Procmon может захватывать большое количество данных за короткое 

время, поэтому пользователь стремился максимально сузить поле поиска. 
Он запустил Procmon с помощью параметра командной строки /noconnect, 
чтобы не начинать захват событий сразу, но и не пропустить ошибку. Затем 
он нажал  Ctrl+E, чтобы запустить захват, дважды щелкнул папку и нажал 
Ctrl+E, чтобы остановить захват сразу после появления сообщения об ошиб-
ке. После этого он перетащил значок в виде перекрестья с панели инстру-
ментов Procmon на сообщение об ошибке, чтобы отфильтровать события 
данного процесса. Поскольку Explorer.exe управляет всем рабочим столом, в 
том числе панелью задач, областью уведомлений и т.д., пользователь решил 
сократить число отображаемых объектов до потока, отображающего сооб-
щение об ошибке. Он щелкнул заголовки столбцов правой кнопкой мыши, 
добавил столбец Thread ID (TID) и поставил его рядом со столбцом PID. 
Полагая, что ему нужен поток с наибольшей активностью, он применил ин-
струмент Count Occurrences (рис. 16-24) и добавил найденный поток его в 
фильтр. После этого он сохранил отфильтрованную трассировку командой 
Save.

Рис. 16-24.  Поиск потока с наибольшей активностью

SIN_ch_16.indd   398

27.12.2011   14:52:45

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

Глава 16  399 

После этого пользователь воспроизвел все действия на другом компьютере, 

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

Пользователь открыл трассировки рядом, добавил в каждую столбец 

TID. Результаты исправной системы содержали гораздо больше событий. 
Предположив, что проблема связана с реестром, пользователь скрыл осталь-
ные классы событий с помощью кнопок панели инструментов. После этого 
он начал искать записи, совпадающие в «исправной» и «неисправной» трас-
сировке. Найдя этот поток, он отфильтровал по нему «исправную» трас-
сировку. Отыскав начало серии идентичных событий, он щелкнул правой 
кнопкой мыши первое событие серии в обеих трассировках и выбрал пара-
метр Exclude Events Before, чтобы обе трассировки начинались с одной точ-
ки (рис. 16-25).

Рис. 16-25.  Сравнение трассировок Procmon

Просматривая постранично результаты в поисках различий, он вскоре 

обнаружил операцию RegOpenKey  в HKCR\Folder\shell\open\command, 
которая привела к результату NAME NOT FOUND в «неисправной» трас-
сировке и SUCCESS в «исправной» (рис. 16-26). С помощью Regedit он экс-
портировал этот раздел c исправной машины и импортировал в реестр неис-
правной. Это несложное действие помогло решить проблему.

Рис. 16-26.  Поиск различий между трассировками Procmon

SIN_ch_16.indd   399

27.12.2011   14:52:45

400  Часть 

III   

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

Визуальное сравнение трассировок иногда требуется, если различий 

много или инструмент типа WinDiff не помогает, но в данном случае WinDiff 
мог бы ускорить процесс. Только нужно было бы исключить столбцы Time 
of Day, PID и TID, поскольку в трассировках они всегда различаются. 
Сохранив отображаемые события (исключая события профилирования) в 
CSV-файлы, эти файлы можно сравнить с WinDiff и отсутствующий раздел 
реестра сразу был бы обнаружен (рис. 16-27).

Рис. 16-27.  Сравнение трассировок Procmon с помощью WinDiff

Проблема с временными профилями реестра

История данной проблемы началась с обращения в службу поддержки 
Microsoft из-за ошибки, периодически возникающей при входе в систему и 
заставляющей Windows создавать временный профиль для пользователя.

Рис. 16-28.  Ошибка загрузки профиля пользователя при входе в систему

Профиль пользователя состоит из папки файловой системы %User-

Profile%, в которую приложения сохраняют файлы конфигураций и дан-
ных пользователей, а также файла куста реестра, хранящегося в папке 
%UserProfile%\Ntuser.dat и загружаемого процессом Winlogon при входе 
пользователя в систему. Приложения сохраняют пользовательские настрой-
ки в кусте реестра, вызывая функции реестра, обращающиеся к корневому 

SIN_ch_16.indd   400

27.12.2011   14:52:46

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

Глава 16  401 

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

Как обычно служба поддержки Microsoft начала с вопросов о конфигу-

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

Не будучи уверенными, что причиной проблемы с профилями стало об-

новление клиента ICA, сотрудники службы поддержки Microsoft пореко-
мендовали клиенту включить ведение журнала профиля (см. статью 221833 
«How to enable user environment debug logging in retail builds of Windows» 
базы знаний Microsoft Knowledge Base по адресу http://support.microsoft.
com/221833). Необходимые изменения были сделаны, но пользователю 
это не помогло. Тогда сделали копию журнала профиля из %SystemRoot%\
Debug\ UserMode\Userenv.log и отправили в службу поддержки Microsoft. 
В журнале не нашлось исчерпывающего ответа, но в нем был ключ к разгад-
ке: указание о том, что профиль пользователя не загрузился из-за ошибки 
32: ERROR_SHARING_VIOLATION (рис. 16-29).

Рис. 16-29.  Запись в Userenv.log о неудаче загрузки профиля из-за ошибки общего доступа

Когда процесс открывает файл, он указывает, какие виды общего доступа 

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

Между тем, все больше и больше клиентов по всему миру стали обра-

щаться в службы поддержки Microsoft и Citrix с той же проблемой. Все 
они установили новый клиент ICA. Служба поддержки Citrix сообщила, 
что ошибку, видимо, вызывает один из процессов клиента ICA, Ssonvr.exe. 
В ходе установки клиент ICA регистрирует DLL провайдера Pnsson.dll, кото-
рую вызывает уведомляющее приложение многосетевого доступа Windows 
(Windows Multiple Provider Notification Application) (%SystemRoot%\ 
System32\Mpnotify.exe) во время загрузки системы. Mpnotify.exe запускает-

SIN_ch_16.indd   401

27.12.2011   14:52:46

402  Часть 

III   

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

ся при входе в систему процессом Winlogon. DLL-файл уведомителя Citrix 
асинхронно запускает процесс Ssonvr.exe относительно входа пользователя в си-
стему (рис. 16-30). Единственный недостаток  данной гипотезы заключался в 
том, что, по мнению разработчиков Citrix, процесс не пытался загружать про-
филь реестра пользователя или даже читать какие-либо его разделы или пара-
метры. В итоге и Microsoft и Citrix зашли в тупик.

Winlogon.exe

Winlogon.exe

Mpnotify.exe

Pnsson.dll

Ssonsvr.exe

Загрузка куста

Время

Рис. 16-30.  Асинхронный запуск Ssonsvr.exe при входе пользователя в систему

В Microsoft подготовили версии Winlogon и ядра для сбора дополнительной 

диагностической информации, и попыталась воспроизвести проблему в тесто-
вых системах идентичной конфигурации, но не преуспели. Не удалось воспро-
извести проблему и с помощью измененных образов Windows. Скорее всего, 
хронометраж процессов в таких образах отличался так сильно, что проблема не 
возникала. Тогда инженер службы поддержки Microsoft предложил записать 
трассировку активности при входе в систему с помощью Procmon.

Существует два способа настройки Procmon для записи операций при входе. 

Первый — использование утилиты PsExec от Sysinternals для запуска Procmon 
в неинтерактивной оконной станции в сеансе 0

2

, чтобы программа продолжала 

работать и после выхода из системы, а затем вновь войти в систему. Второй —
включение журнала загрузки для регистрации активности с ранних ее эта-
пов и во время входа в систему. Инженер выбрал второй способ и посовето-
вал клиенту запустить Process Monitor в одной из систем, регулярно сталки-
вавшихся с проблемой, выбрать Enable Boot Logging в меню Options и вы-
полнить перезагрузку, повторяя все действия, пока проблема не воспроизве-
дется. Эта процедура настраивает драйвер Process Monitor для регистрации 
активности процессов с самого начала загрузки в файле %SystemRoot%\ 
Procmon.pmb. Когда клиент столкнулся с проблемой в очередной раз, ему 
пришлось перезапустить Process Monitor. В результате драйвер остановил 
ведение журнала, и программа Process Monitor предложила преобразовать 
журнал в стандартный формат журнала Process Monitor.

2

 Подробнее об оконных станциях и сеансе 0 см. в главе 2, а о запуске Procmon с помощью 

PsExec — в главе 4.

SIN_ch_16.indd   402

27.12.2011   14:52:47