Дело о задержке появления диалога открытия файла
Предлагаем вашему вниманию прошлогоднюю статью Марка Руссиновича, которая, к сожалению, раньше осталась незамеченной. В данной статье Руссинович говорит о причине задержки открытия диалога Open в Windows Explorer и иных приложениях, поэтому она может оказаться поистине полезной.
Несколько недель назад я был на конференции TechEd/ITForum в Барселоне, где выступал с несколькими докладами. Конференция прошла очень хорошо и Windows Vista, которую я решил испробовать впервые, работала отлично. Однако, когда я просматривал демо перед одной из своих лекций, я заметил, что диалог открытия файлов, который является общим для всех Windows-приложений, появляется с интервалом 5-15 секунд после нажатия.
У меня не было времени разобраться с причиной до доклада, поэтому подобные задержки во время моего доклада "Изменения в ядре Windows Vista" (Windows Vista Kernel Changes) застали меня врасплох. Такое поведение ОС оставляло такое же странное впечатление, как и в том случае, который я описал в заметке "
До тех пор, пока я не прилетел домой, у меня не было возможности взглянуть на эту проблему еще раз. Я совершил шаги, похожие на те, которые я делал, когда исследовал зависания Windows Defender. Я запустил инструмент Windbg из
Если вы раньше не видели стек – то это список всех последних команд, вызванных потоком. Вы читаете их снизу вверх, и таким образом, можете прочитать, что блокнот загрузил Browseui.Dll, и вызвал её функцию CAddressBand::SetNavigationState. Эта функция вызвала CBreadcrumbBar::SetNavigationState, которая, в свою очередь, вызвала CBreadcrumbBar::SetIDList, и так далее.
Взгляд на названия функций в стеке сразу мне сказал, что же произошло: когда вы первый раз в приложении запускаете диалог открытия файлов, то он открывает вашу папку документов. В Windows Vista моя папка с документами это C:\Users\Markruss\Documents, но оболочка хочет сделать путь в новой панели "хлебных крошек" (от англ. "bread crumb") красивым, отображая его как "Mark Russinovich\Documents", и поэтому, вызывает
Я установил контрольную точку на возвращении вызова и обратился к ней, когда зависание закончилось. Команда GetUserNameEx вернула код ошибки ERROR_NO_SUCH_DOMAIN, и прошла через SHGetUserDisplayName, показав, что это она снижает скорость передачи данных к команде
В противоположность вот, что появилось, когда я пришёл на работу, и подключился к корпоративной сети.
Я разобрался с проблемой, но мне стало интересно, где именно происходила задержка, и поэтому я продолжил исследование того, что же именно происходило по ту сторону вызова Secure32!CallSPM, который находится в начале листинга стека. Я знал, что процесс Local Security Authority (LSASS) ответственен за аутентификацию, включая взаимодействие с контроллерами домена и трансляторами имени учётной записи, так что, я прикрепил Windbg к процессу Lsass.exe (убедитесь, что вы открепили дебаггер от LSASS, иначе при его выключении с помощью команды qd отключится и процесс LSASS, и система перезагрузится через 30 секунд). Я определил, что Secur32.Dll связывается и с клиентом и с сервером, и подтвердил, что она загружается в процесс LSASS, но мне необходимо было определить определённую серверную функцию, которая отвечает за Secur32!SecpGetUserName. Я её определил брут-форсом (то есть перебором): я выгружал функции, осуществляемые Secur32.Dll, и искал какую-либо со словом "name" в ней.
Я установил контрольные точки на некоторых из них и, когда я заново вызвал подвисание, я запустил одну на SecpGetUserName, и переступил через неё, чтобы добраться до этого стека.
Функция
Узнав, что 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?
Источник:
Перевод: Zloy Kak Pё$
Комментарии
короче, мешанина полная. Скоро придется новую ось им на рынок выводить, так как эта разваливается под собственной тяжестью.
В данной статье
поэтому она может оказаться поистине полезной
codemaster, ты вроде бы никогда не отличался плохим зрением
Нет, ну у яственно в мире начинает царить параноя. Сначала IE7 с задержкой открывает сайты набранные без "http", теперь вот Explorer с задержкой открывает диалоговое окно открытия. Знаете, я вот свое такое тупое мнение выскажу: а у меня все нормально и быстро открывается, ничего не тормозит, и все отображается, и это на компьютере трехлетней давности, и людям, которым после второй бутылки начинает глючить, я посоветую побольше отсыпаться и не переносить свои глюки на юди.
Эти проблемы на NT-платформе были всегда - если рабочая станция включена в домен, но контроллер домена не доступен или когда становится недоступен DNS-сервер, то очень многие действия приводят к серьёзным задержкам, пока операция, завязанная на контроллере или name-сервере не отвалятся по таймауту.
Кстати, эти ситуации не имеют однозначного решения - МС только пытается выбрать золотую середину в велечине таймаута. И не надо кричать, что у МС руки кривые - это не её проблема. Это вообще свойство любой сетевой инфраструктуры.
to codemaster
А вы что тут делаете любитель НЕ решений MS?!
Комментируете только незначительные недочеты с утверждениями, что именно они есть один из самых страшных багов ОСи и она исчезнет.
p.s.
вы дурак?!
взял секундомер и замерил сколько открывает: около 0,5 секунды. Это задержка???
Задержка возникает, если ваш компьютер был включён в домен и контроллер домена не доступен по той или иной причине.
Большинство пользователей на этом сайте об NTшном домене только слышали и их это не касается.
на работе домен. когда с контроллером или с сеткой что-то происходит, то 2003 винда дуплит на каждом шагу. эти задержки - общая болезнь всех виндов, которые поддерживают домен
Итить его, тормозит в ней все! ХР тоже тормозила по сравнению с 2000, сам видел и юзал.
И что? MacOS X тоже офигенно тормозила первое время, пока интерфейс не пропатчили. Игры новые тормозят...
Все новые продукты имеют свойство тормозить.
И решение всегда было одно - улучшать аппаратную часть своего компа и/или оптимизировать красивости и функции под себя.
Блин. На топовом оборудовании игры (в плане производительности) из под висты чуть лучше чем из под вайна в линуксе. Одно дело когда тормозит на старом оборудовании, совсем другое, когда на ультрановом не дотягивает (в плане производительности) до своей предыдущей версии (xp если кто то не догадался).
Выводы делал после тестирования такой игрушки как сталкер на машине dell xps m1710.
По теме
- Устраняем конфликт подписей дисков
- Дело о загадочных звуках
- Дело об ооооочень долгом входе в систему
- Дело об ошибке службы установки
- Дело о загадочных перезагрузках
- Дело о зависшей программе запуска игры
- Анализируем вирус Stuxnet с помощью инструментов Sysinternals (ч.3)
- Анализируем вирус Stuxnet с помощью инструментов Sysinternals (ч.2)
- Анализируем вирус Stuxnet с помощью инструментов Sysinternals (ч.1)
- Дело о нерабочей системе