bifido 76
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Mazahaka_lab
На примере моей системы, поясню почему скрипт не удаляет KB2534111. Вот экспорт ветки реестра со списком пакетов для компонента, относящегося к KB2534111.
Код: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ComponentDetect\amd64_microsoft-windows-oobe-machine-ui_31bf3856ad364e35_0.0.0.0_none_e253bf5ee2386636]
"Package_1_for_KB2534111~31bf3856ad364e35~amd64~~6.1.1.0.2534111-1_neutral_LDR"="6.1.7601.21700@2"
"Package_1_for_KB2534111~31bf3856ad364e35~amd64~~6.1.1.0.2534111-2_neutral_GDR"="6.1.7601.17591@2" |
А вот ветка определяющая актуальную версию компонента -
Код: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\amd64_microsoft-windows-oobe-machine-ui_31bf3856ad364e35_none_a4b949a8ef06c166\6.1]
@="6.1.7601.17591"
"6.1.7601.17514"=hex:01
"6.1.7601.17591"=hex:01 |
Для этого компонента актуальной версией является 6.1.7601.17591 и нет другого обновления с его большей версией, которое бы заменяло KB2534111, соответственно и скрипт не считает его устаревшим. Интересно было бы узнать, что у вас в этих ветках на предыдущем образе.
В случае с veremi, могу предположить, что скрипт мог определить KB3177467 как устаревшее, если в этой ветке указана актуальная версия компонента (значение по умолчанию), не соответствующая этому обновлению.
Вот как должно быть в норме. Список пакетов -
Код: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\ComponentDetect\x86_microsoft-windows-servicingstack_31bf3856ad364e35_0.0.0.0_none_2d3956f60f74b69a]
"Package_1_for_KB976902~31bf3856ad364e35~x86~~6.1.1.17514.976902-1_neutral_GDR"="6.1.7601.17514@32"
"Package_2_for_KB2533552~31bf3856ad364e35~x86~~6.1.1.1.2533552-2_neutral_GDR"="6.1.7601.17592@16"
"Package_2_for_KB3177467~31bf3856ad364e35~x86~~6.1.1.1.3177467-2_neutral_LDR"="6.1.7601.23505@16" |
Актуальная версия -
Код: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\x86_microsoft-windows-servicingstack_31bf3856ad364e35_none_ee01dfbc727bc8e6\6.1]
"6.1.7600.16385"=hex:01
@="6.1.7601.23505"
"6.1.7601.17514"=hex:01
"6.1.7601.17592"=hex:01
"6.1.7601.23505"=hex:01 |
Проделал эксперимент и заменил значение по умолчанию @="6.1.7601.23505" (KB3177467) на @="6.1.7601.17514" (KB976902) - и получил в точности такую картину как у veremi, когда скрипт считает актуальным KB976902 и предлагает к удалению KB3177467. Если это так, то такому дистрибутиву от Dell, имхо, грош - цена (ибо что-то они там накосячили), так как система будет использовать в задачах обслуживания файлы старого стека - KB976902, игнорируя наличие KB3177467 (по крайней мере, сразу после прохождения sfc /scannow).
PS. Хотя, может у этого Dell - это фишка такая. Я, например, этот способ , когда более новые обновления установлены, но система использует для работы предыдущие версии файлов (успешно проходя при этом проверку на целостность), хотел использовать для борьбы с невозможностью обновления на новых процессорах, но так как уже вышел wufuc, то такой скрипт стал более не актуальным, и я положил его на дальнюю полочку.
|
Всего записей: 2474 | Зарегистр. 08-04-2016 | Отправлено: 01:54 27-09-2018 | Исправлено: bifido 76, 02:31 27-09-2018 |
|
