Windows Registry Hive е повреден (BAD_SYSTEM_CONFIG_INFO BSOD): Защо RegBack Празен ли е в Windows 10/11 и как да възстановите кошерите от VSS сенчести копия¶

Виждате как машина с Windows 10, Windows 11 или Windows Server се срива по време на стартиране в безкраен син екран на смъртта (BSOD) циклично показване Stop code: BAD_SYSTEM_CONFIG_INFO (0x00000074), CRITICAL_PROCESS_DIED или черен екран на Windows Boot Manager, който гласи \Windows\System32\config\SYSTEM is missing or contains errors (Status: 0xc000014c / 0xc0000225) означава един или повече от кошерите на основния двоичен регистър на Windows (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) или Данните за конфигурация на стартиране (BCD) магазинът беше разкъсан по време на прекъсване на захранването, принудително изключване или неуспешна кумулативна актуализация. Още по-лошо, когато администраторите следват по-стари онлайн уроци, които им казват да отворят Windows Recovery Environment (WinRE) Команден ред и копирайте архивни файлове на системния регистър от C:\Windows\System32\config\RegBack\, те откриват, че the RegBack папката е напълно празна (или съдържа 0-byte файлове). Започвайки от Windows 10 версия 1803 и във всички компилации на Windows 11, Microsoft деактивира за постоянно RegIdleBackup задача за спестяване на дисково пространство. Не изтривайте и не инсталирайте отново Windows: вашият компютър почти сигурно държи непокътнати, наскоро регистрирани копия на всеки кошер на системния регистър вътре в скритата Услуга за сенчесто копиране на том (VSS) моментни снимки (HarddiskVolumeShadowCopyN) и транзакция .LOG1 / .LOG2 дневници, от които можете да извлечете за 3 минути WinRE. За общо отстраняване на неизправности с BSOD драйвер или хардуер вижте Син екран на Windows (BSOD) и ремонт на зареждане; ако BitLocker иска 48-цифрен ключ за възстановяване, преди да отвори командния ред, консултирайте се Блокирането на ключа за възстановяване на шифроване на BitLocker, FileVault и LUKS и нулиране на TPM и SSD и NVMe внезапен режим само за четене и спасяване при деактивиране на TRIM. Ако тази повреда на системата деактивира болничните клинични работни станции, спешно изпращане (CAD) или контролите за безопасност на живота, обадете се на местния номер за спешни повиквания (911 в Съединените щати и Канада, 112 в целия Европейски съюз, 999 в Обединеното кралство) или проверете нашия указател на номера за спешни случаи.

Направете това сега¶

