Вулей рэестра Windows пашкоджаны (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 з паведамленнем \Windows\System32\config\SYSTEM is missing or contains errors (Status: 0xc000014c / 0xc0000225) азначае адзін або некалькі асноўных бінарных вулляў рэестра Windows (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) або даныя канфігурацыі загрузкі (BCD) крама была разарвана падчас адключэння электрычнасці, прымусовага адключэння або няўдалага накапляльнага абнаўлення. Што яшчэ горш, калі адміністратары прытрымліваюцца старых онлайн-падручнікаў, якія загадваюць ім адкрыць асяроддзе аднаўлення Windows (WinRE) Камандны радок і скапіруйце файлы рэестра з C:\Windows\System32\config\RegBack\, яны выяўляюць, што ** 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 (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\) выкарыстоўваючы vssadmin list shadows: Нават калі System Restore (rstrui.exe) выходзіць з ладу з памылкай у графічным інтэрфейсе, базавы том 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 -->|"Не: БХД Чысты"| TestReplay["Праверка 2: Тэставанне і паўторнае прайграванне журналаў транзакцый (.LOG1/.LOG2) для кожнага вулля праз рэгулярную загрузку HKLM\\TempHive"]

    TestReplay --> WhichBroken{"Ці паспяховая загрузка рэгістрацыі і чыстае прайграванне .LOG1/.LOG2?"}
    WhichBroken -->|"Так: reg загрузка Паўторны брудны журнал транзакцый -> Выгрузка праз reg unload"| BootFixed["Перазагрузіце ПК: брудны загаловак вулля выпраўлены на месцы з нулявым адкатам"]

    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) і загрузнік (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 Support 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 і .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: Паўтор брудны .LOG1 / .LOG2 з выкарыстаннем журналаў транзакцый hive на месцы 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)¶

Чаму мы здабываем зламаны вулей уручную з ценявой копіі тома, а не націскаем Ліквідацыю непаладак -> Дадатковыя параметры -> Аднаўленне сістэмы у графічным інтэрфейсе? 1. Па-першае, калі SYSTEM або SOFTWARE нечытэльны, графічны System Restore (rstrui.exe) майстар часта выходзіць з ладу 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: Праверце вуллі рэестра ўнутры тома Shadow Copy¶

Таму што стандарт cd або dir каманды часам задыхаюцца \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 шлях прасторы імёнаў ядра, вы можаце альбо перадаць шлях у двукоссі ў dir, або стварыць зручную сімвалічную спасылку (mklink /d) на D:\ паказваючы прама ў ценявую копію:

# 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: Скапіруйце ТОЛЬКІ пашкоджаныя вуллі з ценявой копіі ў 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) або мае менеджэр транзакцый ядра (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 фармат вулля рэестра as 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 Restore Points) паварочваецца 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:` гэта насамрэч жывы запушчаны RAM-дыск WinRE (`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` рэестр аператыўнай памяці ў сістэмнай памяці), ваш рэестр SSD **не** праблема: **аператыўная памяць вашай сістэмы (`DDR4 / DDR5`) пашкоджвае вулей рэестра ў памяці падчас распакавання**. Увядзіце сваю матчыну плату `BIOS / UEFI` ўстаноўка (`Del` або `F2`), адключыць `XMP / EXPO` профілі разгону памяці, каб аператыўная памяць працавала на стандартных хуткасцях JEDEC, або правярайце з адной палкай аператыўнай памяці за раз, выкарыстоўваючы `MemTest86`.

Ці можа старонні антывірус або выяўленне канчатковай кропкі (EDR) абнаўленне драйвера ядра выклікае цыкл BSOD, які выглядае як пашкоджанне рэестра?¶

так. Драйверы бяспекі ў рэжыме ядра (`BOOT_START` кіроўцы с `Start = 0` ўнутры `HKLM\SYSTEM\ControlSet001\Services\`) загружаюцца `winload.efi` побач з `SYSTEM` hive яшчэ да таго, як 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 МБ?¶

У адрозненне ад `SYSTEM`, `SOFTWARE`, `SAM`, `SECURITY`, і `DEFAULT` (якія загружаюцца пры кожнай загрузцы), **`COMPONENTS`** вулей (`C:\Windows\System32\config\COMPONENTS`) дынамічна загружаецца толькі па патрабаванні, калі **Абнаўленне Windows (`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
• 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.): Архітэктура дыспетчара канфігурацыі, двайковая структура вулля рэестра (regf, hbin) і часопіс падвойных транзакцый (.LOG1 / .LOG2) Аднаўленне.
• Дакументацыя па сховішчы Microsoft Server: Служба ценявога капіравання тамоў (VSS) Адміністрацыя (vssadmin list shadows і GLOBALROOT Доступ да прасторы імёнаў прылады).
• Нацыянальны інстытут стандартаў і тэхналогій (NIST) (Злучаныя Штаты): Спецыяльная публікацыя 800-86: Судовы аналіз і аднаўленне рэестра Windows.