Опрос
Вы участвуете в программе Windows Insider?
Популярные новости
Обсуждаемые новости

01.10.2007 10:04 | deeper2k

Предлагаем вашему вниманию прошлогоднюю статью Марка Руссиновича, которая, к сожалению, раньше осталась незамеченной. В данной статье Руссинович говорит о причине задержки открытия диалога Open в Windows Explorer и иных приложениях, поэтому она может оказаться поистине полезной.

Несколько недель назад я был на конференции TechEd/ITForum в Барселоне, где выступал с несколькими докладами. Конференция прошла очень хорошо и Windows Vista, которую я решил испробовать впервые, работала отлично. Однако, когда я просматривал демо перед одной из своих лекций, я заметил, что диалог открытия файлов, который является общим для всех Windows-приложений, появляется с интервалом 5-15 секунд после нажатия.

У меня не было времени разобраться с причиной до доклада, поэтому подобные задержки во время моего доклада "Изменения в ядре Windows Vista" (Windows Vista Kernel Changes) застали меня врасплох. Такое поведение ОС оставляло такое же странное впечатление, как и в том случае, который я описал в заметке "Причина задержки автоматически загружаемых процессов" (The Case of the Process Startup Delays). В том случае Windows Defender Remote Procedure Call (RPC) пытался соединиться с контроллером домена, что приводило к зависаниям, в случае если компьютер к домену не подключён. Я бормотал извинения от имени Windows Vista и пытался отвлечь аудиторию, переходя к следующим демонстрациям.

До тех пор, пока я не прилетел домой, у меня не было возможности взглянуть на эту проблему еще раз. Я совершил шаги, похожие на те, которые я делал, когда исследовал зависания Windows Defender. Я запустил инструмент Windbg из Debugging Tools for Windows, а из него блокнот, нажал Ctrl+O для открытия диалога открытия файлов и, когда система начала тормозить, я посмотрел в стек основного потока в блокноте.



Если вы раньше не видели стек – то это список всех последних команд, вызванных потоком. Вы читаете их снизу вверх, и таким образом, можете прочитать, что блокнот загрузил Browseui.Dll, и вызвал её функцию CAddressBand::SetNavigationState. Эта функция вызвала CBreadcrumbBar::SetNavigationState, которая, в свою очередь, вызвала CBreadcrumbBar::SetIDList, и так далее.

Взгляд на названия функций в стеке сразу мне сказал, что же произошло: когда вы первый раз в приложении запускаете диалог открытия файлов, то он открывает вашу папку документов. В Windows Vista моя папка с документами это C:\Users\Markruss\Documents, но оболочка хочет сделать путь в новой панели "хлебных крошек" (от англ. "bread crumb") красивым, отображая его как "Mark Russinovich\Documents", и поэтому, вызывает http://msdn2.microsoft.com/en-gb/library/ms724435.aspx">функцию GetUserNameEx, чтобы посмотреть, как отображается имя моей учётной записи в объекте Пользователь в Active Directory. Я подтвердил свою теорию, проверив, что первый параметр SHGetUserDisplayName передает параметры команде GetUserNameEx, которая интерпретируется как перечень EXTENDED_NAME_FORMAT, и есть 3: NameDisplay.

Я установил контрольную точку на возвращении вызова и обратился к ней, когда зависание закончилось. Команда GetUserNameEx вернула код ошибки ERROR_NO_SUCH_DOMAIN, и прошла через SHGetUserDisplayName, показав, что это она снижает скорость передачи данных к команде GetUserName. Вместо того, чтобы искать отображаемое имя пользователя, эта функция просто получает идентификатор безопасности (SID) пользователя от маркера процесса (структура данных ядра, которая определяет владельца процесса), и вызывает LookupAccountName, чтобы перевести SID в имя учётной записи, которое, в моём случае, просто markruss. Таким образом, появившийся диалог выглядел таким образом.



В противоположность вот, что появилось, когда я пришёл на работу, и подключился к корпоративной сети.



