Групповая политика может добавить это значение реестра. gpresult Инструмент может дать вам представление о настройках, применяемых через групповую политику.

Это может делать любая программа, запущенная от имени пользователя, потому что пользователи имеют право изменять эту часть реестра по умолчанию. Поскольку он меняется "Каждые несколько дней", я подозреваю, что это не групповая политика, которая делает это (поскольку обновление политики происходит чаще, чем это).

Я хотел бы рассмотреть возможность проведения аудита на HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings реестра и просмотра журнала событий безопасности, чтобы поймать модификацию. (Я не спешу ссылаться на блоги, однако процедура в этой записи хороша, потому что она не предполагает внесения изменений в политику аудита с помощью групповой политики, как это делают большинство официальных примеров Microsoft.)

Возможно, вы также захотите включить аудит отслеживания процессов, чтобы получить четкое представление о том, какие процессы участвуют в модификации.

Хотя ответ Олешри достаточно полный, я хочу добавить некоторые дополнительные детали.

В своих наблюдениях я не вижу MpOAv влияющих или связанных с этой проблемой. Удаление ключа проверки расширения также не меняет поведения, которое я испытываю - остальная часть поста заставила меня копать дальше...

При использовании Internet Explorer 11 и посещении многих веб-страниц Google (например, Google Images) в Javascript генерируется ошибка:

{var c=function(a){try{return new window.ActiveXObject(a),!0}catch(c){return!1}}

только после попытки возврата нового window.ActiveXObject(a) сегмент.

Это заставляет IE сделать \Ext\Settings\{CA8A9780-280D-11CF-A24D-444553540000} изменения в реестре и отключение Adobe PDF Reader Add-On. Это наблюдается с помощью инструмента Sysinternals Procmon и фильтрации пути к нашему реестру.

Начиная с IE 11, свойство window.ActiveXObject скрыто от DOM. https://msdn.microsoft.com/library/dn423948(v=vs.85).aspx

Плохой / устаревший код от Google? Конечно, это не значит, что Microsoft не может лучше справиться с этим исключением.

Объяснения Олешри очень точны.

Одно из объяснений службы поддержки MS было несколько дней назад:

"После внутреннего анализа и работы с партнерами мы считаем, что мы определили основную причину как проблему с тем, как Adobe использует наш раздел реестра в IE, в результате чего Adobe ведет себя так, как будто она заблокирована или не установлена, даже если она есть. проблема была обнаружена и должна быть устранена в следующем ежеквартальном обновлении продукта Adobe PDF SCEP раскрывает проблему, активируя функцию сканирования подключаемого модуля IE, но не вызывает проблему. Это также объясняет, почему мы не видим подобных проблем с другими подключаемыми модулями IE."

Там нет никакого решения, которое является полностью адекватным. Краткосрочные решения включают в себя выполнение предпочтений на стороне клиента групповой политики для удаления ключа Adobe CLSID время от времени, если он найден, или изменение ярлыка IE для удаления CLSID перед запуском. Отключение сканирования вредоносных программ в IE11 для каждого клиента или параметра групповой политики с помощью параметров зоны безопасности Интернета "Запуск программного обеспечения для защиты от вредоносных программ на элементах управления ActiveX" - далеко не мудрый выбор, и я думаю, что большинство с этим согласится.

Совершенно не рекомендуется

Расположение GP для настройки: "Административные шаблоны \ Компоненты Windows\Internet Explorer\ Панель управления Интернетом \ Страница безопасности \ Интернет-зона \" Не запускайте программы защиты от вредоносных программ против элементов управления ActiveX "

Adobe решена проблема

К счастью, 12 января 2016 года Adobe выпустила версию 11.0.14, в которой устранена эта проблема. Кроме того, Adobe Reader DC того же выпуска не имеет этой проблемы.

http://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotes/11/11.0.14.html

Вот небольшой VB-скрипт, из которого вы можете сделать ярлык и развернуть его. Это удалит Adobe Reader CSLID, затем запустите IE и перейдите в Google.

Set WshShell = WScript.CreateObject("WScript.Shell")
On Error Resume Next
Key = "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{CA8A9780-280D-11CF-A24D-444553540000}"
WshShell.RegDelete Key & "\" 


CreateObject("WScript.Shell").Run "https://www.google.com"

Wscript.quit

С уважением

Спасибо и Олешри, и Джейру за информацию; это было чрезвычайно полезно.

Я хотел бы добавить, что эта проблема касается только тех пользователей, у которых отключен контроль учетных записей. Если вы будете смотреть Procmon, когда вынуждаете эту проблему возникать (перейдя в Google images...), вы заметите, что IE ищет указанный ниже ключ и терпит неудачу с результатом "NAME NOT FOUND":

HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{CA8A9780-280D-11CF-A24D-444553540000}

Если UAC пользователя включен, это все, что происходит. Procmon показывает, что IE ищет ключ еще несколько раз, а потом ничего. Однако, если UAC выключен, вы должны увидеть операции "RegCreateKey" из IE (как объяснил Олешри в своем посте). Похоже, что IE не находит нужные ключи, поэтому создает их. Я думаю, что UAC мешает IE создавать ключи, поэтому только мои пользователи, у которых он отключен, испытывают проблему.

Я нашел эту опцию в зонах безопасности Интернета, чтобы отключить "проверку расширений". Не запускайте программы защиты от вредоносных программ против элементов управления ActiveX

установите этот параметр, чтобы "отключить" на данный момент, надеюсь, MS en Adobe сделают это вместе:)