Обсуждение завершено Дело о пропавшем автозапуске

Саныч

Ветеран
Сообщения
860
Симпатии
1,096
Баллы
553
#1
Я рассказываю об изменениях в ядре Windows Vista вот уже полтора года с момента проведения TechEd 2006 в США и одной из функций, которым я уделяю особое внимание, является ReadyBoost, технология кэширования, которая позволяет увеличить производительность дисковой системы ОС за счет использования флэш-памяти в качестве дискового кэша.

Принцип работы ReadyBoost достаточно подробно объяснен в статье "В ядре Windows Vista: часть вторая", вышедшей в рамках TechNet Magazine. В ходе моей презентации я подключил к моему компьютеру USB-драйв, после чего Windows Vista инициализировала диалог AutoPlay/Автозапуск, в котором присутствует опция для включения ReadyBoost-кэширования для конкретного устройства:


proxy.php?image=http%3A%2F%2Fimg208.imageshack.us%2Fimg208%2F5281%2Fautoplay.jpg&hash=2c22e585d2084cc0d1e5ad888865ccec



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

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

proxy.php?image=http%3A%2F%2Fimg208.imageshack.us%2Fimg208%2F4997%2Fautoplay2.jpg&hash=bd89f1803b795eed9d3e821fd01539f7



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

Просмотр 22000 событий требует не одного часа, поэтому пришлось подумать и выбрать ключевое слово, которое сумело бы облегчить поиск необходимой информации. Перво-наперво мне пришло в голову "autoplay", но результата не дало. Я знал, что Explorer ищет файл с именем Autorun.inf в корневой папке устройства, в котором содержатся указатели на ярлык устройства и исполняемый файл, который запускается по двойному щелчку. Поэтому второй попыткой стало ключевое слово "autorun". Первый из результатов не показал ничего интересного, поскольку ссылался на mount-point GUID, информаци, которую Windows генерирует динамически при обнаружении нового устройства:

proxy.php?image=http%3A%2F%2Fimg208.imageshack.us%2Fimg208%2F7853%2Fautoplay3.jpg&hash=3739eab1f399d1b91174bd091cd554ce


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

proxy.php?image=http%3A%2F%2Fimg208.imageshack.us%2Fimg208%2F5536%2Fautoplay4.jpg&hash=5633a23a63a46e82294c47a1a0ee93c5



Обращение по первым двум адресам выдало ошибку NAME NOT FOUND, подразумевая, что политики не определены, а вот обращение к HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun было успешным. Process Monitor показал значение, которое читал Explorer, в столбце Details:

proxy.php?image=http%3A%2F%2Fimg208.imageshack.us%2Fimg208%2F7875%2Fautoplay5.jpg&hash=3522219cd55caa3005e04eb4d19ff52f


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

proxy.php?image=http%3A%2F%2Fimg208.imageshack.us%2Fimg208%2F671%2Fautoplay6.jpg&hash=443634f8c32dd719a3902f5e89bff634


Далее я воспользовался функцией Jump-To, которая позволила запустить редактор реестра и перейти к найденному значению, после чего я изменил значение на 0, тем самым разрешив автозапуск всех устройств. Теперь нужно было проверить, что изменилось. Я извлек флэш-драйв и снова подключил. К моему удовольствию, диалог AutoPlay появился. Обратите внимание, что в Windows Vista функция AutoPlay более не означает "автоматический запуск содержимого файла Autorun.inf", а, скорее, отображает возможные опции, поэтому риска безопасности в автозапуске более нет.

Дело было почти завершены, но была одна деталь, которую следовало прояснить. Функция автозапуска была заблокирована в моей системе конфигурацией групповых политик домена Microsoft, к которому подключен мой компьютер. Это объясняет, почему моя демонстрация поначалу работала: первое мое выступление произошло до того, как я подключился к домену Microsoft. Это также означало, что значение снова вернется в свое изначальное положение, как только я подключусь к домену. Если это произойдет до начала моей сессии, то моя презентация снова не сработает.

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

proxy.php?image=http%3A%2F%2Fimg208.imageshack.us%2Fimg208%2F4821%2Fautoplay7.jpg&hash=ae2e7a02808029671fa62a17f33ab057


Теперь я был уверен, что моя презентация на сессии "Изменения в ядре Vista" и последующих будет успешной. Кроме подчеркивания незаменимости Process Monitor в деле отыскания корня проблем, данный пример призван проиллюстрировать мощь локальных администраторских прав. Локальный администратор является полноправным хозяином компьютера и способен делать все, что вздумывается, включая управление политиками домена. Дело закрыто.





источник
 
Сверху Снизу