DTGaraGe | Автомобили, Офроуд, Заваряване, Linux, AI

Регистрирайте безплатен акаунт днес, за да станете член! След като влезете, ще можете да участвате в този сайт, като добавяте свои собствени теми и публикации, както и да се свързвате с други членове чрез вашата лична пощенска кутия!

Урок 0xc000021a: Как един прекъснат ъпдейт уби Windows и как го върнахме без загуба на данни

0xc000021a: Как един прекъснат ъпдейт уби Windows и как го върнахме без загуба на данни


Възстановяване след грешка 0xc000021a.png

Синият екран с тъжното лице не е краят. Той е квитанция за нещо, което вече се е случило.


Всичко започна с една снимка в Viber. Приятел праща кадър на монитор - класическото синьо, тъжният двоеточие-скоба, и отдолу Stop code: 0xc000021a. Съобщението към снимката: "виж какво ми се случи".

Не той машината. Приятел на приятеля. И собственикът - човек, който не различава BIOS от Windows и на третата команда беше готов да "го удари от земи". Та тази тема е за две неща едновременно: конкретната случка как върнахме един мъртъв Windows, и наръчник за всеки, който утре види същия код.




Какво всъщност значи 0xc000021a


Кодът се разшифрова като STATUS_SYSTEM_PROCESS_TERMINATED. На човешки: критичен процес в user-mode е умрял. Обикновено това е winlogon.exe или csrss.exe - двата стълба, без които ядрото не може да продължи. Умре ли един от тях, Windows пада веднага, защото приема, че системата вече не е в доверено състояние.

Най-честите причини, подредени по вероятност:


  • Прекъснат или частично инсталиран ъпдейт - класика при рестарт или ток по време на update
  • Повреден системен файл или счупена registry хива след мръсно изключване
  • Несъвместим драйвер или филтър на трета страна (антивирус, VPN, disk encryption) след ъпдейт
  • Лоши сектори на диска или умиращ SSD

В нашия случай беше първото. Как разбрахме - идва по-надолу.



Първо правило: спаси данните, после лекувай


Преди изобщо да пипаш поправки, приеми едно наум: системата е счупена, данните може да не са. Затова редът е обратен на инстинкта. Не се хвърляй на Reset и преинсталация - това трие. Първо изкарай данните на сигурно.

Най-бързият начин без разглобяване е live Linux USB. Буутваш от флашка (в моя случай Parrot), монтираш дисковете и копираш данните. Linux чете NTFS без проблем и не му пука за счупения Windows boot. При тази машина имаше късмет - беше десктоп с два диска: системен SSD и отделен HDD за данни. Затова не се наложи външен носител изобщо - прехвърлих данните на потребителя директно от SSD-то на втория вътрешен HDD, disk-to-disk, преди да пипна каквото и да е. SATA към SATA е и по-бързо от USB.


Два вътрешни диска са лукс в такава ситуация. Спасяваш данните от единия на другия, без нищо да излиза от кутията.



Влизане в WinRE без пароли


Средата за възстановяване (WinRE) е където се работи. Ако машината не влиза в Windows, стигаш до нея така: прекъсваш буутването три пъти подред (щом видиш логото, задръж бутона докато угасне), на четвъртия път сама влиза в "Preparing Automatic Repair", после менюто.

Тук ударихме първата стена. Automatic Repair се завъртя и се предаде - "Startup Repair couldn't repair your PC". Нормално, той рядко хваща 0xc000021a. Не го оставяй да те върти в цикъл - карай директно на:


  • Troubleshoot → Advanced options

Оттам има шест опции. Логичният първи изстрел е Uninstall Updates → Uninstall latest quality update - при 0xc000021a след ъпдейт това го оправя в мнозинството случаи.

Но тук дойде вторият капан: потребителят не знаеше паролите си. Uninstall Updates иска акаунт с парола. System Restore - също. Класическа ситуация: човекът влиза с ПИН или с празна парола и няма идея какъв е реалният акаунт.

Спасението е Command Prompt - той единствен не пита за парола на акаунт. Стартира като SYSTEM. Оттам нататък всичко се прави на ръка.




Диагностика и ремонт от командния ред


Първо - намери на коя буква е Windows. В WinRE почти никога не е C:, буквите се разместват. Пусни:

Code:
diskpart
list volume
exit

Гледаш таблицата, търсиш най-големия NTFS дял. Потвърждаваш с dir БУКВА:\Windows - ако изсипе System32, WinSxS и компания, това е дискът.

После идва тежката артилерия, по ред:


  • chkdsk C: /f /r - проверява файловата система и лошите сектори. Отнема дълго, не се пипа.
  • sfc /scannow /offbootdir=C:\ /offwindir=C:\windows - проверява и заменя счупени системни файлове (offline вариант).
  • dism /image:C:\windows /cleanup-image /restorehealth - оправя component store-a.

chkdsk свърши чудесна работа - намери и поправи bitmap грешки (свободно място, маркирано като заето) и orphaned files (файлове, откачени от директориите си). Точно повредата, която оставя прекъснат ъпдейт. И най-важното - 0 KB in bad sectors. Дискът беше здрав, само файловата система беше счупена.

sfc намери счупени файлове, но не успя да ги поправи всичките сам ("was unable to fix some of them"). Тук трябваше DISM да му подаде здрави копия. И тук дойде голямата спънка.




Когато DISM отказва да работи