Я разобрался с проблемой, но мне стало интересно, где именно происходила задержка, и поэтому я продолжил исследование того, что же именно происходило по ту сторону вызова Secure32!CallSPM, который находится в начале листинга стека. Я знал, что процесс Local Security Authority (LSASS) ответственен за аутентификацию, включая взаимодействие с контроллерами домена и трансляторами имени учётной записи, так что, я прикрепил Windbg к процессу Lsass.exe (убедитесь, что вы открепили дебаггер от LSASS, иначе при его выключении с помощью команды qd отключится и процесс LSASS, и система перезагрузится через 30 секунд). Я определил, что Secur32.Dll связывается и с клиентом и с сервером, и подтвердил, что она загружается в процесс LSASS, но мне необходимо было определить определённую серверную функцию, которая отвечает за Secur32!SecpGetUserName. Я её определил брут-форсом (то есть перебором): я выгружал функции, осуществляемые Secur32.Dll, и искал какую-либо со словом "name" в ней.



Я установил контрольные точки на некоторых из них и, когда я заново вызвал подвисание, я запустил одну на SecpGetUserName, и переступил через неё, чтобы добраться до этого стека.



Функция DsGetDcName документирована как возвращающая имя контроллера домена в определённом домене. Очевидно, функции SecpTranslateName необходимо найти контроллер домена, которому она пошлёт запрос на отображаемое имя пользователя. Я проследовал далее и обнаружил, что LSASS кэширует результат поиска на 45 секунд, что объясняет, почему у меня не было задержки, если я запускал другое приложение и диалог открытия файла в нём сразу после этого зависания. После этого я попал в тупик, когда Netapi32!DsrGetDcNameEx2 выполняла RPC запрос.

Узнав, что Netapi32 работает и с клиентом и с сервером, я убрал её символы и установил контрольные точки на командах, содержащих "dc". Я позволил LSASS запускать процессы и к своему удивлению наткнулся на ту же самую функцию Netapi32!DsrGetDcNameEx2. Я проследил за запросом всё глубже и глубже, пока поток меня, наконец, не привёл в ядро (Ntdll!KiFastSystemCallRet).



Я был близок к окончанию своего расследования. Последний вопрос, который у меня был – что это за драйвер устройства Netlogon, делающий вызов на посылание дейтаграммы браузера? Я ответил на этот вопрос, посмотрев на первый параметр, который он передал NlBrowserDeviceIoControl, который, как я предположил, был обработчиком объекта файла. Потом я открыл Windbg в режиме Local Kernel Debugging (заметьте, что в Windows Vista вы должны загрузиться в режиме отладки, чтобы сделать это, что позволит вам посмотреть на живую структуру данных ядра) и убрал информацию обработчика. Это показало мне объект устройства, который подсказал мне, что драйвер Bowser.sys - это NT драйвер-получатель дейтаграммы менеджера локальных подключений (NT Lan Manager Datagram Receiver Driver).



Я думал, что моё исследование подошло к концу, но когда позже я пытался вызвать снова подвисание, у меня ничего не вышло. Я повторил свои шаги и узнал, что LsapGetUserNameForLogonSession кэширует отображаемое имя на 30 минут. Далее отображаемое имя кэшируется с кэшируемыми мандатами, так что вы не будете сталкиваться с задержками в течение 30 минут после подключения или отключения от корпоративной сети. Я подтвердил свои предположения, подождав 30 минут и вызвав зависание.

Итак, диалог открытия файлов пытается отобразить имя пользователя для панели "хлебных крошек" при отображении папки документов и в процессе пытается определить местоположение контроллера домена, отсылая дейтаграмму менеджера локальных подключений через драйвер устройства Bowser.sys. Я также узнал, что нет способов решения проблемы задержек, и что любой, у кого компьютер подключён к домену, но в данный момент отключённый от него, тоже будет сталкиваться с такими задержками, по крайней мере, до выхода Vista SP1.

Нет ли изменений после установки недавно выпущенного Vista SP1?


Источник: http://blogs.technet.com/markrussinovich
Перевод: Zloy Kak Pё$

