8 Minutės
Windows 11 atnaujinimų grandinė sukėlė paleidimo klaidas ir BSOD riziką
Gruodžio ir sausio Windows 11 atnaujinimuose įvyko problema, ir Microsoft dabar pripažįsta, kad tai nėra vienkartinė klaida, o domino efektas. Pirmiausia vartotojai pranešė apie netikėtą elgesį — kompiuteriai, kurie atsisakė išsijungti, keistas našumo svyravimas — o vėliau pasirodė rimtesnė problema: sistemos nepaleidžiamos, ekrane atsiranda mėlynas ekranas su klaidos pranešimu UNMOUNTABLE_BOOT_VOLUME dar prieš Windows įkrovą.
Pradinis instinktas buvo apkaltinti sausio taisymą. Tai suprantama. Tačiau Bleeping Computer pranešimai ir Susan Bradley įžvalgos svetainėje AskWoody nurodo sudėtingesnę seką: gruodį išplatintas klaidingas atnaujinimas paliko kai kurias sistemas pažeidžiamas, o sausio atnaujinimas tada paleido grandininę reakciją. Trumpai tariant, tai yra dviejų atnaujinimų sąveika, o ne vienkartinis klaidos atvejis.
Kaip tai pasireiškia realiai? Apsigavusiems įrenginiams simptomas yra akivaizdus ir staigus. Paleidžiate įrenginį, jis bando įsikrauti, o vietoje įprasto įkrovos rato ekrane atsiranda mėlynas ekranas su užrašu UNMOUNTABLE_BOOT_VOLUME. Nėra lėto degradavimo. Nėra įspėjimo — tik stop kodas ir kompiuteris, kuris nepasiekia darbalaukio.
Microsoft dabartinis laikinas sprendimas yra tiesmukas, bet praktiškas: blokuoti sausio atnaujinimo diegimą įrenginiuose, kurie galėtų patekti į BSOD ciklą. Tai užkerta kelią naujiems atvejams. Tačiau tai nieko nekeičia sistemoms, kurios jau įdiegė probleminį atnaujinimų derinį ir yra užstrigusios prie įkrovos.
Tad ką tai reiškia administratoriams ir kasdienių vartotojams? Pirma, pripažinimas: tai nėra mitinė masinė epidemija, bet ji stipriau paliečia įmonių ir organizacijų įrenginius dėl sudėtingos atnaujinimų istorijos ir sluoksniuotos aptarnavimo tvarkos. Antra, budrumas: patikrinkite atnaujinimų istoriją, ypač jei jūsų įrenginys gavo kelis kumuliacinius atnaujinimus gruodį ir sausį.
Jei jūsų įrenginys dabar stabilus, atidėkite sausio atnaujinimo diegimą, kol Microsoft patvirtins pataisą; jei administruojate kelis galinius taškus, apsvarstykite automatinio diegimo sustabdymą, kol situaciją ištirsite.
Neegzistuoja universalus paprastas sprendimas sistemoms, kurios jau rodo UNMOUNTABLE_BOOT_VOLUME stop kodą — Microsoft dar neišleido plataus diapazono atkūrimo įrankio būtent šiai grandininei reakcijai. Atkūrimas dažnai priklauso nuo turimų naujausių atsarginių kopijų, atkūrimo laikmenų ar įmoninių vaizdavimo įrankių, kurie gali atstatyti žinomą gerą būseną. Daugeliui IT komandų tai reiškia grįžimą prie patikrintų nelaimių atkūrimo procedūrų, o ne pasikliauti momentiniu pataisymu.
Kaip atpažinti ir patvirtinti paveiktumą
Prieš imantis veiksmų, svarbu aiškiai identifikuoti, ar įrenginys yra paveiktas atnaujinimų grandinės. Pagrindiniai žingsniai diagnostikai yra šie:
- Peržiūrėkite Windows Update atnaujinimų istoriją: žiūrėkite, ar buvo įrašyta gruodžio datos KB palaikanti pataisa, o vėliau sausio kumuliacinis atnaujinimas.
- Tikrinkite paleidimo klaidų kodus: mėlyno ekrano pranešimas UNMOUNTABLE_BOOT_VOLUME yra aiškus rodiklis, kad užkrovos tūris buvo negalimas dėl failų sistemos arba atnaujinimų sąveikos problemos.
- Analizuokite įvykimų žurnalus (Event Viewer): System ir WindowsUpdate žurnalai gali atskleisti eiliškumą ir kokie paketai buvo taikyti prieš atsirandant klaidai.
- Patikrinkite aparatūros ir tvarkyklių suderinamumą: kai kuriais atvejais aparatūros arba diskų tvarkyklių nesuderinamumo simptomai gali pasireikšti kitaip, bet verta atmesti šią galimybę.
Kas sukelia grandininę reakciją?
Apibendrintai, problema išryškėja, kai du arba daugiau atnaujinimų paveikia tuos pačius sistemos komponentus, konfigūraciją arba metaduomenis atnaujinimų kataloge. Galimos priežastys apima:
- Netinkamai paruoštos kumuliacinės ar funkcijų pataisos, kurios pakeitė įkrovos ar failų sistemos tvarką.
- Atnaujinimų tvarka: gruodžio atnaujinimas paliko sistemą „pažeidžiamą“, o sausio atnaujinimas pakeitė failų sistemos ar BCD (Boot Configuration Data) elementus taip, kad sistema nebegali rasti ar prijungti įkrovos tūrio.
- Įmonių valdymo įrankių ir sluoksniuoto aptarnavimo poveikis: kai centralizuotos politikos ar vaizdavimo sprendimai modifikuoja atnaujinimų diegimo eigą, atsiranda papildomų kintamųjų.
- Disko ar failų sistemos klaidos, paslėptos iki kol atnaujinimų seka jas išprovokuoja.
Techninis paaiškinimas (santrauka)
Techniniu požiūriu, UNMOUNTABLE_BOOT_VOLUME reiškia, kad sistemos įkrovos procesas negali prisijungti prie pasirinkto tūrio arba rasti pagrindinių failų. Tai gali būti dėl pažeistos NTFS struktūros, BCD konfigūracijos gedimo arba tvarkyklių/instrumentų pakeitimų, trukdančių diskų identifikacijai. Kai atnaujinimai pakeičia tvarkyklę arba sisteminius komponentus be atitinkamo perkrovimo ar atnaujinimų eiliškumo užtikrinimo, įkrovos grandinė gali nutrūkti.
Laikini sprendimai ir prevencija
Microsoft laikinai sustabdė saugaus diegimo galimybę tam tikruose įrenginiuose, bet yra papildomų veiksmų, kuriuos gali atlikti administratoriai ir pažengę vartotojai:
Administratorių veiksmai
- Užblokuokite įtariamą atnaujinimą per centralizuotas valdymo priemones (WSUS, Intune ar grupines politikas), kol gausite oficialią pataisą.
- Peržiūrėkite atnaujinimų diegimo istoriją ir sukurkite filtrus, kurie neleis taikyti problematiškų KB paketų į jautrias „rinkinių“ mašinas.
- Testuokite pataisas kontroliuotose testavimo aplinkose, atkartodami gruodžio ir sausio atnaujinimų tvarką, kad būtų galima atkurti problemą ir patvirtinti pataisos efektyvumą.
- Paruoškite atkūrimo planus — turėkite paruoštas sistemos vaizdų, atsargines kopijas bei įrankius, leidžiančius greitai atkurti įrenginius į žinomą gerą būseną.
Paprasti vartotojai
- Jei kompiuteris dabar stabilus, atidėkite didesnius atnaujinimus ir įgalinkite automatinių atnaujinimų valdymą arba pasitarkite su IT specialistais.
- Reguliariai darykite atsargines kopijas ir turėkite avarinį atkūrimo laikmeną (pvz., Windows Recovery Drive arba sistemos atvaizdą).
- Stebėkite patikimus informacijos šaltinius (Microsoft bendruomenės pranešimus, techninius tinklaraščius kaip Bleeping Computer, AskWoody ir kt.).
Atkūrimo scenarijai paveiktoms sistemoms
Jei sistema jau rodo UNMOUNTABLE_BOOT_VOLUME, galimi keli atkūrimo keliai, priklausomai nuo organizacijos išteklių ir pasirengimo lygio:
- Naudoti atkūrimo laikmeną (Windows Recovery Environment): bandyti Startup Repair, chkdsk ir bootrec komandų rinkinį (bootrec /fixmbr, bootrec /fixboot, bootrec /rebuildbcd), tačiau sėkmė priklauso nuo klaidos priežasties ir BCD būklės.
- Atkurti iš vaizdo (imaging) sprendimų: jeigu įmonė naudoja bitų vaizdavimo sprendimus (SCCM, ImageX, Acronis, Veeam), greitas atstatymas į paskutinę žinomą gerą nuotrauką dažnai yra patikimiausias kelias.
- Atkurti failus iš atsarginių kopijų ir pertvarkyti įkrovą: kai kuriais atvejais reikia atkurti tik tam tikrus sistemos failus arba BCD įrašus.
- Įvertinti disko sveikatą: fiziniai diskų gedimai gali pasireikšti panašiai, todėl verta paleisti SMART ir diagnostinius įrankius.
Kodėl organizacijų aplinkos dažniau nukentėjo?
Įmonių aplinkos turi daug papildomų kintamųjų, kurie didina riziką:
- Sluoksniuotas atnaujinimų valdymas: kai atnaujinimai diegiami per kelis žingsnius arba skirtingus kanalus, lengviau susidaryti nepageidaujamoms sekoms.
- Įvairialypė aparatūra ir tvarkyklės: IT parkai dažnai susideda iš skirtingų gamintojų aparatūros ir tvarkyklių versijų, o tai didina suderinamumo riziką.
- Individualūs vaizdai ir konfigūracijos: įmonės dažnai taiko pritaikytus OS vaizdus arba politiką, kuri gali sąveikauti su oficialiais Microsoft atnaujinimais.
- Ilgos laiko juostos ir netolygus atnaujinimų diegimas: dėl palaikymo ciklų kai kurios sistemos gali būti labiau pažeidžiamos senesnių atnaujinimų likučių.
Techninės analizės perspektyvos
Norint pilnai suprasti grandinę, Microsoft ir partneriams reikės atsekti kiekvieno atnaujinimo pakeitimus, metaduomenus ir diegimo seką. Svarbūs tyrimo taškai:
- Atnaujinimų metaduomenų analizė — ar pakeitimai paveikė tą pačią sisteminę sritį (pvz., failų sistemą, įkrovos tvarkykles, saugos filtrus).
- Diegimo eiliškumo ir tranzicijų žurnalo analizė — kada ir kaip buvo taikomi atnaujinimai, ar buvo perkrovimo tarp atnaujinimų, ar diegimo metu įvyko klaidų.
- Įtakos testavimas įvairiose aparatūros konfigūracijose — kiek atvejai priklauso nuo konkrečių diskų valdiklių, NVMe/SSD modelių ar trečiųjų šalių tvarkyklių.
Rekomendacijos IT komandoms ir vartotojams
Norint sumažinti riziką ateityje, rekomenduojama:
- Sukonfigūruoti atnaujinimų valdymą (Windows Update for Business, WSUS, Intune) su aiškiais testavimo ir diegimo etapais.
- Kaupti ir dalintis stebėjimo duomenimis, kad greičiau būtų nustatyti grandininiai poveikiai tarp paketų.
- Laikyti paruoštas atsargines kopijas ir greito atkūrimo procedūras kiekvienai kritinei naudai.
- Užtikrinti, kad testavimo aplinkos kuo tiksliau atkartotų gamybines konfigūracijas, įskaitant tvarkykles ir trečiųjų šalių programinę įrangą.
Išvados
Ši atnaujinimų grandinė primena, kad atnaujinimų valdymas ir testavimas organizacijose turi būti atliekami su atitinkamu atsargumu. Svarbu ne tik reaguoti į pataisas, bet ir suprasti jų tarpusavio priklausomybes. Kol Microsoft išleis galutinę pataisą, geriausia strategija yra derinti proaktyvius prevencinius veiksmus, reguliarius atsarginių kopijų kūrimus ir nuoseklų atnaujinimų testavimą.
Stebėkite oficialias Microsoft rekomendacijas ir patikimus pranešimus iš technologijų žiniasklaidos. Būkite pasirengę atkurti sistemas pagal įmonės turimas atkūrimo procedūras, o ne laukti momentinio sprendimo, jei jau atsirado UNMOUNTABLE_BOOT_VOLUME stop kodas.
Šaltinis: smarti
Komentarai
Marius
Ar čia tikrai tik dviejų KB sąveika? Skamba kaip kažkas gilesnio, pvz tvarkyklės arba firmware konfliktas... kas turi nuoseklius log'us ir patvirtina?
duomix
Mačiau tokį bugą irgi darbe, vienas PC po gruodžio atnaujinimo užstrigo su UNMOUNTABLE_BOOT_VOLUME. chkdsk nieko nepadėjo, teko iš vaizdo atstatyt, chaosas. MS turi geriau testint
Palikite komentarą