Саныч
Опытный участник
- Сообщения
- 734
- Реакции
- 742
Я рассказываю об изменениях в ядре 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, подразумевая, что политики не определены, а вот обращение к HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun было успешным. 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 в деле отыскания корня проблем, данный пример призван проиллюстрировать мощь локальных администраторских прав. Локальный администратор является полноправным хозяином компьютера и способен делать все, что вздумывается, включая управление политиками домена. Дело закрыто.
источник
Принцип работы 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, подразумевая, что политики не определены, а вот обращение к HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoDriveTypeAutoRun было успешным. 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 в деле отыскания корня проблем, данный пример призван проиллюстрировать мощь локальных администраторских прав. Локальный администратор является полноправным хозяином компьютера и способен делать все, что вздумывается, включая управление политиками домена. Дело закрыто.
источник