1. НЕ кликвайте върху „Нулиране на този компютър -> Премахване на всичко“ или копирайте сляпо 0-byte файлове извън C:\Windows\System32\config\RegBack\: Ако бягате copy C:\Windows\System32\config\RegBack\* C:\Windows\System32\config\ на Windows 10 (1803+) или Windows 11 без проверка dir RegBack първо, ще презапишете вашите частично повредени кошери в регистъра с 0-byte празни файлове, унищожавайки останалите кошери и правейки възстановяването много по-трудно.
2. Стартирайте в средата за възстановяване на Windows (WinRE) и отворете Troubleshoot -> Advanced options -> Command Prompt:
3. Ако Windows не успее да се зареди три пъти подред, той автоматично стартира Автоматична поправка -> Разширени опции.
4. Друга възможност е да стартирате от всеки Windows 10 / 11 USB инсталационен носител, натиснете Shift + F10 (или Shift + Fn + F10 на лаптопи) точно на екрана за първоначален избор на език и повишена X:\Sources> Командният ред се отваря незабавно, без да щракате през менютата.
5. Намерете истинската буква на устройството на вашия Windows дял (diskpart -> list vol), както често се случва D: или E: вътре в WinRE, НЕ C:: В средата за възстановяване, C: често се присвоява на 100 мегабайта System Reserved или Recovery дял, докато действителната ви инсталация на Windows се намира D: или E:. Бягай dir C:\Windows, dir D:\Windows, dir E:\Windows за да потвърдите коя буква на устройството съдържа \Windows\System32\config\.
6. Винаги архивирайте вашите съществуващи (дори повредени) config\ папка към C:\Config_Backup\ ПРЕДИ да докоснете един файл: Стартирайте mkdir D:\Config_Backup и xcopy /h /i /c /k /e /r /y D:\Windows\System32\config D:\Config_Backup. Трябва да запазите и петте първични файла на кошера (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) и техните скрити регистрационни файлове за транзакции (SYSTEM.LOG1, SYSTEM.LOG2, SOFTWARE.LOG1, SOFTWARE.LOG2).
7. Преди да смените който и да е кошер, проверете дали BCD (Boot Configuration Data) отрязване или мръсен регистър на транзакциите на кошера (.LOG1 / .LOG2) е истинската причина за BAD_SYSTEM_CONFIG_INFO:
8. в 30% на BAD_SYSTEM_CONFIG_INFO BSOD, кошерите в регистъра са 100 процента добре и BCD магазинът просто има повреден truncatememory / numproc флаг (msconfig капан) или нужди reg load да преиграете .LOG1/.LOG2 регистър на транзакциите автоматично.
9. Ако SYSTEM или SOFTWARE е наистина повредено, извлечете здраво копие директно от VSS Shadow Copy (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\) използвайки vssadmin list shadows: Дори когато System Restore (rstrui.exe) се проваля с грешка в GUI, основният том на VSS Shadow Copy съществува на диска и ви позволява да копирате чисто SYSTEM и SOFTWARE копривна треска направо в \Windows\System32\config\ използване copy или robocopy.

Дърво на решенията: BAD_SYSTEM_CONFIG_INFO (0x00000074) и 0xc000014c триаж в регистъра¶

Използвайте тази блок-схема от WinRE Команден ред (Shift + F10), за да определите точно повредения файл и да го възстановите, без да губите инсталирани програми или потребителски акаунти:

flowchart TD
    Start["Windows се срива при зареждане: BAD_SYSTEM_CONFIG_INFO (0x74) или 0xc000014c"] --> OpenCmd["Стартирайте в WinRE или Windows USB -> Отворете командния ред (Shift + F10)"]

    OpenCmd --> FindDrive["Намерете истинската буква на Windows устройство (напр. D:) чрез: diskpart -> list vol -> exit"]
    FindDrive --> BackupFirst["Архивирайте текущата конфигурационна папка (включително скритите .LOG1/.LOG2): xcopy /h D:\\Windows\\System32\\config D:\\Config_Orig\\"]

    BackupFirst --> CheckBcd["Проверка 1: Изпълнете bcdedit -> Някой задал ли е truncatememory или numproc в msconfig?"]
    CheckBcd -->|"Да: truncatememory или badvalue Present"| FixBcd["Run: bcdedit /deletevalue {default} truncatememory AND bcdedit /deletevalue {default} numproc -> Reboot"]

    CheckBcd -->|"Не: BCD Clean"| TestReplay["Проверка 2: Тествайте и възпроизвеждайте регистрационни файлове на транзакции (.LOG1/.LOG2) за всеки Hive чрез reg load HKLM\\TempHive"]

    TestReplay --> WhichBroken{"Зареждането на reg Успешно ли е и възпроизвежда ли .LOG1/.LOG2 чисто?"}
    WhichBroken -->|"Да: рег. зареждане. Повторен мръсен регистър на транзакциите -> Разтоварване чрез рег. разтоварване"| BootFixed["Рестартирайте компютъра: Dirty Hive Header е фиксиран на място с нулево връщане назад"]

    WhichBroken -->|"Не: СИСТЕМА или СОФТУЕР Връща „Базата данни на системния регистър е повредена“ или е 0 байта"| CheckVss["Изпълнение: vssadmin списък сенки"]

    CheckVss --> HasVss{"Изброени ли са сенчестите копия на томове (HarddiskVolumeShadowCopy1..N)?"}

    HasVss -->|"Да: съществуват сенчести копия"| CopyVss["Копирайте САМО повредения кошер (напр. СИСТЕМА / СОФТУЕР) от най-новия HarddiskVolumeShadowCopyN в D:\\Windows\\System32\\config\\"]

    HasVss -->|"№: 0 Скрити копия в списъка"| CheckAlt["Проверете алтернативни източници на Hive: D:\\Windows\\System32\\config\\TxR\\ ИЛИ Windows.old ИЛИ WinSxS Component Hive Repair"]

