Share via


Дело о пропавшем автозапуске

Я рассказываю об изменениях в ядре ОС Windows Vista с момента проведения конференции TechEd US летом 2006 года, и одной из функций, которой я в своем докладе уделяю внимание, является ReadyBoost. Это технология кэширования на диске со сквозной записью, которая позволяет повысить производительность системы за счет размещения кэша диска на флэш-накопителе. Принцип работы ReadyBoost достаточно подробно описан в моей статье «Внутренности ядра ОС Windows Vista, часть 2», опубликованной в журнале TechNet Magazine. Вкратце, он заключается в следующем: поскольку флэш-носители характеризуются значительно меньшей задержкой при произвольном доступе, чем жесткие диски, технология ReadyBoost перехватывает операции доступа к диску и перенаправляет операции чтения методом произвольного доступа в кэш, если, конечно затребованные данные в нем имеются. При этом операции последовательного доступа производятся на диске. В ходе презентации я подключил к компьютеру флэш-накопитель USB, ожидая увидеть диалоговое окно автозапуска с предложением организовать на накопителе кэш ReadyBoost.

clip_image001

Первая презентация прошла удачно, а вот во время двух последующих диалоговое окно автозапуска не появлялось. Готовясь к презентациям перед докладами, я уже замечал подобные случаи, но в силу нехватки времени не имел возможности провести полноценное расследование. Чтобы обойти проблему, я вручную открывал диалоговое окно свойств тома после подключения устройства. В результате страницу ReadyBoost можно было вызвать щелчком на ссылке "Speed up my system" (Ускорить работу системы) в диалоговом окне автозапуска.

Перед последним докладом, который я должен был сделать на ноябрьской конференции TechEd/ITforum в Барселоне, у меня нашлось время, чтобы разузнать, с какой, собственно, стати не работает автозапуск. В первую очередь, я проверил его настройки, которые находятся в секции AutoPlay (Автозапуск) страницы Hardware and Sound (Оборудование и звук) панели управления. Некоторым параметрам было присвоено значение Ask me every time (Спрашивать каждый раз), но, по-видимому, они игнорировались, и даже после возврата к настройкам по умолчанию автозапуск работать не возжелал.

clip_image002

Далее требовалось разобраться в том, как на подключение устройства реагируют реестр и файловая система. Решение этой задачи могло помочь найти причину, по которой проводник не обращал внимания на настройки автозапуска в панели управления. Я запустил программу Process Monitor, настроил фильтр, отбирающий операции проводника с реестром, а затем повторно подключил флэш-носитель. Остановив запись событий, я приступил к изучению собранного материала.

Для исследования 22 000 событий потребовались бы многие часы, а поскольку конкретные коды ошибок, на которые следовало бы обратить внимание, не были мне известны, пришлось искать ключевое слово, которое смогло бы придать верное направление моим поискам. Первая попытка - поиск по слову “autoplay” - не принесла никакого результата. Известно, что проводник ищет в корневом каталоге съемного носителя файл Autorun.inf, в котором содержатся указания о значке тома и исполняемом файле, который должен запускаться по двойному щелчку пользователя на томе. Поэтому для второй попытки я избрал ключевое слово "autorun". В первой найденной строке не оказалось ничего интересного - она ссылалась на идентификатор GUID точки подключения. Эти сведения ОС Windows генерирует динамически при обнаружении нового устройства.

clip_image003

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

clip_image004

Запросы по первым двум путям завершались ошибкой NAME NOT FOUND (ИМЯ НЕ НАЙДЕНО), из чего можно было сделать вывод о том, что политики не определены, а вот запрос по пути HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun оказался успешным. Программа Process Monitor показала значение, считанное проводником, в столбце Details (Сведения).

clip_image005

Поскольку я не знал, как трактовать значение 255, пришлось провести поиск в Интернете по строке "nodrivetypeautorun". В результате я нашел страницу из комплекта ресурсов для Windows 2000. В ней объяснялось, что указанное значение представляет собой маску, которая определяет, с каких типов устройств автозапуск должен быть запрещен. Как выяснилось, десятичное значение 255 (шестнадцатеричное 0xFF) отключает автозапуск со всех устройств.

clip_image006

Далее посредством функции перехода (Jump-To) программы Process Monitor я запустил редактор Regedit и перешел непосредственно к указанному значению. Открыв редактор значений, я заменил старое значение нулем, что должно было разрешить автозапуск с любых устройств. Теперь нужно было проверить, что изменилось. Я отключил, а затем вновь подключил к компьютеру флэш-накопитель. На экране появилось диалоговое окно автозапуска, что и требовалось доказать. Стоит иметь в виду, что в ОС Windows Vista автозапуск больше не работает по принципу «автоматически запустить то, что указано в файле Autorun.inf». Новый принцип - «показать возможные варианты» - не создает угроз безопасности.

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

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

clip_image007

Теперь можно было не сомневаться, что я не попаду впросак во время текущей серии докладов об изменениях в ядре ОС Windows Vista, а равно и в ходе любых докладов в будущем. Дело было раскрыто. Рассмотренный пример подчеркивает не только ценность программы Process Monitor при поиске причин неполадок, но и широкие возможности локального администратора. Локальный администратор - это полноправный хозяин компьютера. Он вправе делать с ним все, что угодно, в том числе обходить политики домена (об этом я рассказывал в одной из предыдущих записей). По этой причине, хотя и не только по ней, предприятиям стоит ограничивать своих сотрудников правами стандартных пользователей.