SVCHOST już nie na 100%: Microsoft naprawił wreszcie aktualizacje Windows XP

W zeszłym roku wielu użytkowników Windows XP SP3 zauważyło, żeusługa Windows Update w praktyce przestała nadawać się do użytku.Chodzi oczywiście o słynny na forach dyskusyjnych proces SVCHOST,zużywający niemal 100% dostępnej mocy procesora i powodujący„zamrożenie” systemu. Do takich zamrożeń dochodziłozwykle dwukrotnie – pierwszy raz gdy Windows Update łączyło sięz serwerami Microsoftu, by pobrać listę dostępnych aktualizacji,drugi raz, gdy bardzo cierpliwy użytkownik po pobraniu listy w końcubył w stanie wyrazić zgodę na instalację tychże aktualizacji. Jeszczegorzej było w sytuacji, gdy włączone były automatyczne aktualizacje.Usterkę wyeliminować miała listopadowa runda poprawek, ale niestetytak się nie stało, a wręcz przeciwnie, problem powrócił z jeszczewiększą siłą. Okazało się też, że jego historia jest dłuższa, niżmogłoby się wydawać. O problemie z SVCHOST wspomnianona forach TechNetu w czerwcu zeszłego roku, pierwszy wskazał na jegoprawdziwą przyczynę znany dziennikarz IT i pisarz Jeff Dunteman,sugerując,że swoją genezą błąd ten sięga 2004 roku (pierwsze zgłoszenia naforum dobreprogramy.pl pochodzą z 2007 roku!), a winnym jestmechanizm aktualizacji Windows Update, wuauclt.exe. Bez pomocyMicrosoftu użytkownikom XP pozostawało jedynie wyłączyć WindowsUpdate i ręcznie aktualizować swój system. Dopiero w listopadzie DougNeal z zespołu Windows Update opublikował wiadomość na liściedyskusyjnej patchmanagement,opisującą co się właściwie stało:[img=windowspatch]Problem powodowany jest przez klienta Windows Update,oszacowującego wyjątkowo długi łańcuch zastępstw – coś co IE6 iIE7 mają znacznie dłuższe niż jakakolwiek inna wersja IE, ze względuna ich czas na rynku. Każdy kolejne ogniwo takiego łańcucha podwajazasoby CPU wymagane do oszacowania go w stosunku do poprzedniegoogniwa. Łańcuch jest tak długi, że jego konstrukcja dławi klientaWindows Update.Najwyraźniej więc klient WUA,komunikując się z bazą aktualizacji ustalał, które z nich należypobrać i zainstalować, a które zostały zastąpione przez inne i nietrzeba ich już pobierać. W miarę jak liczba aktualizacji rosła,proces zajmował coraz więcej zasobów (najwyraźniej do przeszukiwaniadrzewa dostępnych łatek nie wykorzystano zbyt efektywnego algorytmu,nie było też żadnego mechanizmu pozwalającego na ominięcie zbędnychjuż przeszukiwań). W końcu łańcuch stał się tak długi, że przekroczyłlimity przewidziane dla Windows Update (w pewnych sytuacjach miałnawet 40 i więcej wzajemnie zastępujących się elementów)Microsoft postanowił więc rozwiązaćproblem za pomocą unieważnienia najstarszych, zbędnych,przestarzałych aktualizacji w łańcuchu aktualizacji InternetExplorera. Zrobiono to już w październikowym wydaniu poprawekbezpieczeństwa, jednak okazało się, że agent Windows Update okazałsię sprytniejszy od programistów i nie dał się zwieść tą sztuczką –u większości użytkowników problem nie tylko nie zniknął, ale jeszczesię zaostrzył.W listopadowej edycji poprawek podjętokolejną próbę z unieważnieniem starych poprawek, ale i ta się nieudała. W grudniu więc oprócz unieważniania kolejnych łatek,zdecydowano się wprowadzić zmiany w logice mechanizmu zastępowania.Niestety jednak problem wciąż pozostał nierozwiązany –pisał kilka dni po wydaniu łatek Doug Neal, przyznając, że dzieli zużytkownikami frustrację wynikającą z niemożliwości rozwiązania tegoproblemu przez Microsoft.Dopiero najnowsza, styczniowa rundapoprawek rozwiązała problem z SVCHOST. W oficjalnym oświadczeniuDustin Childs, menedżer Microsoft Trustworthy Computing Group,poinformował, że przestarzałe aktualizacje Internet Explorera zostałzastąpione nowszymi. Pozwoliło to skrócić czas aktualizacji WindowsUpdate, zwiększyło wydajność Windows XP i w żaden sposób nie zagrażabezpieczeństwu użytkowników.Biorąc pod uwagę to, że już od 8kwietnia 2014 Windows XP nie otrzyma żadnych nowych łatek, tonaprawdę ładny gest ze strony Microsoftu, by naprawić niemal wostatniej chwili tak dokuczliwą usterkę. Rozwiązanie problemuAby zmusić agenta Windows Update do działania we własnej instancji SVCHOST, którą łatwo później zabić z poziomu Menedżera zadań, należy w konsoli Windows (CMD.EXE) wydać polecenie: