Възкресих „мъртъв“ Windows 11 с вградени инструменти, за които 99% от потребителите не подозират

Windows не се счита за толкова гъвкав, колкото Linux, когато става въпрос за корекции и настройки на ниско системно ниво, но може да се изненадате колко мощни всъщност са инструментите за възстановяване, вградени в системата. Наскоро моя приятелка играеше Detroit: Become Human, когато компютърът ѝ внезапно замръзна. След рестартиране тя беше посрещната от грешка „inaccessible boot device“, а последващите рестартирания водеха до екран, изискващ нейния BitLocker ключ. Въвеждането му просто я връщаше обратно в омагьосания кръг на екрана с грешката за зареждане.

Системата, задвижвана от Intel Core i5-14600K и Intel Arc A770, изглеждаше напълно „мъртва“. Автоматичното поправяне при стартиране (Startup repair) не успя да реши проблема, а отказът на Bitlocker да отключи устройството с предоставения ключ ме накара да се опасявам от най-лошото. За щастие, тя пази резервни копия на всички важни данни, но ситуацията изглеждаше странна: как може да се случи това? И дали беше възможно спасението?

Bitlocker влоши лошия сценарий, но не беше реалният проблем

Когато погледнах компютъра сам, първото нещо, което видях, беше екранът за възстановяване на BitLocker. Изтеглих ключа за възстановяване от нейния акаунт в Microsoft, въведох го внимателно и изчаках. Системата се рестартира и отново спря на екрана „inaccessible boot device“, преди да се рестартира отново и да се върне на екрана за ключа. Той приемаше въведените данни, не правеше нищо полезно с тях и зацикляше. В този момент си помислих, че дискът е изгорял, но това нямаше логика – това е Corsair MP700 и почти не е използван, откакто го купих.

Вместо това реших да предприема друг подход: първо да проверя дали дискът изобщо е „жив“. Заредих Clonezilla от Ventoy USB флашка и пуснах ntfsfix, за да проверя дяла. NTFS томът се монтира чисто и самата файлова система изглеждаше непокътната. Тогава ми стана ясно, че самата конфигурация на зареждането (boot configuration) някъде по веригата е повредена.

Какво точно беше повредено обаче оставаше неясно. Първоначално помислих, че е EFI дяла, но не знаех, че сривът е повредил и данните за конфигурация на зареждането, известни като BCD (Boot Configuration Data). На една модерна Windows система последователността на зареждане изглежда така:

1. UEFI фърмуер
2. EFI мениджър на зареждането (boot manager)
3. \EFI\Microsoft\Boot\bootmgfw.efi
4. BCD хранилище (store)
5. winload.efi
6. Инициализация на ядрото (Kernel initialization)
7. Драйвери за стартиране (Boot-start drivers)
8. SYSTEM регистър (hive)
9. Потребителска среда (Userland)

Когато EFI файловете и BCD бяха повредени, средата за зареждане вече не съвпадаше с това, срещу което TPM модулът беше „запечатал“ BitLocker ключа. Това означаваше, че той отказва да освободи ключа за криптиране автоматично. И докато ръчното въвеждане на правилния ключ за възстановяване заобикаля това, то не помагаше, защото нямаше нищо валидно, което реално да се зареди.

С други думи: с декриптирания дял Windows можеше да продължи към winload, но повредените записи в BCD сочеха към грешен път на устройството. Когато ядрото се опита да монтира системния том, то се провали и изхвърли грешка INACCESSIBLE_BOOT_DEVICE. Оказа се, че поправянето само на EFI частта ще реши само половината от проблема.

Командният ред е най-мощният инструмент в Windows Recovery. Повечето хора никога не го отварят

Средата за възстановяване на Windows (Windows Recovery Environment – WinRE) предлага няколко графични опции за поправка, като Startup Repair, System Restore и Reset this PC – именно към тях посягат повечето хора. Нито една от тях не помогна тук. Но скрито под „Advanced Options“ се намира командният ред (Command Prompt) и точно там се крие истинската сила за възстановяване. Знаех, че данните на диска са наред, тъй като ги бях монтирал през Clonezilla, така че си струваше да се опитам да реконструирам последователността на зареждане правилно.