DISM в offline режим (от WinRE) гърми с Error: 2 - Unable to access the image, колкото и правилен да е пътят. Причината - в WinRE няма достъп до нормалния източник на здрави компоненти, а понякога самата COMPONENTS хива е повредена.

Пробвахме всичко: различни варианти на пътя (/image:C:\ срещу /image:C:\windows), /revertpendingactions за отмяна на висящите ъпдейт операции - все Error 2. Проверихме и последния бърз коз, RegBack (резервно копие на registry-то):


Code:
dir C:\Windows\System32\config\regback

0 File(s), 0 bytes. Празна. От Windows 10 версия 1803 нататък Microsoft спря да пълни RegBack по подразбиране. Този път е затворен за всички модерни системи - не разчитай на него.

Тук се вижда и датата на престъплението. Като листнахме C:\Windows\System32\config, registry хивите SOFTWARE, SAM, SECURITY бяха с дата от последните дни - пипани точно когато машината се е счупила. Ъпдейтът е бил насред запис в регистъра, когато токът/бутонът го е прекъснал. Оттам счупената хива, оттам мъртвият winlogon, оттам 0xc000021a.


Понякога командният ред ти казва не само какво е счупено, а и кога е станало. Датите по registry хивите са като часовник на местопрестъплението.



Кога да спреш да се бориш


Ето важен момент, който мнозина пропускат: знай кога да спреш. Когато offline DISM не работи, RegBack е празна, sfc не може да довърши сам, а Startup Repair и Reset се провалят - изчерпал си WinRE. Всеки следващ час ровене е загубено време.

На този етап има само едно чисто решение: флашка с Windows. И понеже данните вече бяха спасени и дискът беше здрав (chkdsk потвърди 0 bad sectors), решението беше просто - чист Windows на системния диск, без да пипаме диска с данните.




Чиста инсталация и капанът с акаунта


Машината беше i7 от 6-то поколение (Skylake, 3.4 GHz), 16 GB RAM, дискретна NVIDIA с 4 GB - напълно достатъчно желязо за работа, но официално под минимума за Windows 11. Microsoft иска 8-мо поколение нагоре, а Skylake остава отвън. Windows 10 пък вече е извън поддръжка (октомври 2025, потребителската ESU изтича октомври 2026). Затова изборът беше Windows 11 през Rufus, който заобикаля и хардуерната проверка (TPM, Secure Boot, поколение на процесора), и изискването за Microsoft акаунт наведнъж - чекбоксовете в прозорчето "Windows User Experience".

Но да речем, че флашката не е минала през Rufus bypass и setup опира до задължителен Microsoft акаунт. За 2026 старият трик OOBE\BYPASSNRO вече е блокиран на новите build-ове. Работещият метод сега: на екрана "Нека установим връзка с мрежа" натискаш Shift + F10 и в командния прозорец пишеш:


Code:
start ms-cxh:localonly

Изскача директно създаване на локален акаунт - име, парола (или празна), готово. Оттам setup продължава без акаунт.

Инсталацията мина само на системния SSD, дискът с данните на потребителя остана недокоснат. Windows 11 Pro се активира сам - лицензът е вшит в дъното на машината (цифров лиценз). Състояние на активация: Активен.




От гаража


Няколко неща, които тази случка потвърди за пореден път.

Първо - тъжното синьо лице не е присъда. В деветдесет процента от случаите желязото е здраво, счупен е софтуерът. Провери диска (chkdsk, 0 bad sectors), преди да мислиш за смяна.

Второ - редът е свещен. Данни → диагностика → ремонт → като последен вариант преинсталация. Който започне с Reset, за да "оправи по-бързо", често трие данни, които са били съвсем спасяеми.

Трето - знай кога да спреш с командите. Offline DISM в WinRE е капризен звяр. Двадесет минути опити стигат да разбереш дали ще тръгне. Не му се моли час и половина - флашката е по-бърза и по-надеждна.

И четвърто, за собственика - не дърпай кабела по време на ъпдейт. Цялата тази сага дойде от едно прекъснато писане в регистъра. Едно натискане на бутона в грешния момент, и десет часа ремонт.

Един счупен шев можеш да го запоиш наново. Един счупен ъпдейт - ако извадиш късмет с диска, също. Но и в двата случая по-добре да не се стига дотам.





Ключови думи: 0xc000021a, STATUS_SYSTEM_PROCESS_TERMINATED, WinRE, Windows Recovery, chkdsk, sfc, DISM, RegBack, winlogon, csrss, прекъснат ъпдейт, счупена registry хива, live Linux USB, Parrot OS, спасяване на данни, Rufus, Windows 11 локален акаунт, ms-cxh:localonly, Skylake, чиста инсталация
Източници: Microsoft Learn (Windows 10/11 lifecycle, ESU); практика от гаража


toni@dtgarage:~$ whoami
Тони Ангелчовски | Ексклузивно за DTGaraGe
toni@dtgarage:~$ cat LICENSE
🔒 Копирането и препубликуването без разрешение не е позволено.
toni@dtgarage:~$ ./support.sh
☕ Подкрепи DTGaraGe и независимото техническо съдържание
toni@dtgarage:~$ █
 
Last edited:
Top Bottom
🛡️ Този сайт използва аналитични инструменти за подобряване на потребителското изживяване. Никакви лични данни не се събират. С продължаването си в Потока приемаш тази философия на прозрачност и уважение.