Комментарии

Не в сети

короче, мешанина полная. Скоро придется новую ось им на рынок выводить, так как эта разваливается под собственной тяжестью.

01.10.07 10:11
0
Не в сети

поистине полезной задержка может оказаться?

01.10.07 10:12
0
Не в сети

В данной статье

поэтому она может оказаться поистине полезной


codemaster, ты вроде бы никогда не отличался плохим зрением

01.10.07 10:38
0
Не в сети

не дают людям нормально файл открыть... win98 руллит

01.10.07 12:20
0
Raiker +16
Не в сети

Нет, ну у яственно в мире начинает царить параноя. Сначала IE7 с задержкой открывает сайты набранные без "http", теперь вот Explorer с задержкой открывает диалоговое окно открытия. Знаете, я вот свое такое тупое мнение выскажу: а у меня все нормально и быстро открывается, ничего не тормозит, и все отображается, и это на компьютере трехлетней давности, и людям, которым после второй бутылки начинает глючить, я посоветую побольше отсыпаться и не переносить свои глюки на юди.

01.10.07 14:46
0
Не в сети

Эти проблемы на NT-платформе были всегда - если рабочая станция включена в домен, но контроллер домена не доступен или когда становится недоступен DNS-сервер, то очень многие действия приводят к серьёзным задержкам, пока операция, завязанная на контроллере или name-сервере не отвалятся по таймауту.
Кстати, эти ситуации не имеют однозначного решения - МС только пытается выбрать золотую середину в велечине таймаута. И не надо кричать, что у МС руки кривые - это не её проблема. Это вообще свойство любой сетевой инфраструктуры.

01.10.07 15:24
0
Не в сети

to codemaster
А вы что тут делаете любитель НЕ решений MS?!
Комментируете только незначительные недочеты с утверждениями, что именно они есть один из самых страшных багов ОСи и она исчезнет.

p.s.
вы дурак?!

01.10.07 18:24
0
Не в сети

взял секундомер и замерил сколько открывает: около 0,5 секунды. Это задержка???

01.10.07 18:49
0
Не в сети

Задержка возникает, если ваш компьютер был включён в домен и контроллер домена не доступен по той или иной причине.
Большинство пользователей на этом сайте об NTшном домене только слышали и их это не касается.

01.10.07 21:33
0
Не в сети

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

01.10.07 21:53
0
Не в сети

Обалдеть!

02.10.07 00:08
0
kfv 0
Не в сети

Рожденный ползать летать не сможет

02.10.07 04:19
0
Не в сети

Итить его, тормозит в ней все! ХР тоже тормозила по сравнению с 2000, сам видел и юзал.
И что? MacOS X тоже офигенно тормозила первое время, пока интерфейс не пропатчили. Игры новые тормозят...

Все новые продукты имеют свойство тормозить.

И решение всегда было одно - улучшать аппаратную часть своего компа и/или оптимизировать красивости и функции под себя.

02.10.07 11:25
0
kfv 0
Не в сети

Блин. На топовом оборудовании игры (в плане производительности) из под висты чуть лучше чем из под вайна в линуксе. Одно дело когда тормозит на старом оборудовании, совсем другое, когда на ультрановом не дотягивает (в плане производительности) до своей предыдущей версии (xp если кто то не догадался).

Выводы делал после тестирования такой игрушки как сталкер на машине dell xps m1710.

03.10.07 23:36
0
Для возможности комментировать войдите в 1 клик через

По теме

Акции MSFT
420.55 0.00
Акции торгуются с 17:30 до 00:00 по Москве
Все права принадлежат © ms insider @thevista.ru, 2022
Сайт является источником уникальной информации о семействе операционных систем Windows и других продуктах Microsoft. Перепечатка материалов возможна только с разрешения редакции.
Работает на WMS 2.34 (Страница создана за 0.029 секунд (Общее время SQL: 0.014 секунд - SQL запросов: 81 - Среднее время SQL: 0.00017 секунд))
Top.Mail.Ru