Фаза 1: Защо BAD_SYSTEM_CONFIG_INFO случва и защо RegBack е празен в Windows 10/11¶

Преди да модифицирате каквито и да е файлове вътре \Windows\System32\config\, разберете какво всъщност правят петте файла на системния регистър и защо традиционните RegBack методът вече не работи.

1. Анатомия на \Windows\System32\config\¶

Когато ядрото на Windows (ntoskrnl.exe) и Boot Loader (winload.efi) инициализират по време на стартиране, те зареждат пет двоични файла на базата данни (наречени Hives, започващи с 4-байтовия ASCII подпис regf в байт 0) от \Windows\System32\config\:

2. Защо C:\Windows\System32\config\RegBack е празен в Windows 10 (1803+) и Windows 11¶

От Windows XP до Windows 10 версия 1709, планирана задача с име \Microsoft\Windows\Registry\RegIdleBackup автоматично се копира SYSTEM, SOFTWARE, SAM, SECURITY, и DEFAULT в \Windows\System32\config\RegBack\ когато системата е била неактивна. - Какво промени Microsoft: Започвайки от Windows 10 версия 1803 (май 2018 г.) и продължавайки през всяко издание на Windows 11, Microsoft официално деактивира автоматичното RegBack население по подразбиране, за да се намали дисковият отпечатък (документирано в поддръжката на Microsoft KB4509719). - Резултатът: Освен ако не сте добавили ръчно EnablePeriodicBackup = 1 DWORD към HKLM\System\CurrentControlSet\Control\Session Manager\Configuration Manager преди вашият компютър да се срине, работи dir D:\Windows\System32\config\RegBack ще покаже 0 File(s) (или пет файла с размер 0 байтове). - Защо все още имате резервно копие: Въпреки това RegBack е празен, Windows 10 и Windows 11 автоматично създават Копиране в сянка на том (VSS) моментни снимки преди актуализации на Windows, инсталиране на MSI приложение, инсталиране на драйвери и седмични контролни точки за възстановяване. Всяка моментна снимка на VSS съдържа пълно, замразено копие на момент във времето \Windows\System32\config\.

Фаза 2: Бързи корекции без връщане назад (msconfig BCD Trap & .LOG1/.LOG2 повторение на транзакция)¶

Преди подмяна SYSTEM или SOFTWARE от скрито копие, тествайте тези две корекции за нулево връщане назад в WinRE Команден ред (Shift + F10). Над половината от всички BAD_SYSTEM_CONFIG_INFO (0x00000074) сривовете се разрешават точно тук за по-малко от 60 секунди без връщане назад на нито една настройка.

Стъпка 1: Идентифицирайте вашата истинска буква на Windows устройство (D: срещу C:) и архивирайте config\¶

В X:\Sources> Прозорец на командния ред, намерете коя буква на устройството съдържа вашата инсталация на Windows:

diskpart
list volume
exit

Незабавно направете пълно архивиране на D:\Windows\System32\config (с помощта на /h толкова скрит .LOG1 и .LOG2 са включени файлове за транзакции):

mkdir D:\Config_Emergency_Backup
xcopy /h /i /c /k /e /r /y D:\Windows\System32\config D:\Config_Emergency_Backup

Стъпка 2: Проверете Корекция A: Променил ли е някой Number of processors или Maximum memory в msconfig?¶

Официалната документация на Microsoft за проверка на грешки 0x74 (BAD_SYSTEM_CONFIG_INFO) подчертава известен капан: потребителите отварят msconfig -> Зареждане -> Разширени опции след лошо видео за "оптимизиране на игри", проверете Number of processors или Maximum memory (задаване на 0 или грешна стойност) и рестартирайте. Веднага след рестартиране, Windows удря постоянно BAD_SYSTEM_CONFIG_INFO BSOD, преди дори да докоснете кошерите на системния регистър.

