Дело о пропавшем автозапуске - Компьютерная документация по Windows. Оптимизация Windows.
 Компьютерная документация по Windows. Оптимизация Windows.  Компьютерная документация по Windows. Оптимизация Windows. Поиск
  Здравствуйте  [ Новый пользователь ] Домой  .  Статьи по темам  .  Компьютерная документация  .  Личный кабинет  .  Toп 10  .  Карта сайта  

  Навигация

 Главная   Главная
 Главная   Магазин софта
 Темы новостей   Темы новостей
 Топ 10   Топ 10
 Архив новостей   Архив новостей
 Карта сайта   Карта сайта
 Конструктор   Конструктор
 Обзоры   Обзоры
 Интересное   Интересное
 Рассылка новостей   Рассылка новостей
    Полезные ресурсы
 Пользователи   Пользователи
 Поиск   Поиск
 Написать нам   Написать нам
 Тест скорости   Тест скорости


  Наши темы
Windows 8
Windows 7
Windows Vista
Windows XP
Настройка Windows
Реестр Windows
Восстановление системы
MS-DOS
BIOS
Интернет
Microsoft Office
Сетевые настройки
Обработка видео
Вебмастеру
Оптимизация Windows
Обзор софта
Технологии, обзоры
Обзоры компьютеров и комплектующих
Рецензии
Полезные советы
Продвижение сайтов

Новые обзоры

Как заработать на ремонте компьютеров

Переработка отходов электроники

Типовые неисправности I:Phone, Pad, Pod и Macbook

Место для вашей электронной души

Ремонт компьютеров в Москве


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

Размещено 18/01/2008

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

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

 


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

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

 


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

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

 


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

 


Обращение по первым двум адресам выдало ошибку NAME NOT FOUND, подразумевая, что политики не определены, а вот обращение к HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerNoDriveTypeAutoRun было успешным. Process Monitor показал значение, которое читал Explorer, в столбце Details:

 


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

 


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

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

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

 


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


Источник: http://blogs.technet.com/markrussinovich
Перевод: deeper2k

 



Компьютерная документация по Windows Copyright © 2008-2019