Я запускаю чистую установку (всего несколько дней назад) Windows 10 Home 64 bit и сталкиваюсь с проблемами доступа к определенному разделу реестра. Когда редактор Office VBA (32-разрядный процесс под моей собственной ограниченной учетной записью пользователя) сканирует реестр на наличие доступных элементов управления, он попадает в {0002DF01-0000-0000-C000-000000000046}CLSID в ветке HKCR\CLSIDs и получает сообщение об отказе в доступе при открытии раздела в режиме чтения, что не позволяет ему продолжить работу. Этот раздел присутствует только в ветке HKLM, а не в ветке HKCU. Судя по его значению по умолчанию, это «Internet Explorer(Ver 1.0)». Для него есть две копии: одна непосредственно в пути Classes\CLSID, другая в пути Classes\WOW6432Node\CLSID для 32-разрядных процессов. Поскольку это Office 32 bit, я сначала сосредоточился на версии WOW6432Node.
Мои тесты на данный момент:
- У этого ключа уже было разрешение на чтение для моей учетной записи пользователя... что происходит?
- Владельцем был TrustedInstaller (почему именно он?), а разрешения для этого ключа были явно переопределены (т.е. не унаследованы, как я подозревал — почему?)
- Я изменил владельца на Администраторов и добавил свою конкретную учетную запись пользователя с полным разрешением. Вкладка "эффективный доступ" RegEdit подтверждает, что этот пользователь имеет полное разрешение на него, но доступ запрещен все еще срабатывает, когда VBA IDE (работающая под этой же учетной записью пользователя) пытается прочитать его?
- Я временно переименовал ключ (например, заменив первый "0" на "1"). Согласно Process Monitor, VBA IDE теперь может нормально прочитать переименованный ключ - больше нет отказа в доступе!? Переименование обратно возвращает старое поведение...
- Думая, что это может быть конфликтом между 32- и 64-битной «версией» одного и того же ключа, я попытался сделать то же самое с 64-битной версией этого ключа. Результат: разрешения по умолчанию уже были достаточно хороши, настройка владельца на Администраторов работает, предоставление Администраторам полного доступа также работает, но тогда переименование ключа в RegEdit от имени администратора не разрешено? RegEdit выдает «Ошибка переименования ключа - Редактор реестра не может переименовать {0002DF01-0000-0000-C000-0000000000046}. Ошибка при переименовании ключа». (Ух ты, какая полезная информация!) Использование Process Monitor показывает, что операция RegEdit RegRenameKey также приводит к отказу в доступе здесь.
- Запустив RegEdit с использованием учетной записи System
PsExec -s -i regedit.exe(учетная запись подтверждена через диспетчер задач), переименовать ключ все равно не удается.
Похоже, что это не проблема с разрешениями как таковая; похоже, что какой-то другой процесс активно отслеживает доступ к этому ключу по имени и запрещает его? Независимо от правильности установленных разрешений, администраторы не могут переименовать 64-битную версию ключа, а 32-битные процессы, пытающиеся прочитать 32-битную версию ключа, также получают «отказано в доступе». Я предполагаю, что поскольку 32-битные процессы запрашивают общий путь Classes\CLSID... (т. е. не с явно указанным в нем путем WOW6432Node, как мои переименования в RegEdit), это вызывает тот же захват здесь.
Для полноты картины: честно говоря, я не помню, когда это началось; впервые я заметил это несколько недель назад, когда мне снова понадобилась эта функциональность VBA IDE. У меня установлен Sandboxie v5.18 вместе с Windows Defender по умолчанию. Все программное обеспечение исправлено и обновлено. Кроме этого, не установлено никакого другого агрессивного программного обеспечения безопасности. Отключение службы Sandboxie и Windows Defender также не помогло, как и запуск Windows в безопасном режиме.
Есть ли у кого-нибудь идеи, что происходит?
Контекст для тех, кому интересно и/или нужна помощь в исправлении этого: я использую Office 2010 professional 32 bit, и я столкнулся с ошибкой VBA IDE, из-за которой невозможно добавить дополнительные элементы управления на панель инструментов при разработке форм в IDE. Я могу выбирать «Дополнительные элементы управления» целый день (из меню, а также из всплывающего контекстного меню на самой панели инструментов), но, кроме короткого мигания формы изменения курсора, ничего не происходит — диалоговое окно «Дополнительные элементы управления» вообще не открывается, никаких ошибок не отображается, ничего. Причина этого в том, что при итерации по реестру в поисках CLSID типа «элемент управления» VBA IDE просто прекращает свою работу, когда сталкивается с ошибкой «отказано в доступе» при чтении раздела реестра. С помощью Process Monitor вы можете узнать, какой раздел вызвал ошибку разрешения, а исправление установленных разрешений снова делает VBA счастливым. К сожалению, ошибка существует уже давно, и хотя она встречается не так уж часто, на мой взгляд, это все еще плохой дизайн, который не был исправлен.