Я тестировал откат к точке восстановления в Windows 10 20H1 Release Preview и внезапно напоролся на вынесенную в заголовок проблему. Сегодня я расскажу о ее диагностике и покажу решение.

Занятно, что неделей ранее мы ковыряли такую же ситуацию в чате инсайдеров, но к решению не пришли. Видимо, когда сам сталкиваешься с проблемой, какие-то косвенные признаки помогают или просто приходят в голову другие идеи :)

👉 Описанное в статье решение применимо к специфической ситуации и может не помочь в вашем случае, даже если все симптомы совпадают. При таком раскладе просто переустановите ОС поверх с сохранением настроек и программ.

[+] Сегодня в программе

Описание проблемы

Контроль учетных записей блокирует запуск оснасток MMC (диспетчер устройств, журнал событий, службы и т.д.) сообщением:

Это приложение заблокировано в целях защиты. Администратор заблокировал выполнение этого приложения. За дополнительными сведениями обратитесь к администратору.

This app has been blocked for your protection. An administrator has blocked you from running this app. For more information, contact the administrator.

Проблема наблюдается только при запуске оснасток из оболочки Windows — меню Пуск, ярлыков, Win + R. Из командной строки от имени администратора все работает, в чем и заключается обходной путь, например: mmc devmgmt.msc.

Эта ошибка не связана с заблокированными файлами!

Аналогичное сообщение может появляться при запуске исполняемых файлов, загруженных из интернета. В этом случае проблема решается легко – надо разблокировать файл в его свойствах или из PowerShell. Об этом я рассказывал в рамках статьи об альтернативных потоках данных NTFS.

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

Диагностика

Обратите внимание на строку Издатель: Нет данных в диалоге UAC. Система по какой-то причине не может проверить издателя приложения и блокирует запуск.

Отсутствие издателя

На самом деле в диалоге UAC это наблюдается не только у mmc.exe, но и у множества исполняемых файлов Windows. В этом можно убедиться, например, запустив командную строку от имени администратора. А можно в Process Explorer добавить столбец Verified Signer и увидеть страшную картину.

UAC блокирует почему-то только оснастки MMC. Впрочем, иначе было бы еще хуже ;)

Служба криптографии

За проверку издателя отвечает служба криптографии. В чате мы безуспешно тыкали вокруг нее пальцем в небо, а в своей ОС я обратил внимание, что служба грузит ЦП на 15-20%.

Монитор ресурсов показал постоянную запись 80-90кб/сек в $LogFile, но причины такого поведения оставались неясными.

Это навело меня на мысль сделать проверку диска, и она даже что-то исправила, но не насущную проблему. Для очистки совести я прогнал DISM и SFC, а также удалил последнее обновление, но эти способы ожидаемо не помогли.

Журнал событий

Вообще, с этого можно было начинать, но иногда я забываю даже про такие основы диагностики, как безопасный режим :)

В журнале приложений обнаружились тысячи свежих ошибок CAPI2 и десятки тысяч предупреждений ESENT! Модуль КриптоПРО тоже отметился в качестве пострадавшего.

В частности, регистрировались приведенные ниже ошибки.

Event 256 — CAPI2

Службе шифрования не удалось инициализировать базу данных каталога. Ошибка: -2147418113 (0x8000ffff) : Разрушительный сбой

The Cryptographic Services service failed to initialize the Catalog Database. The error was: -2147418113 (0 x8000 ffff) : Catastrophic failure

Event 642 — ESENT

Catalog Database (16656, D,50) Catalog Database: Не удается использовать версию функции формата базы данных 9180 (0 x23 dc), так как в качестве текущего используется формат базы данных 1568.20.0, и он определяется параметром 0 x410022 D8 (8920 | JET_ efvAllowHigherPersistedFormat).

Catalog Database (16656,D,50) Catalog Database: The database format feature version 9180 (0x23dc) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).

Catalog Database

Стало намного теплее! Catalog Database – это файл базы данных криптографических хэшей. В папке System32 есть две подпапки – catroot и catroot2. В первой данные о пакетах драйверов, а во второй – о системных файлах.

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

esentutl /p %windir%\system32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\catdb

Это не помогло, но оставалось еще кардинальное средство.

Решение

Решение заключается в пересоздании системной базы данных каталогов. В PowerShell от имени администратора:

Stop-Service cryptsvc
Rename-Item -Path "C:\Windows\System32\catroot2" -NewName catroot2.old
Restart-Computer -Force

Первая команда останавливает службу криптографии, вторая переименовывает папку catroot2, а третья перезагружает систему (в моем случае перезапуска службы оказалось недостаточно).

После перезагрузки папка catroot2 создалась заново, и все наладилось! Любопытно, что у товарища в чате система сама исправила проблему спустя четыре дня после появления.

Однако мне не удалось выяснить, что именно проделала ОС для самовосстановления. Равно как осталось загадкой, что вызвало сбой на вполне свежей установке Release Preview.

Заключение

Даже неопытный пользователь легко решит такую проблему переустановкой ОС поверх без всякой диагностики. Однако это проблематично на инсайдерских сборках, в т.ч. на этапе Release Preview, потому что нет дистрибутива!

Для быстрого и медленного колец ISO выпускаются не слишком часто, а в случае с Release Preview нужно ждать общей доступности грядущей версии. Поскольку легкого пути решения проблем нет, приходится обращаться за поддержкой или разбираться самостоятельно.