Проверете вашите данни за конфигурация на стартиране (BCD) съхранявайте точно сега:

bcdedit /enum {default}

bcdedit /deletevalue {default} truncatememory
bcdedit /deletevalue {default} numproc
bcdedit /deletevalue {default} removememory

Стъпка 3: Проверете Fix B: Replay dirty .LOG1 / .LOG2 регистрационните файлове на транзакциите на кошера с помощта на място reg load¶

Какво ще стане, ако захранването спре, докато Windows пише SYSTEM или SOFTWARE?

+-------------------------------------------------------------------------+
| HOW WINDOWS REGISTRY HIVE HEADER SEQUENCE NUMBERS WORK                  |
|                                                                         |
| Base Block Header of SYSTEM Hive (First 4,096 bytes: "regf"):           |
|   Offset 0x04: Primary Sequence Number   = 0x0004810A                   |
|   Offset 0x08: Secondary Sequence Number = 0x00048109 (MISMATCH)        |
|                                                                         |
| Why it fails at boot:                                                   |
|   Power died mid-write before Primary == Secondary. The missing         |
|   dirty pages are sitting safely inside SYSTEM.LOG1 / SYSTEM.LOG2.      |
|   If winload.efi cannot reconcile the log at early boot, it throws      |
|   0xc000014c or BAD_SYSTEM_CONFIG_INFO (0x74).                          |
|                                                                         |
| How to force-replay the .LOG1/.LOG2 file in WinRE:                      |
|   Running `reg load HKLM\Temp D:\Windows\System32\config\SYSTEM`        |
|   invokes the full WinRE Configuration Manager, which reads             |
|   SYSTEM.LOG1 + SYSTEM.LOG2, replays the dirty vector pages into        |
|   SYSTEM, sets Primary == Secondary, and flushes a clean hive on unload |
+-------------------------------------------------------------------------+

Тествайте всеки от петте кошера (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) един по един в WinRE Използване на командния ред reg load:

reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM

reg unload HKLM\TestSys

reg load HKLM\TestSoft D:\Windows\System32\config\SOFTWARE
reg unload HKLM\TestSoft

reg load HKLM\TestSam D:\Windows\System32\config\SAM
reg unload HKLM\TestSam

reg load HKLM\TestSec D:\Windows\System32\config\SECURITY
reg unload HKLM\TestSec

reg load HKLM\TestDef D:\Windows\System32\config\DEFAULT
reg unload HKLM\TestDef

Фаза 3: Извличане на здрави кошери в регистъра от VSS Сенчести копия (HarddiskVolumeShadowCopyN)¶

Защо извличаме счупения кошер ръчно от Volume Shadow Copy, вместо да щракнем върху Отстраняване на неизправности -> Разширени опции -> Възстановяване на системата в GUI? 1. Първо, ако SYSTEM или SOFTWARE е нечетлив, графичният System Restore (rstrui.exe) wizard често се срива с System Restore failed to extract the original copy of the directory from the restore point (0x80070002 / 0x80070017). 2. Второ, графичното възстановяване на системата замества всички кошери и връща назад стотици драйвери/изпълними файлове на диска, докато копира само един повреден SYSTEM или SOFTWARE кошер от HarddiskVolumeShadowCopyN отнема 10 секунди и напуска другите ви кошери (SAM, SECURITY) недокоснат.

Стъпка 1: Избройте всички налични сенчести копия на томове на диска¶

В WinRE Команден ред, стартирайте:

vssadmin list shadows

Contents of shadow copy set ID: {4b9128a1-8812-4091-a910-112938475610}
   Contained 1 shadow copies at creation time: 10/30/2026 11:14:02 PM
      Shadow Copy ID: {99182736-1122-3344-5566-77889900aabb}
         Original Volume: (D:)\\?\Volume{12345678-0000-0000-0000-100000000000}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1

Стъпка 2: Проверете кошерите на системния регистър в тома за копиране в сянка¶

Тъй като стандарт cd или dir командите понякога се задушават \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 път на пространство от имена на ядрото, можете или да предадете пътя в кавички на dir, или създайте удобна символна връзка (mklink /d) включено D:\ сочещи право в Shadow Copy:

