-
-
Microsoft Windows Boards
-
alternative browser
Сегодня я хотел бы обсудить довольно специфическую проблему, которая долгое время не давала покоя техническому отделу, скажем так условного корпоративного клиента. Не то что бы она была какой-то уж чрезвычайно сложной, скорее просто никому не интересной (как в том анекдоте про Джо), и решалась местным персоналом при помощи полной «перезаливки» станции пользователя. Кстати, к слову сказать, проблема, которая будет описана в данной статье, мне уже встречалась, но всё никак не появлялось возможности обстоятельного её изучения. Благо, не так давно возникший аналогичный инцидент явился отправной точкой для написания этой заметки. Надо заметить, что для детального описания сбоев, в будущем хотелось бы все же разработать какой-нибудь единый диагностический шаблон, то есть собрать с проблемной станции именно ту информацию, которая представляла бы собой наиболее точное описание всех необходимых конфигураций и однозначно идентифицировала проблему, что бы пользователи могли находить решения по проблемам со схожими симптомам.
Описание проблемы
- Корпоративная доменная среда;
- Пользовательская станция под управлением Windows 7 Professional x64 6.1.7601 SP1;
- Агент SCCM 2012 версия 5.00.8239.1403.
Иногда (на самом деле редко) при введении в эксплуатацию свежеперезалитой/сохранившейся от другого пользователя рабочей станции, счастливый обладатель начинал жаловался на чрезвычайно низкую работоспособность: многие программы запускались крайне медленно (на протяжении десятков минут!). Работать же в уже запущенных приложениях было совершенно невозможно. При удаленном подключении к станции и попытке удалить произвольное программное обеспечение, было зафиксировано, что процессы инсталляций/деинсталляций «виснут», то есть сам процесс установки/удаления может длиться бесконечно, не завершаясь в течении приемлемого временного интервала. Когда удавалось запустить какое-либо диагностическое ПО (Process Hacker / Process Explorer и подобные), была зафиксирована активность с базой (хранилищем) компонентов. Кроме этого никаких отличительных симптомов обнаружить не удалось.
Часто бывает так что решения и исправления для ошибок Центра обновлений Windows не помогают, и обновления никак не хотят устанавливаться. В Windows 7 это серьезная проблема, хотя большинство пользователей и даже системных администраторов ее таковой не считают, на просторах б. СССР не принято устанавливать обновления, а зря — своевременная установка обновлений серьезно повышает шансы избежать негативных последствий от вирусных атак. Это статья для тех кто не привык переустанавливать Windows по любому поводу, а докапываться до причин проблемы и их устранять.
Большая часть ошибок центра обновления Windows возникает из-за того что он не может прочесть или получить доступ к какому либо файлу или ключу реестра. И таким образом все причины сводятся к двум:
- Недостаточно прав доступа к требуемому объекту, нет права на доступ вообще, либо нет права на чтение или запись.
- Файл или ключ реестра — отсутствуют или повреждены и поэтому не могут быть прочитаны
Служба Центра обновлений Windows использует при работе огромное количество различных файлов, поэтому вероятность что какой-то из них со временем будет поврежден весьма велика, к счастью в большинстве случаев повреждения не критичные и обновления нормально устанавливаются, но если нет, то эта статья поможет всё исправить.
Исправляем ошибки Центра обновления Windows
Предполагается что команды sfc /scannow и DISM /Online /Cleanup-Image /ScanHealth вы уже испробовали и Центр обновлений не заработал — идем дальше.
Установка пакета может занять достаточно много времени, даже если компьютер с SSD, это нормально дождитесь ее окончания и прочтите лог, в командной строке введите:
Файл может быть достаточно обширный, поиском найдите слово «Summary:», стрелкой помечено время установки пакета в секундах, как не трудно заметить установка длилась почти час, найдено 28 ошибок и внизу список поврежденных пакетов/манифестов:
Для исправления проще всего — скопировать эталонные файлы с рабочей системы где обновления нормально устанавливаются, система должна быть той же разрядности и желательно той же редакции. Если поврежденных файлов немного — можно выбрать нужные вручную, я не заморачивался и скопировал всё.
Все файлы *.mum и *.cat из C:\Windows\servicing\Packages с рабочей системы копируем на проблемную в папку C:\Windows\Temp\CheckSUR\servicing\packages, если такой нет — создайте вручную, C:\Windows — путь установки системы по умолчанию, если у вас другой измените.
Точно так же поступаем и с файлами типа *.manifest из C:\Windows\winsxs\Manifests копируем в C:\Windows\Temp\CheckSUR\winsxs\manifests\ на проблемной системе, если такого пути нет — создаем нужные папки.
После того как файлы скопированы — запускаем установку System Update Readiness Tool (SURT) еще раз, затем опять смотрим лог, если все сделано верно, то он должен выглядеть как-то так:
После этого пробуем устанавливать обновления, все должно получиться и заработать, если ошибок нет, а обновления всё равно не ставятся сбросьте службу обновления Windows, для этого в консоли запущенной от имени администратора выполните команды:
Topic: Need to manually fix problems in checksur (Read 18410 times)
0 Members and 1 Guest are viewing this topic.
I have a corrupt manifest. I see that people come here with the same problem and a helpful poster gives out the needed files to fix it.
Summary:
Seconds executed: 2355
Found 901 errors
CSI Manifest Failed Catalog Check Total count: 5
CSI Missing Deployment Key Total count: 15
CSI Missing Identity Total count: 6
CSI Mismatched Identity Total count: 2
CSI C Mark Deployment Not Marked Total count: 862
CSI C Mark Deployment Missing Total count: 9
CBS MUM Corrupt Total count: 1
CSI Missing Winning Component Key Total count: 1
Unavailable repair files:
winsxs\manifests\amd64_microsoft-windows-msauditevtlog_31bf3856ad364e35_6.1.7601.23040_none_25cd72a8a846d196.manifest
winsxs\manifests\wow64_microsoft-windows-ie-htmlrendering_31bf3856ad364e35_11.2.9600.17633_none_ffdaa43c6ba73cf8.manifest
winsxs\manifests\wow64_microsoft-windows-ie-internetexplorer_31bf3856ad364e35_11.2.9600.17420_none_1c0e758f636ca489.manifest
winsxs\manifests\x86_netfx-sbscmp10_dll_31bf3856ad364e35_6.1.7601.18514_none_770d53c5633e1fe1.manifest
winsxs\manifests\amd64_netfx-sbscmp10_dll_31bf3856ad364e35_6.1.7601.22724_none_d3aabe0e34c149f9.manifest
servicing\packages\Package_for_KB3004394_SP1~31bf3856ad364e35~amd64~~6.1.2.0.mum
servicing\packages\Package_for_KB3004394_SP1~31bf3856ad364e35~amd64~~6.1.2.0.cat
« Last Edit: September 13, 2015, 02:19:59 AM by garegin »
Hmmm let me check for those
First grab the zip file off this page and apply the reg file it in to add the take owner ship to the right click menu in explorer.
http://www.tweaking.com/articles/pages/add_quottake_ownershipquot_to_right_click_menu_in_vista_amp_7,1.htmlOnce that is done go to C:\Windows\servicing\ and right click on Packages and click on take ownership. You will now be able to copy the files into that folder.
I have attached the missing files, extract the files out of the attached zip file and put them in the C:\Windows\servicing\Packages\ folder.
Then run my pre-scan again, put a check on the box to have it add the cat files back to the database.
It says to check the checkbox for the cat files in the prescan, what about the manifests?
Manifests you need to do a sfc /scannow
some things got fixed. The sound and the touch work now! thanks a lot
but, I’m stuck in a failed update loop
error codes are 80070246 and 80070308. I tried erasing the pending updates in the registry, but it’s not there.
i also attached checksur
« Last Edit: September 16, 2015, 12:53:21 PM by garegin »
Someone else fixed most of the issues. But there is one left. Anyone here is welcome to take a crack at it.
Here is the new checksur.log
=================================
Checking System Update Readiness.
Binary Version 6.1.7601.22471
Package Version 26.0
2015-10-06 16:41
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
Checking Package Watchlist
Checking Component Watchlist
Checking Component Store
(f) CSI Catalog Missing 0x00000002 26f882afa7518dbac995a3b82a664764a4704bc1808f26680e4ba1198649b18e.cat ae677085b95..1a49ee8c5a5_31bf3856ad364e35_6.1.7601.17567_0594635cf349c2fc Missing catalog or invalid CatalogThumprint
(fix) CSI Catalog Missing CSI File Replaced File: 26f882afa7518dbac995a3b82a664764a4704bc1808f26680e4ba1198649b18e.cat From: C:\Windows\servicing\Packages\Package_1_for_KB2515325~31bf3856ad364e35~amd64~~6.1.1.0.cat
(f) CSI Missing Component Key 0x00000000 amd64_ae677085b95add6b9539e1a49ee8c5a5_31bf3856ad364e35_6.1.7601.17567_none_0594635cf349c2fc HKLM\Components\DerivedData\Components
(fix) CSI Missing Component Key CSI Registry Item Repaired Key created. There will be more reports as values are replaced.
(f) CSI Corrupt Deployment Keyform 0x00000000 appid 79a8da50923..72460ba3cfb_31bf3856ad364e35_6.1.7600.20740_071f1beb767921ef appid and keyform do not match; keyform is wrong.
(f) CSI Catalog Missing 0x00000002 9312cc322b388114eb0cad8e9da6ac66ec49e29544d339a38a6b5c549ac62f80.cat 202c00b5cd2..e8f8d3d7582_31bf3856ad364e35_6.1.7600.16444_b4028544b0890ec2 Missing catalog or invalid CatalogThumprint
(fix) CSI Catalog Missing CSI File Replaced Deleted CatalogThumbprint
(f) CSI Catalog Missing 0x00000002 47e2193b6e86fb9dba552f27d7cd005ef4edf06a984f9d804e4670686e7e51d0.cat 9eee84c6ac3..2538ead2473_31bf3856ad364e35_8.0.7600.20908_b8b8766185731dd4 Missing catalog or invalid CatalogThumprint
(fix) CSI Catalog Missing CSI File Replaced Deleted CatalogThumbprint
(f) CSI Catalog Missing 0x00000002 122752992b2967e34480ee96553c0012e85ebcb601f27ea6126442c02daee003.cat 89bc3a3186d..38a9947b066_31bf3856ad364e35_8.0.7600.16766_bc77a1c38977ecdf Missing catalog or invalid CatalogThumprint
(fix) CSI Catalog Missing CSI File Replaced Deleted CatalogThumbprint
(f) CSI Catalog Missing 0x00000002 081e12b8b938168da6ce0f59ce366d64c8c3c6322d322fa11d89ca99b744a87e.cat 50851c14f4b..9208f5b57ac_31bf3856ad364e35_6.1.7600.20910_5f3fb1e9d67e75ae Missing catalog or invalid CatalogThumprint
(fix) CSI Catalog Missing CSI File Replaced File: 081e12b8b938168da6ce0f59ce366d64c8c3c6322d322fa11d89ca99b744a87e.cat From: C:\Windows\servicing\Packages\Package_3_for_KB2515325~31bf3856ad364e35~amd64~~6.1.1.0.cat
(f) CSI Catalog Missing 0x00000002 5929dbf4705cb4c6032acb25463b5bee4297fa06d23bb4cb922d06442eb551f0.cat 41ed3b74800..5e0a215fd08_31bf3856ad364e35_8.0.7600.16766_bebb2178f1a778e0 Missing catalog or invalid CatalogThumprint
(fix) CSI Catalog Missing CSI File Replaced Deleted CatalogThumbprint
(f) CSI Missing C Mark 0x00000000 c!ae677085b95..1a49ee8c5a5_31bf3856ad364e35_6.1.7601.17567_0594635cf349c2fc amd64_ae677085b95add6b9539e1a49ee8c5a5_31bf3856ad364e35_6.1.7601.17567_none_0594635cf349c2fc Missing c!
(fix) CSI Missing C Mark CSI Registry Item Repaired c!ae677085b95..1a49ee8c5a5_31bf3856ad364e35_6.1.7601.17567_0594635cf349c2fc successfully added to amd64_ae677085b95add6b9539e1a49ee8c5a5_31bf3856ad364e35_6.1.7601.17567_none_0594635cf349c2fc
(f) CSI Missing Winning Component Key 0x00000000 x86_policy.9.0.microsoft.vc90.openmp_1fc8b3b9a1e18e3b_9.0.30729.5570_none_0e94c157b72a923c
(f) CSI C Mark Deployment Missing 0x00000000 c!1d8a7a776d9..ce6dc969b0b_b03f5f7f11d50a3a_6.1.7601.17587_6ab77d7b023fbe6d amd64_netfx-mscorwks_dll_b03f5f7f11d50a3a_6.1.7601.17587_none_bf133713d70404bb
Summary:
Seconds executed: 2636
Found 11 errors
Fixed 8 errors
CSI Catalog Missing Total count: 6
Fixed: CSI Catalog Missing. Total count: 6
CSI Missing Component Key Total count: 1
Fixed: CSI Missing Component Key. Total count: 1
CSI Corrupt Deployment Keyform Total count: 1
CSI Missing C Mark Total count: 1
Fixed: CSI Missing C Mark. Total count: 1
CSI C Mark Deployment Missing Total count: 1
CSI Missing Winning Component Key Total count: 1
no, this is unrelated to other threads.
=================================
Checking System Update Readiness.
Binary Version 6.1.7601.22471
Package Version 26.0
2015-10-10 18:16
Checking Windows Servicing Packages
Checking Package Manifests and Catalogs
Checking Package Watchlist
Checking Component Watchlist
Checking Component Store
(f) CSI Missing Winning Component Key 0x00000000 x86_policy.9.0.microsoft.vc90.openmp_1fc8b3b9a1e18e3b_9.0.30729.5570_none_0e94c157b72a923c
Summary:
Seconds executed: 2497
Found 1 errors
CSI Missing Winning Component Key Total count: 1
CSI Missing Winning Component Key
That made me laugh because I thought it was a Charlie Sheen joke lol
Aside from that, I am having trouble finding that file on my system, can you post a chunk of the log around that one so I can see if I am missing anything.
what you mean by chunk of the log around that. I posted the entire checksur.log. Do you want another log?
thanks. I already found that program from before. Unfortunately, by itself its of little use. Although it’s very helpful when used with a sfcfix script.
Just received «WindowsUpdate_80070246» «WindowsUpdate_dt000»
-
Daniël de Jongh
-
Jan 8, 2019
Daniël de Jongh
So i started up my old pc, its one from 2009 still works great with an i7.
When i tried updating which last was about 1 year ago, so it has missed quite a few updates. I got a windows update error.
Tried looking it up and tried doing some sfc /scannow stuff but that doesnt work either.
so i also used a System Update Readiness Tool scan:
Seconds executed: 1748
Found 117 errors
Fixed 106 errors
CSI Manifest Missing Total count: 1
CSI Catalog Missing Total count: 6
Fixed: CSI Catalog Missing. Total count: 6
CSI Missing Component Key Total count: 1
Fixed: CSI Missing Component Key. Total count: 1
CSI Missing Pinned Component Key Total count: 2
Fixed: CSI Missing Pinned Component Key. Total count: 2
CSI Missing Identity Total count: 3
Fixed: CSI Missing Identity. Total count: 3
CSI Corrupt Identity Total count: 3
Fixed: CSI Corrupt Identity. Total count: 2
CSI Missing C Mark Total count: 3
Fixed: CSI Missing C Mark. Total count: 3
CSI C Mark Deployment Not Marked Total count: 6
CSI Payload File Missing Total count: 3
CSI F Mark Bad Type Total count: 89
Fixed: CSI F Mark Bad Type. Total count: 89
CSI F Mark Missing Total count: 1
Fixed: CSI F Mark Missing. Total count: 1
CSI Store Directory Missing Total count: 1
Fixed: CSI Store Directory Missing. Total count: 1
Unavailable repair files:
So this is what ive gotten so far. dont know what the error is all about, i also updated my graphics drivers but with no luck.
Thank you for reading and i hope you can help me.
Similar threads
-
-
Microsoft Windows Boards
-
- This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
Диагностика
К сожалению в тот момент я не догадался остановить Службу регистрации ошибок Windows, что в разы бы упростило мне дальнейшую работу с клиентом. Поэтому, если Вы видите повышенную нагрузку от процессов WERFault, которая приводит к существенному снижению общей производительности системы, первым делом останавливайте службу, а потому уже продолжайте диагностику.
Затем я попытался устранить лишнюю нагрузку на систему и удалить один установленный компонент командой:
.. процесс msiexec.exe наглухо вис, показывая, что работает с хранилищем. При этом процессы, относящийся к деинсталлируемому ПО успешно были выгружены из памяти, однако сам msiexec упорно не хотел завершать свою работу. Все попытки инсталляции различных дистрибутивов заканчивались тем же «подвисанием» установщика, который просто стопорился на каком-нибудь из окон процесса установки, одним словом приложения не устанавливались. Общая производительность станции была, как уже отмечалось, очень низкая, низкая настолько, что порой невозможно было переключиться из окна в окно (!), окна приходилось просто сворачивать, только что бы добраться до находящегося на заднем плане окна 🙂
Тем не менее, первая подсказка у нас уже есть, сперва я попытался открыть в проводнике каталог , с которым так активно работали процессы WERFault. Директория относилась к системному механизму WER.
(Windows Error Reporting) — подсистема агрегации данных о сбоях в операционной системе Windows, предназначающаяся для отправки данных об ошибках на локальные/удаленные специализированные сервера Microsoft/независимых разработчиков ПО. Под данными здесь подразумевается пакет, включающий всю необходимую для проведения анализа инцидента информацию.
WER используется разделенные пути очередей отладочных данных:
- — для дампов процессов, запущенных в контексте или с повышенными привилегиями.
- — для дампов всех остальных процессов (в том числе уровня пользователя);
Очевидно, что в нашем случае используется второй (системный) вариант. Далее, в каталоге было обнаружено большое количество подкаталогов такого вот примерно вида:
Каталог содержит отчеты об ошибках, которые ставятся в очередь на отправку. Отчеты требуют пользовательского подтверждения отправки и наличия сетевого подключения для осуществления непосредственной загрузки данных на сервер. Когда отчет успешно выгружен, он удаляется из каталога и перемещается в каталог .
Вот так выглядит комплект данных для отправки отчета разработчикам. Глядя на размер файла , я начал смутно догадываться о причинах медленной работы системы 🙂 ведь файл журнала компонентной модели присутствовал в каждой поддиректории и каждый раз копировался в новую. В последствии, в зависимости от системных настроек, вся эта гигантская прорва информации еще и пытается каким-либо образом закачаться на локальный/удаленный сервер отчетов. Попытаемся разобраться в предназначении каждого файла из комплекта отправки:
После изучения содержимого каталога отправки становится очевидным, что WER готовит «отчет» об инциденте, куда включает все необходимые (?) файлы для передачи разработчику. Однако, почему происходило бесконечное создание фактически одинаковых пакетов отсылки? Вероятно, WER действовал в пределах нормы, просто в системе в тот момент что-то очень часто «падало», что и приводило к постоянной генерации отчетов. Давайте попытаемся разобраться что именно. Под рукой у нас для этого имеется все необходимое, а именно пара файлов с именами и , которые являются ничем иным как разными версиями дампа приложения. Не очень хорошо пока разбираюсь в структуре памяти процесса и не понимаю, что мне могут дать в данной ситуации данные кучи, поэтому откроем любой из этих файлов в отладчике WinDbg, благо в версии 6.12.0002.633 отладчик позволяет открывать и расширение .mdmp и .hdmp (в более ранних версиях могли иметься ограничения). При анализе дампа через команду !analyze -v мы видим имя сбойного процесса (PROCESS_NAME: TrustedInstaller.exe) и ниже по тексту стек вызовов момента падения:
Вот в этой точке то и наступает у нас ключевой момент изучения инцидента, эдакая развязка. Правильный (сложный) путь состоит в попытке отладить сбойный модуль, а неправильный (легкий) просто в поиске ответа о причинах падения на основании легкодоступных факторов. Времени было мало, поэтому я пошел по простому пути, просто переключившись на изучение файлов журнала компонентной модели. Грустно! 🙁
Двигаемся далее, мы выяснили что падает , вопрос почему он падает с завидным постоянством? Ну упало один раз, с кем не бывает 🙂 но зачем же так часто? Выходит, что бы часто падать, необходимо часто запускаться, кто-то постоянно создает задачи на установку пакетов. Вот тут то мы вспоминаем, что у нас в нашей корпоративной среде используется агент SCCM 2012. Что это такое? Выдержка из Wikipedia:
System Center Configuration Manager (SCCM, ранее SMS) — продукт для управления ИТ-инфраструктурой на основе Microsoft Windows и смежных устройств. Предоставляет такие возможности, как: управление обновлениями, развёртывание ПО и операционных систем, интеграция с NAP, инвентаризация аппаратного и программного обеспечения, удалённое управление, управление виртуализированными и мобильными системами на базе Windows.
Очень модная в данный момент штука, чрезвычайно громоздкая, написанная на старом бейсике начала 90-х годов и скомпилированная с опциями максимизации размера бинарного файла (шутка) 🙂 Так вот этот самый агент SCCM и спамил нам постоянно задачи на установку обновлений операционной системы. Вроде как разобрались что именно падает и кто постоянно создает эти падающие впоследствии задачи. Но почему падает? Первое что приходит на ум, так это проанализировать файл журнала компонентной модели и поискать ответ в нем. Приведу основные, самые интересные (на мой взгляд), выдержки из этого файла, поскольку целиком файл занял порядка 1 гигабайта, вставлять его полностью не вижу возможности да и смысла, поэтому перечислим лишь основные моменты:
Во-первых, бросается в глаза код ошибки 0x800f0805, намекая на битые пакеты (?). Далее в файле можно увидеть интересные сообщения: «Store corruption detected» и «MissingWinningComponentKey on resource», что сразу же наводит нас на мысль о повреждении хранилища компонентов.
Выводы
Инцидент породил слишком большое количество вопросов.
- Почему у нас агент обновления ругается на битые пакеты? Приходят ли они действительно битые с сервера обновлений или причина в другом?
- Почему TrustedInstaller не отслеживает повреждения хранилища пакетов/компонентов и падает вместо завершения с кодом ошибки? Ошибка в коде модуля?
- Почему WER копирует в большие объемы данных, тем самым сильно нагружая систему? А если устроить циклическое падение множества процессов в системе, то WER просто «положит» станцию, как в этом случае?
Я думаю, что все эти вопросы останутся без ответов, поскольку мы не докопались до сути проблемы. Ну а исключить возможность возникновения подобных ситуаций в будущем можно через консоль Configuration Manager Console. Как один из вариантов: — — Software Update Groups, задать для требуемой группы , а вот уже на Alert’ы потом повесить необходимые действия. Возникает вопрос в более тонкой интеграции агента SCCM со стеком обслуживания с целью отслеживания ситуации с падающим процессом TrustedInstaller.exe на клиентской машине и остановке задач по установке компонентов. В нашем случае он продолжал ставить задания на запуск установки обновлений.
Если у Вас без видимых на то причин не устанавливаются приложения, виснет установка драйвера, зависает установка обновления, при этом не выдается никаких ошибок, а просто-напросто процесс установки долго выполняется на каком-либо из этапов, то, возможно, вы столкнулись с ситуацией занятого стека обслуживания. Причиной этого, зачастую, может быть повреждение хранилища компонентов.
Решение
Скорее по привычке, нежели обоснованно, первой я запустил команду Sfc с ключом и тут же получил следующую ошибку:
Эта лишняя (в данной ситуации) команда дала понять, что стек обслуживания кем-то занят. Скорее всего, со стеком одновременно невозможно работать нескольким источникам. Вспоминаем, про , однако его снятие нам ничего не даст, поскольку работает агент SCCM, который постоянно создает задачи на установку. Поэтому, при помощи диспетчера задач рекомендуется снимать следующие процессы (в заданной последовательности):
CcmExec.exe;CmRcService.exe;msiexec.exe;TrustedInstaller.exe;wermgr.exe— если присутствует;
Поле этого вся активность со стеком обслуживания прекратилась. Далее была выполнена команда:
DISM /Online /Cleanup-Image /ScanHealth
результатом выполнения которой было следующее сообщение «Выполнение операции scanhealth завершено, см. журнал по адресу %windir%\logs\CBS\Checksur.log. Операция успешно завершена.»:
с рекомендацией проверить файл . Привожу выдержку ключевых моментов содержимого данного файла:
Видно, что DISM исправил ошибок. После этого была произведена перезагрузка системы и SCCM продолжил штатную установку обновлений. Более проблем у пользователя не возникало.
