Открыть список
Как стать автором
Обновить

Комментарии 20

Хорошая, годная статья.

Добавлю из опыта:

— Много пишут, что ошибка 0x800B0001 возникала в 2014-2015 году именно у windows 7 + криптоПРО 3.6
https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=7973
http://remontka.pro/800b0001-error/
http://www.tune-it.ru/web/fender/blog/-/blogs/%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0-%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-windows-800b0001-80244018-cryptopro-vipnet?p_p_auth=B0lgkHFx
http://bazanovv.livejournal.com/37371.html

“Windows update error 800B0001 и Крипто-Про CSP 3.6
Наступили на глупые грабли, тем более глупые, что уже второй раз. При автоматической установке обновлений со WSUS 3.0 на рабочих станциях всё ок, при ручном поиске обновлений оттуда-же — ошибка 800B0001. В логах — ошибка проверки подписи автообновления клиента Windows Update. CheckSUR ошибок не находит, проявилось достаточно массово. Уже и агент Windows Update проверил-обновил, там обновления были, и на WSUS последний патч накатил — безрезультатно. Как оказалось, это опять что-то протухло в Крипто-Про CSP 3.6. Подобная ошибка уже была с год назад, там истёк сертификат, которым был подписан код, и вот опять. Лечится обновлением Крипто-Про до v3.6.7777 (3.6 R4).”
Спасибо. Есть целая группа проблем на предмет — то TLS не можем с WSUS согласовать, то прокси вдруг внезапно начали/прекратили использовать. Но тут обычно ничего не меняется, но каждый месяц кто-то да не может дальше обновляться.
Да, попила крови эта ошибка, и ведь поди догадайся, из-за чего проблема...

А знаете откуда ошибка? —
Windows Update стал требовать поддержку sha256 от дефолтного криптопровайдера системы.

А недешевая сертифицированная Крипто Про не умеет :(

https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=7973
А ошибку 0x80240020 при обновлении windows 7 pro x64 до windows 10 через WSUS (2012 R2) не подскажите как победить? Software distribution удалял. Все остальные обновления замечательно ставятся.
К сожалению, нет идей. У нас такие обновления суровее будут происходить, если конечно будут — все снесли, все поставили.
А кто-нибудь в курсе, что за обновление может отправить семёрку на несколько часов в "Установка обновлений: 100%" или "Пожалуйста, подождите"?
Такое эпизодически появляется последний год на разных компьютерах и во время сообщения что-то сильно нагружает диск. AppLocker не включен, так что хотфикс вряд ли поможет.
Встречался с таким и возникло стойкое "очучение", что Windows в этот момент делает скан всех дисков на предмет вирусов. Хотя я совершенно в этом не уверен. Однако подругому нельзя объяснить, почему на support форуме полно постов, что у кого-то это заняло пару часов, а у кого-то реально шуршало пару дней. После чего всё прекрасно устанавливается.
PS. Абсолютно не уверен, что дело именно в этом, однако на MS support тоже ни кто толком не объяснил.
С диском может быть ложный симптом, недавно словил такое на виртуалке и в мониторинге была 100% загрузка ЦП и лишь немного задействован диск.
При этом никаких ошибок и необычных событий в журнале нет и профайлер не запустишь, так как после перезагрузки проблема уходит. Ещё вспомнил, как на паре компов после жесткой перезагрузки повредилась ФС.
Появилась безумная мысль: может быть загрузку блокирует клиент Windows Update, который может часами искать обновления, шурша диском и загружая ЦП?
Интересное предположение. Как-то пристально рассматривал машины с W7, на которых клиент «бесконечно» искал обновления. Так вот он процессор и память утилизировал с удовольствием (100% CPU, 1-1,2Gb RAM, плавает по ходу работы). А к диску обращений нет.

Есть ли такая проблема, любопытно, с свежим KB3138612 «Windows Update Client for Windows 7 and Windows Server 2008 R2: March 2016»
Пользуюсь вот таким файлом:

sc sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
net stop "Background Intelligent Transfer Service"
net start "Background Intelligent Transfer Service"
net stop "Фоновая интеллектуальная служба передачи (BITS)"
net start "Фоновая интеллектуальная служба передачи (BITS)"
net stop "BITS"
net start "BITS"
gpupdate
gpupdate /force
wuauclt /detectnow
Дополнение к пункту #4:
Иногда даже этот вариант не помогает.
Откройте и посмотрите лог cryptsvc: C:\Windows\System32\catroot2\dberr.txt
У меня там была ругань с разнообразными ошибками, а остновка wuauserv не разблокировала SoftwareDistribution.
Помогло в итоге:

  • загрузиться в безопасном режиме (для разблокировки SoftwareDistribution, некоторым может хватить просто остановки wuauserv и bits)
  • net stop cryptsvc
  • переместить C:\Windows\System32\catroot2 и C:\Windows\SoftwareDistribution
  • загрузиться в нормальном режиме и ждать, около часа

Обновления обнаружились и я смог их установить.
Спасибо, интересно в чем причина проблемы с cryptsvc, и какая взаимосвязь с WU. У меня catroot2\dberr.txt пестрит ошибками, а нарушений целостности CheckSUR нет.

Пока "занятый" каталог SoftwareDistribution не встречался, возьмем на заметку.
Сегодня такую же штуковину провернули на 2008-R2 — полетели обновления.
Я еще не разобрался, но вроде бы не только обновления не ставились, но и новые роли.

А связь простая — вот описание сервиса: http://maximumpcguides.com/windows-7/what-is-the-cryptographic-services-cryptsvc-service/
Если нельзя верифицировать целостность обновления, то как вы её ставить будете? Причем, я подозреваю вопрос не столько в обновлении, сколько в списке обновлений — если нельзя верифицировать подпись списка обновлений, то качать нечего, что и наблюдаем.
И я вкину информации в базу знаний:
Если у вас на клиентах начали возникать ошибки 80072EE2, то вам придется переустанавливать WSUS, т.к. БД приказала долго жить.
Сама ошибка означает таймаут сервера обновлений.
У меня такие пока успешно лечатся iisreset. БД на другом сервер, по SQL Server Standard.
Если вы имеете ввиду перезапуск служб, то в таком случае помогала бы и просто перезагрузка всего сервера.
Если же она не помогает, то это БД, По крайней мере в случае с WID.
Да, это перезапуск служб. Сервер жалко перезагружать, он используется как вспомогательный файловый сервер.
Интересно, что там внутри SQL может сломаться, DBCC CHECKDB ничего интересного не пишет?
Не могу вам сказать, бекапов за то время уже нет.
Часть старых клиентов обновлялась нормально, новые и немного старых отказывались, ссылаясь на эту ошибку.
После переустановки WID все в норме.
Увеличил память для App Pool WSUS. Ошибка ушла. Добавил в статью.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.