# Create a folder symlink on D:\ pointing into the newest Shadow Copy (e.g., ShadowCopy1):
mklink /d D:\ShadowMount \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\

# Inspect the file sizes and dates of the registry hives inside that Shadow Copy:
dir D:\ShadowMount\Windows\System32\config

Стъпка 3: Копирайте САМО повредения кошер(и) от Shadow Copy в D:\Windows\System32\config\¶

Да предположим, че вашият тест във фаза 2, стъпка 3 показа, че SYSTEM неуспешно зареждане (или и двете SYSTEM и SOFTWARE неуспешно).

Изпълнете точно тези команди, за да замените повредените SYSTEM (и/или SOFTWARE) кошер чисто:

# 1. Remove the dirty .LOG1 / .LOG2 files for the hive being replaced (already backed up in D:\Config_Emergency_Backup)
attrib -h -s -r D:\Windows\System32\config\SYSTEM.LOG*
del D:\Windows\System32\config\SYSTEM.LOG1
del D:\Windows\System32\config\SYSTEM.LOG2

# 2. Copy the healthy SYSTEM hive from the Shadow Copy into D:\Windows\System32\config\
copy /y D:\ShadowMount\Windows\System32\config\SYSTEM D:\Windows\System32\config\SYSTEM

# (If SOFTWARE was ALSO broken in Phase 2 Step 3, run the same for SOFTWARE:)
attrib -h -s -r D:\Windows\System32\config\SOFTWARE.LOG*
del D:\Windows\System32\config\SOFTWARE.LOG1
del D:\Windows\System32\config\SOFTWARE.LOG2
copy /y D:\ShadowMount\Windows\System32\config\SOFTWARE D:\Windows\System32\config\SOFTWARE

# 3. Clean up the temporary symlink so you don't leave a dangling link on D:\
rmdir D:\ShadowMount

Стъпка 4: Проверете чисто възстановените товари на кошера (reg load) и проверете CurrentControlSet¶

Тествайте, че новокопираният SYSTEM кошерът се зарежда с нула грешки:

reg load HKLM\TestRestored D:\Windows\System32\config\SYSTEM
reg query HKLM\TestRestored\Select
reg unload HKLM\TestRestored

HKEY_LOCAL_MACHINE\TestRestored\Select
    Current    REG_DWORD    0x1
    Default    REG_DWORD    0x1
    Failed     REG_DWORD    0x0
    LastKnownGood    REG_DWORD    0x2

Фаза 4: Ами ако vssadmin list shadows Показва No items found (0 сенчести копия)?¶

Ами ако защита на системата (VSS) беше напълно изключен на устройството, RegBack е празен и reg load се проваля SYSTEM или SOFTWARE? Все още имате три резервни пътя за възстановяване, преди да преинсталирате Windows:

Резервен вариант 1: Превключване Default към LastKnownGood (ControlSet002) вътре SYSTEM¶

Ако reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM успешно и BSOD (BAD_SYSTEM_CONFIG_INFO) се случва, защото драйвер или сервизен ключ вътре ControlSet001 (Current = 0x1) е повреден, докато ControlSet002 (LastKnownGood = 0x2) вътре в същото SYSTEM кошерът е непокътнат:

reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM
reg query HKLM\TestSys\Select
# If ControlSet002 exists (verify via: reg query HKLM\TestSys\ControlSet002), switch Default from 1 to 2:
reg add HKLM\TestSys\Select /v Default /t REG_DWORD /d 2 /f
reg unload HKLM\TestSys

Резервен вариант 2: Проверка C:\Windows\System32\config\TxR\ и C:\Windows.old\Windows\System32\config\¶

Проверете дали компилациите на наскоро надстроената функция на компютъра (22H2 -> 23H2 -> 24H2) или има Kernel Transaction Manager (TxR) контейнерни регистрационни файлове:

dir /a D:\Windows.old\Windows\System32\config
dir /a D:\Windows\System32\config\TxR

Резервен вариант 3: Връщане на полуинсталирана кумулативна актуализация (dism /RevertPendingActions)¶