Първо, трябваше да отключа криптирания с BitLocker диск. Едно нещо, което си струва да знаете за WinRE, е, че буквите на устройствата невинаги съвпадат с това, което виждате в нормалния Windows. Вашият диск C: може да се появи като D: или E: в средата за възстановяване. Затова използвах инструмента diskpart, за да изброя томовете и да идентифицирам правилния, преди да правя каквото и да било друго. Оттам изпълних: manage-bde -unlock C: -RecoveryPassword последвано от 48-цифрения ключ, а след това: manage-bde -protectors -disable C:, за да преустановя временно защитата на BitLocker. По този начин можех да работя върху зареждащите файлове, без да бъда блокиран отново по средата на ремонта.

Следващата стъпка беше получаването на достъп до EFI системния дял. Това е малък, скрит FAT32 дял, обикновено около 100 MB, който съдържа Windows Boot Manager и BCD хранилището. По подразбиране той няма буква и WinRE също не му присвоява такава автоматично. Обратно в diskpart избрах диска, изброих томовете, намерих EFI дяла и ръчно му зададох буквата S. Направих това, след като manage-bde беше хвърлил грешка „parameter incorrect“ – принудителното задаване на буква на устройството беше това, което реши проблема.

С достъпен EFI дял на S:, изпълних командата: bcdboot C:\Windows /s S: /f UEFI Тази единствена команда върши цялата тежка работа. Тя копира необходимите файлове за зареждане от инсталацията на Windows към EFI дяла, генерира чисто ново BCD хранилище от вграден шаблон и конфигурира мениджъра на зареждането да сочи към правилния дял на Windows. Само с тази команда цялата верига на зареждане се изгражда наново от нулата. Изпълних bcdedit /enum, за да проверя дали новите записи изглеждат правилно, рестартирах и Windows зареди нормално. Всичко беше непокътнато.

След като се върнах в Windows, активирах отново BitLocker през команден ред с администраторски права с: manage-bde -protectors -enable C:.

Windows има повече инструменти за възстановяване, отколкото си мислите. И Microsoft продължава да добавя нови

Това, което ме порази, не беше самата поправка. А фактът, че тези инструменти – именно bcdboot, bcdedit, manage-bde и diskpart – се доставят с Windows от години… и въпреки това повечето хора не знаят, че съществуват. Първичният инстинкт, когато Windows не иска да зареди, е да се грабне инсталационна флашка и да се започне отначало – и аз го разбирам. Средата за възстановяване не се пребива да рекламира възможностите на своя команден ред. Но тези инструменти могат да ви спасят от изтриване на напълно здрав диск и са много по-способни, отколкото мнозина осъзнават.

Microsoft тихомълком подобрява и самата среда за възстановяване. Windows 11 вече изтегля мрежови драйвери от основната операционна система в WinRE, което означава, че средата за възстановяване всъщност може да се свърже с интернет, без да се налага ръчно да вграждате драйвери първо. Именно това позволява функцията Quick Machine Recovery – функция, директно вдъхновена от инцидента с CrowdStrike през 2024 г., която може автоматично да изтегля целенасочени корекции, когато устройството продължава да не зарежда. Има дори функция за възстановяване към конкретен момент (Point-in-Time Restore) в предварителна версия (preview), която би ви позволила да се върнете към точно предишно състояние на системата, вместо само към най-близката точка за възстановяване.

Разбира се, във всичко това има известна ирония. Собствените актуализации на Microsoft многократно са задействали подкани за възстановяване на BitLocker, подобни на тази, на която попаднах аз. Актуализацията на сигурността от октомври 2025 г. изпрати компютри с процесори Intel в същата последователност (макар че беше еднократно отключване, а не повтарящо се), а придружаваща грешка счупи поддръжката на USB клавиатури в WinRE, което означаваше, че засегнатите потребители дори не можеха да напишат ключа си за възстановяване, за да излязат от ситуацията. Microsoft го поправи в рамките на една седмица, но ако сте били заседнали в този цикъл, без да знаете тези команди, щеше да сте напълно безпомощни. Автоматичната поправка невинаги ще ви спаси и когато тя се провали, командният ред е следващото най-добро нещо.

Онзи компютър сега работи перфектно. Не се наложи преинсталация, не бяха загубени данни и това спести цяла вечер в настройки на всичко от нулата. Инструментите са били там, в самия Windows, през цялото време и се радвам, че се сетих да ги изпробвам първо.