често, BAD_SYSTEM_CONFIG_INFO или CRITICAL_PROCESS_DIED възниква, защото компютърът е загубил захранване при 30% по време на Working on updates... Don't turn off your computer, напускане SOFTWARE и \Windows\WinSxS\pending.xml извън синхрон. От WinRE Команден ред, кажете на Обслужване и управление на образа за разполагане (DISM) двигател за връщане на всички необвързани транзакции за актуализиране срещу офлайн изображението на Windows (D:\):

mkdir D:\Scratch
dism /Image:D:\ /Cleanup-Image /RevertPendingActions /ScratchDir:D:\Scratch

Резервен вариант 4: Поправяне на нечетливи данни за конфигурация на стартиране (BCD) магазин (bootrec /rebuildbcd и bcdboot)¶

Ами ако всичките пет кошера на регистъра са вътре D:\Windows\System32\config\ товарете и разтоварвайте чисто с reg load, но компютърът все още хвърля 0xc000014c (The Boot Configuration Data for your PC is missing or contains errors) или 0xc000000f? Тъй като Windows BCD файл на вашия скрит 100 MB FAT32 EFI системен дял (\EFI\Microsoft\Boot\BCD) се съхранява в същия двоичен файл regf формат на системния регистър като SYSTEM и SOFTWARE, загубата на мощност може да повреди BCD кошер при напускане D:\Windows\System32\config\ недокоснат. Възстановете чисто нов BCD кошер на вашия EFI системен дял за 15 секунди:

diskpart
list volume
# Find the 100 MB to 300 MB FAT32 EFI System Partition (e.g. Volume 2)
select volume 2
assign letter=S
exit

# Back up the old broken BCD hive and generate a fresh one from D:\Windows:
ren S:\EFI\Microsoft\Boot\BCD BCD.bak
bcdboot D:\Windows /s S: /f UEFI

Фаза 5: Повторно активиране на автоматичното RegBack архивиране в Windows 10 и Windows 11¶

След като вашият компютър с Windows се върне на работния плот, активирайте отново вградения на Microsoft RegIdleBackup задача така C:\Windows\System32\config\RegBack\ се попълва автоматично всяка седмица и проверете възстановяването на системата (VSS) е активен:

• Активирайте отново автоматичното RegBack резервни копия на кошер в Windows 10 (1803+) и Windows 11: Отворете команден ред с повишени права (Run as Administrator) и изпълнете тази единствена официална команда на регистъра (KB4509719):

  reg add "HKLM\System\CurrentControlSet\Control\Session Manager\Configuration Manager" /v EnablePeriodicBackup /t REG_DWORD /d 1 /f
  

  След това веднага задействайте задачата за архивиране веднъж, за да проверите C:\Windows\System32\config\RegBack запълва със здрави копия на всичките пет кошера:

  schtasks /run /tn "\Microsoft\Windows\Registry\RegIdleBackup"
  dir C:\Windows\System32\config\RegBack
  

• Проверете защитата на системата (VSS Точки за възстановяване) се обръща ON за C:: Натиснете Win + R, тип sysdm.cpl ,4, изберете своя C: устройство, щракнете върху Конфигуриране, изберете Включване на защита на системата, задайте Максимално използване на 5% (10 GB към 25 GB) и щракнете върху Създаване, за да направите чисто базово копие в сянка точно сега.
• Бягай sfc /scannow и DISM /Online /Cleanup-Image /RestoreHealth веднъж зареден в Windows, за да проверите дали няма системни DLL файлове или манифести на хранилище на компоненти (COMPONENTS кошер) бяха повредени по време на катастрофата.

Регионални номера за спешни повиквания и протоколи на агенцията¶

Докато Windows BAD_SYSTEM_CONFIG_INFO BSOD обикновено е вътрешен ИТ проблем или проблем с поправка на персонален компютър, повреди на работни станции или сървъри, засягащи болници, спешна помощ или обществена инфраструктура, изискват незабавна ескалация:

• САЩ и Канада: Наберете 911 ако срив на Windows дезактивира клинично наблюдение на пациента, спешно изпращане (CAD), или контроли за безопасност на живота и преминаване към процедури за престой на съоръженията. Докладвайте за широко разпространени корпоративни стартиращи цикли, причинени от актуализации на агенти за сигурност или кибер инциденти на CISA (1-844-Say-CISA / cisa.gov/report) или Канадския център за киберсигурност (1-833-CYBER-88).
• Обединено кралство: Наберете 999 за заплахи за живота или остри клинични смущения на NHS. Докладвайте големи кибер инциденти или инциденти с наличност на NCSC (ncsc.gov.uk) или NHS England Cyber Operations.
• Европейски съюз: Наберете 112 във всички страни членки на ЕС. Обхванатите субекти съгласно Директивата NIS2 трябва да докладват значителни оперативни прекъсвания на своя национален CSIRT в рамките на 24 часа.
• Австралия и Нова Зеландия: Наберете 000 в Австралия или 111 в Нова Зеландия; докладвайте инциденти с критична инфраструктура на ACSC (1300 CYBER1).
• Индия и Азиатско-тихоокеанския регион: Наберете 112 в Индия за спешна реакция; докладвайте инфраструктурни или кибер инциденти на CERT-In (incident@cert-in.org.in).

Често задавани въпроси¶

Ами ако самият ми потребителски профил не успее да влезе след зареждане ("We can't sign in to your account" / Временен профил), защото NTUSER.DAT е повреден?¶

В допълнение към петте системни кошера вътре `\Windows\System32\config\`, всеки индивидуален потребителски акаунт има свой собствен регистър кошер (`HKEY_CURRENT_USER`) съхранявани в **`C:\Users\\NTUSER.DAT`** (плюс `AppData\Local\Microsoft\Windows\UsrClass.dat`). Ако вашият компютър се зарежда на екрана за влизане добре, но влизането зарежда празен временен работен плот, защото `NTUSER.DAT` е бил повреден по време на прекъсване на захранването, отворете повишен команден ред, стартирайте `vssadmin list shadows`, и копирайте здравите `NTUSER.DAT` извън `\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\\NTUSER.DAT` (докато сте влезли във втори администраторски акаунт или WinRE, така че файлът да не е заключен).

Защо WinRE да поискате 48-цифрен ключ за възстановяване на BitLocker, преди да ми позволите да отворя командния ред, когато никога не съм включвал BitLocker?¶

На почти всички модерни лаптопи с Windows 11 (и Windows 10). `TPM 2.0` и Modern Standby, влизането с акаунт в Microsoft по време на първоначалната настройка автоматично активира **Шифроване на устройството (`BitLocker`)** във фонов режим и качва вашия 48-цифрен ключ за възстановяване във вашия акаунт в Microsoft. Отворете **`https://aka.ms/myrecoverykey`** на вашия смартфон влезте с акаунта в Microsoft (`@outlook.com`, `@hotmail.com`, `@gmail.com`) или служебен/училищен входен идентификатор (`myaccount.microsoft.com`), използван на този компютър, и въведете 48-цифрения ключ, съответстващ на `Key ID` показано на екрана. След отключване, `D:\Windows\System32\config` е напълно достъпен в командния ред на WinRE.

Ами ако copy не успява с The process cannot access the file because it is being used by another process когато се опитам да презапиша SYSTEM или SOFTWARE в WinRE?¶

Тази грешка възниква поради една от двете причини: (1) случайно сте въвели `C:\Windows\System32\config\SYSTEM` когато `C:` или `X:` всъщност е работещият на живо WinRE RAM диск (`X:\Windows\System32\config\SYSTEM` се заключва от самия WinRE; винаги проверявайте буквата на вашето реално офлайн SSD устройство `D:` или `E:` с `diskpart -> list vol`); или (2) тичаш `reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM` по-рано в сесията и забравих да стартирам **`reg unload HKLM\TestSys`** преди бягане `copy`.

Защо моят компютър се срива с BAD_SYSTEM_CONFIG_INFO (0x00000074) дори на чисто нов Windows USB инсталатор, преди да докоснете SSD?¶

Ако `BAD_SYSTEM_CONFIG_INFO` (`0x00000074`) възниква при зареждане на **чисто нов USB инсталационен стик на Windows 10/11** (където инсталаторът зарежда собствен `boot.wim` RAM регистър кошер в системната памет), вашият SSD регистър **не** е проблемът: **вашата системна RAM (`DDR4 / DDR5`) поврежда кошера на системния регистър в паметта, докато се разопакова**. Въведете вашата дънна платка `BIOS / UEFI` настройка (`Del` или `F2`), деактивирайте `XMP / EXPO` профили за овърклок на паметта, така че RAM да работи на стандартни JEDEC скорости, или тествайте с една RAM памет наведнъж, като използвате `MemTest86`.

Може ли антивирусна програма на трета страна или откриване на крайна точка (EDR) актуализацията на драйвера на ядрото причинява BSOD цикъл, който изглежда като повреда в системния регистър?¶

да Драйвери за сигурност в режим на ядрото (`BOOT_START` шофьори с `Start = 0` вътре `HKLM\SYSTEM\ControlSet001\Services\`) се зареждат от `winload.efi` заедно с `SYSTEM` кошер, преди Windows дори да инициализира видеото. Ако има дефект `.sys` файл в `D:\Windows\System32\drivers\` се срива при зареждане, дори не е необходимо да заменяте кошера на системния регистър: просто преименувайте проблемния `.sys` файл в `D:\Windows\System32\drivers\` (или заредете `D:\Windows\System32\config\SYSTEM` с `reg load HKLM\TestSys` и сменете повредените услуги `Start` стойност от `0` към `4` [Забранено]).

Какво е COMPONENTS кошер вътре C:\Windows\System32\config\, а защо е 100 MB?¶

За разлика от `SYSTEM`, `SOFTWARE`, `SAM`, `SECURITY`, и `DEFAULT` (които се зареждат при всяко зареждане), **`COMPONENTS`** кошер (`C:\Windows\System32\config\COMPONENTS`) се зарежда динамично само при поискване, когато **Windows Update (`TiWorker.exe` / Обслужване на базата на компоненти)** или `sfc /scannow` бяга. Повреден `COMPONENTS` hive **никога** няма да спре зареждането на Windows (`0x00000074`), въпреки че това ще доведе до неуспешни актуализации на Windows `0x80073712` до ремонт с `DISM /Online /Cleanup-Image /RestoreHealth`.

Свързани ръководства¶

• Син екран на Windows (BSOD) и ремонт на зареждане
• Блокирането на ключа за възстановяване на шифроване на BitLocker, FileVault и LUKS и нулиране на TPM
• Тухла за актуализиране на фърмуера на BIOS и UEFI, загуба на захранване и Dual-BIOS Flashback
• SSD и NVMe внезапен режим само за четене, 0% резервни блокове и дезактивиране на TRIM
• Повреда на твърдия диск и възстановяване на данни
• Компютърни резервни копия, стратегията 3-2-1 и възстановяване след бедствие
• Номера за спешни повиквания по държави

Източници и официални указания¶

• Microsoft Learn (learn.microsoft.com): Проверка за грешки 0x74: BAD_SYSTEM_CONFIG_INFO Официален справочник за отстраняване на неизправности (BCD truncatememory / numproc Поправка и проверка на кошера на регистъра).
• Поддръжка на Microsoft (KB4509719): * Системният регистър вече не се архивира в RegBack папка, започваща в Windows 10 версия 1803 (EnablePeriodicBackup Конфигурация на системния регистър)*.
• Microsoft Windows Internals (7-мо издание, Russinovich et al.): Архитектура на Configuration Manager, двоична структура на Registry Hive (regf, hbin) и регистър на двойните транзакции (.LOG1 / .LOG2) Възстановяване.
• Документация за съхранение на сървър на Microsoft: Услуга за сенчесто копиране на том (VSS) Администрация (vssadmin list shadows и GLOBALROOT Достъп до пространството на имената на устройството).
• Национален институт по стандарти и технологии (NIST) (Съединени щати): Специална публикация 800-86: Криминалистичен анализ и възстановяване на системния регистър на Windows.