Skip to content

A Windows Registry Hive sérült (BAD_SYSTEM_CONFIG_INFO BSOD): Miért RegBack Üres a Windows 10/11 rendszerben, és hogyan lehet visszaállítani a csalánkiütéseket a VSS árnyékmásolatokból

A segélyhívó számok országonként eltérőek. Ez az oldal a 911-et használja, amely az Egyesült Államokra és Kanadára vonatkozik. Sok más országban a 112-es, 999-es vagy más számokat használják. Keresse meg az országának megfelelő számot.

Látva, hogy a Windows 10, Windows 11 vagy Windows Server gép összeomlik az indítás során a végtelen Blue Screen of Death-be (BSOD) hurok megjelenítése Stop code: BAD_SYSTEM_CONFIG_INFO (0x00000074), CRITICAL_PROCESS_DIED vagy egy fekete Windows Boot Manager képernyő, amelyen a következő felirat látható: \Windows\System32\config\SYSTEM is missing or contains errors (Status: 0xc000014c / 0xc0000225) a Windows egy vagy több alapvető bináris rendszerleíró adatbázisát jelenti (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) vagy a rendszerindítási konfigurációs adatokat (BCD) bolt megszakadt áramszünet, kényszerleállás vagy sikertelen kumulatív frissítés során. Még rosszabb, ha a rendszergazdák régebbi online oktatóanyagokat követnek, amelyek azt mondják nekik, hogy nyissa meg a Windows helyreállítási környezetet (WinRE) Parancssor és másolja ki a rendszerleíró adatbázis biztonsági másolatait a C:\Windows\System32\config\RegBack\, rájönnek, hogy a RegBack mappa teljesen üres (vagy tartalmaz 0-byte fájlok). A Windows 10 1803-as verziójától kezdve és a Windows 11 összes buildjénél a Microsoft végleg letiltotta a RegIdleBackup feladat a lemezterület megtakarítása érdekében. Ne törölje és ne telepítse újra a Windows rendszert: a számítógépe szinte bizonyosan sértetlen, nemrégiben lefoglalt másolatokat tartalmaz minden rendszerleíró adatbázis rejtett Volume Shadow Copy Service (VSS) pillanatképek (HarddiskVolumeShadowCopyN) és tranzakció .LOG1 / .LOG2 folyóiratok, amelyekből 3 perc alatt kinyerhet WinRE. Az általános illesztőprogram- vagy hardveres BSOD-hibaelhárításról lásd: Windows kék képernyő (BSOD) és rendszerindítási javítás; ha BitLocker 48 számjegyű helyreállítási kulcsot kér a Parancssor megnyitása előtt, forduljon hozzá A BitLocker, a FileVault és a LUKS titkosítási helyreállítási kulcsok zárolása és a TPM visszaállítása és SSD és NVMe hirtelen csak olvasható mód és a TRIM letiltása. Ha ez a rendszerhiba letiltja a kórházi klinikai munkaállomásokat, a sürgősségi kiszállítás (CAD), vagy az életbiztonsági vezérlőket, hívja a helyi segélyhívó számot (911 az Egyesült Államokban és Kanadában, 112 az Európai Unió egész területén, 999 az Egyesült Királyságban), vagy tekintse meg címtárunkat segélyhívó számok.

Tedd ezt most

  1. ** NE kattintson a "Számítógép alaphelyzetbe állítása -> Minden eltávolítása" lehetőségre, és NE másoljon vakon 0-byte fájlok ki C:\Windows\System32\config\RegBack\**: Ha futsz copy C:\Windows\System32\config\RegBack\* C:\Windows\System32\config\ Windows 10 (1803+) vagy Windows 11 rendszeren ellenőrzés nélkül dir RegBack először felülírja a részlegesen sérült rendszerleíró adatbázisait 0-byte üres fájlokat, megsemmisítve a megmaradt kaptárakat, és megnehezítve a helyreállítást.
  2. ** Indítsa el a Windows helyreállítási környezetet (WinRE) és nyissa meg Troubleshoot -> Advanced options -> Command Prompt**:
  3. Ha a Windows háromszor egymás után nem indul el, automatikusan elindítja az Automatikus javítás -> Speciális beállítások lehetőséget.
  4. Alternatív megoldásként indítsa el a rendszert bármely Windows 10/11 USB-telepítési adathordozóról, nyomja meg a Shift + F10 (vagy Shift + Fn + F10 laptopokon) közvetlenül a kezdeti nyelvválasztó képernyőn, és egy megemelt X:\Sources> A parancssor azonnal megnyílik, anélkül, hogy a menükre kattintana.
  5. Keresse meg a Windows-partíció valódi meghajtóbetűjelét (diskpart -> list vol), ahogy az lenni szokott D: vagy E: WinRE-n belül NEM C:: A helyreállítási környezetben, C: gyakran hozzá van rendelve a 100 megabájthoz System Reserved vagy Recovery partíciót, miközben a tényleges Windows-telepítés rajta van D: vagy E:. Fuss dir C:\Windows, dir D:\Windows, dir E:\Windows annak ellenőrzésére, hogy melyik meghajtóbetűjelet tartalmazza \Windows\System32\config\.
  6. ** Mindig készítsen biztonsági másolatot a meglévőről (még hibás is) config\ mappába C:\Config_Backup\ ELŐTT egyetlen fájl megérintése**: Futtassa mkdir D:\Config_Backup és xcopy /h /i /c /k /e /r /y D:\Windows\System32\config D:\Config_Backup. Meg kell őriznie mind az öt elsődleges kaptárfájlt (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) és rejtett tranzakciós naplófájljaik (SYSTEM.LOG1, SYSTEM.LOG2, SOFTWARE.LOG1, SOFTWARE.LOG2).
  7. Mielőtt kicseréli a kaptárt, ellenőrizze, hogy nem BCD (Boot Configuration Data) csonkítás vagy egy piszkos kaptár tranzakciós napló (.LOG1 / .LOG2) a valódi oka BAD_SYSTEM_CONFIG_INFO:
  8. In 30% -ból BAD_SYSTEM_CONFIG_INFO A BSOD-ok, a registry hives 100 százalékban rendben vannak és a BCD az üzletben egyszerűen megsérült truncatememory / numproc zászló (msconfig csapda) vagy szükségletek reg load hogy újra lejátssza a .LOG1/.LOG2 tranzakciós napló automatikusan.
  9. Ha SYSTEM vagy SOFTWARE valóban sérült, készítsen egy egészséges másolatot közvetlenül egy VSS árnyékmásolatból (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\) segítségével vssadmin list shadows: Akkor is, amikor System Restore (rstrui.exe) meghiúsul a grafikus felhasználói felület hibája miatt, a mögöttes VSS Shadow Copy kötet létezik a lemezen, és lehetővé teszi a tiszta másolást SYSTEM és SOFTWARE csalánkiütés egyenesen bele \Windows\System32\config\ segítségével copy vagy robocopy.

Danger

Soha ne írd felül SAM vagy SECURITY hónapos biztonsági másolattal, hacsak nem az a két kis fájl 0 bytes vagy sérült: a rendszerleíró adatbázis összeomlásának csaknem 99 százaléka csak SYSTEM (15 MB hogy 30 MB) vagy SOFTWARE (80 MB hogy 150 MB), mert a rendszerindítás és a Windows-frissítések során ez a két kaptár folyamatosan íródik. A SAM (Security Accounts Manager, jellemzően 64 KB hogy 256 KB) és SECURITY csalánkiütések tárolják a helyi felhasználói jelszó kivonatait és a tartománygép fiók megbízható jelszavát ($machine.ACC). Ha felülír egy egészséges SAM és SECURITY kaptár egy 2 hónapos árnyékmásolattal Active Directory tartományhoz csatlakoztatott számítógépen, vagy jelszómódosítás után megszakítja a tartomány bizalmi viszonyát (The trust relationship between this workstation and the primary domain failed), vagy zárolja a legutóbbi helyi jelszómódosításokat. Cserélje ki csak az adott kaptárt (SYSTEM vagy SOFTWARE), amely nem sikerül a reg load teszt a 2. fázisban.


Döntési fa: BAD_SYSTEM_CONFIG_INFO (0x00000074) és 0xc000014c nyilvántartási osztályozás

Használja ezt a folyamatábrát a WinRE Parancssor (Shift + F10), hogy pontosan meghatározza a sérült fájlt, és visszaállítsa a telepített programok vagy felhasználói fiókok elvesztése nélkül:

flowchart TD
    Start["A Windows összeomlik rendszerindításkor: BAD_SYSTEM_CONFIG_INFO (0x74) vagy 0xc000014c"] --> OpenCmd["Indítsa el a WinRE-t vagy a Windows USB-t -> Nyissa meg a parancssort (Shift + F10)"]

    OpenCmd --> FindDrive["Keresse meg a valódi Windows meghajtóbetűjelet (pl. D:) a következővel: diskpart -> list vol -> exit"]
    FindDrive --> BackupFirst["Az aktuális konfigurációs mappa biztonsági mentése (beleértve a rejtett .LOG1/.LOG2 fájlokat is): xcopy /h D:\\Windows\\System32\\config D:\\Config_Orig\\"]

    BackupFirst --> CheckBcd["1. ellenőrzés: Futtassa a bcdedit parancsot -> Valaki beállította a truncatememory-t vagy a numproc-ot az msconfig-ban?"]
    CheckBcd -->|"Igen: csonkamemória vagy rossz érték Jelen"| FixBcd["Run: bcdedit /deletevalue {default} truncatememory AND bcdedit /deletevalue {default} numproc -> Reboot"]

    CheckBcd -->|"Nem: BCD Clean"| TestReplay["2. ellenőrzés: A tranzakciós naplók (.LOG1/.LOG2) tesztelése és újrajátszása minden egyes kaptárhoz a HKLM\\TempHive reg betöltésén keresztül"]

    TestReplay --> WhichBroken{"A reg betölti a sikert, és tisztán lejátssza a .LOG1/.LOG2-t?"}
    WhichBroken -->|"Igen: reg load Replayed Dirty Transaction Log -> Unload via reg unload"| BootFixed["PC újraindítása: A Dirty Hive Header helyben rögzítve nulla visszaállítással"]

    WhichBroken -->|"Nem: A SYSTEM vagy SOFTWARE „A konfigurációs rendszerleíró adatbázis sérült” vagy 0 bájtot ad vissza"| CheckVss["Futtatás: vssadmin lista árnyékai"]

    CheckVss --> HasVss{"Fel vannak tüntetve a kötet árnyékmásolatai (HarddiskVolumeShadowCopy1..N)?"}

    HasVss -->|"Igen: léteznek árnyékmásolatok"| CopyVss["Másolja CSAK a sérült kaptárt (pl. RENDSZER/SZOFTVER) a Legújabb HarddiskVolumeShadowCopyN fájlból a D:\\Windows\\System32\\config\\ mappába"]

    HasVss -->|"Nem: 0 árnyékmásolat szerepel"| CheckAlt["Ellenőrizze az alternatív hive-forrásokat: D:\\Windows\\System32\\config\\TxR\\ VAGY Windows.old VAGY WinSxS komponens kaptárjavítás"]

1. fázis: Miért BAD_SYSTEM_CONFIG_INFO történik és miért RegBack üres a Windows 10/11 rendszerben

Mielőtt bármilyen belső fájlt módosítana \Windows\System32\config\, megértse, mit csinál valójában az öt registry hive fájl, és miért a hagyományos RegBack a módszer már nem működik.

1. Anatómiája \Windows\System32\config\

Amikor a Windows kernel (ntoskrnl.exe) és Boot Loader (winload.efi) inicializálják az indítás során, öt bináris adatbázisfájlt töltenek be (Hives néven, a 4 bájtos ASCII aláírással kezdve regf a 0. bájtnál) innen \Windows\System32\config\:

Registry Hive fájlnév A rendszerleíró adatbázis elérési útja be van szerelve regedit Tipikus egészséges fájlméret Mi történik, ha ez az adott fájl megsérül
SYSTEM HKEY_LOCAL_MACHINE\SYSTEM 15 MB hogy 40 MB (15.7 million hogy 41.9 million bájt) Azonnali rendszerindítási hiba (0xc000014c) vagy BAD_SYSTEM_CONFIG_INFO (0x00000074): winload.efi olvas SYSTEM még mielőtt a kernel elkezdi tudni, mely tároló-illesztőprogramokat (storahci.sys, stornvme.sys), szolgáltatások és ControlSet001 betöltendő hardverparaméterek.
SOFTWARE HKEY_LOCAL_MACHINE\SOFTWARE 80 MB hogy 200 MB (83.8 million hogy 209.7 million bájt) Kissé később összeomlik a rendszerindításkor (BAD_SYSTEM_CONFIG_INFO vagy CRITICAL_PROCESS_DIED közvetlenül a bejelentkezési képernyő előtt) amikor smss.exe / winlogon.exe betölti a Windows osztályokat, házirendeket és a telepített összetevők jegyzékeit.
SAM HKEY_LOCAL_MACHINE\SAM 64 KB hogy 256 KB Helyi felhasználói fiók adatbázis (RID 500 Administrator, helyi felhasználók). Ritkán sérült, hacsak nincs tele a lemez.
SECURITY HKEY_LOCAL_MACHINE\SECURITY 64 KB hogy 512 KB Helyi biztonsági hatóság (LSA) titkokat, BitLocker/DPAPI gépkulcsokat és Active Directory tartományi számítógép megbízhatósági jelszavát. Ritkán sérült.
DEFAULT HKEY_USERS\.DEFAULT 256 KB hogy 2 MB Profilbeállítások a LOCAL SYSTEM (S-1-5-18) bejelentkezés előtti asztal (ahol maga a bejelentkezési képernyő fut).
*.LOG1 & *.LOG2 *(Rejtett rendszerfájlok) Előre írható tranzakciós naplók minden kaptárhoz (SYSTEM.LOG1, SYSTEM.LOG2) 256 KB hogy 8 MB Kritikus: Amikor a Windows módosít egy kaptárt, a módosításokat oda írja .LOG1 / .LOG2 először az alap frissítése előtt regf fejléc (Primary Sequence Number == Secondary Sequence Number).

2. Miért C:\Windows\System32\config\RegBack üres a Windows 10 (1803+) és a Windows 11 rendszerben

Windows XP-től Windows 10 1709-es verzióig egy ütemezett feladat néven \Microsoft\Windows\Registry\RegIdleBackup automatikusan másolt SYSTEM, SOFTWARE, SAM, SECURITY, és DEFAULT be \Windows\System32\config\RegBack\ amikor a rendszer tétlen volt. - Mit változtatott a Microsoft: A Windows 10 1803-as verziójától (2018. május), és a Windows 11 minden kiadásáig a Microsoft hivatalosan letiltotta az automatikus működést. RegBack alapértelmezés szerint a lemezterület csökkentése érdekében (dokumentálva a Microsoft támogatási KB4509719 számában). - Az eredmény: Hacsak nem manuálisan adta hozzá a EnablePeriodicBackup = 1 DWORD to HKLM\System\CurrentControlSet\Control\Session Manager\Configuration Manager mielőtt a számítógép összeomlik, fut dir D:\Windows\System32\config\RegBack megmutatja 0 File(s) (vagy öt ** méretű fájl0 bájt**). - Miért van még mindig biztonsági másolat: Még akkor is RegBack üres, a Windows 10 és a Windows 11 automatikusan létrehozza a Volume Shadow Copy (VSS) pillanatképek a Windows frissítések, az MSI-alkalmazások telepítése, az illesztőprogramok telepítése és a heti visszaállítási ellenőrzőpontok előtt. Minden VSS-pillanatkép tartalmazza a teljes, pont-időben lefagyasztott másolatot \Windows\System32\config\.


2. fázis: Gyors, visszaállítás nélküli javítások (msconfig BCD csapda és .LOG1/.LOG2 Tranzakció visszajátszása)

Csere előtt SYSTEM vagy SOFTWARE árnyékmásolatból, tesztelje ezt a két nulla visszaállítású javítást a WinRE Parancssor (Shift + F10). Az összesnek több mint a fele BAD_SYSTEM_CONFIG_INFO (0x00000074).

1. lépés: Azonosítsa a valódi Windows meghajtó betűjelét (D: vs C:) és vissza config\

A X:\Sources> Parancssor ablak, amelyből megtudhatja, melyik meghajtó betűjele tartalmazza a Windows-telepítést:

diskpart
list volume
exit
Nézd meg a Size és Label oszlopokat, hogy lássa, melyik meghajtóbetűjel (C:, D:, vagy E:) az Ön fő Windows operációs rendszer partíciója (az útmutató további részében a D:; helyettesítse a tényleges meghajtóbetűjelet).

Azonnal készítsen teljes biztonsági másolatot a D:\Windows\System32\config (használva /h olyan rejtett .LOG1 és .LOG2 a tranzakciós fájlokat tartalmazza):

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

2. lépés: A javítás ellenőrzése: Változott valaki Number of processors vagy Maximum memory be msconfig?

A Microsoft hivatalos Bug Check dokumentációja 0x74 (BAD_SYSTEM_CONFIG_INFO) rávilágít egy hírhedt csapdára: a felhasználók megnyitják msconfig -> Indítás -> Speciális beállítások egy rossz "játékoptimalizálási" videót követően ellenőrizze a Number of processors vagy Maximum memory (beállítva 0 vagy rossz érték), és indítsa újra. Az újraindítás után azonnal eléri a Windows végleges állapotát BAD_SYSTEM_CONFIG_INFO BSOD, mielőtt még megérintené a rendszerleíró kaptárakat.

Ellenőrizze a rendszerindítási konfigurációs adatokat (BCD) bolt most:

bcdedit /enum {default}
Nézze meg a kimenet alján truncatememory, numproc vagy removememory. Ha a sorok bármelyike megjelenik, azonnal törölje:
bcdedit /deletevalue {default} truncatememory
bcdedit /deletevalue {default} numproc
bcdedit /deletevalue {default} removememory
Ha ezek az értékek jelen voltak, írja be wpeutil reboot most: a számítógép közvetlenül az asztalra indul.

3. lépés: Ellenőrizze a B javítást: A lejátszás piszkos .LOG1 / .LOG2 kaptár tranzakciós naplók helyben segítségével reg load

Mi van, ha áramszünet történt, miközben a Windows írt SYSTEM vagy 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 |
+-------------------------------------------------------------------------+

Tesztelje mind az öt kaptárt (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) egyesével be WinRE Parancssor használatával reg load:

reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM
- Ha kinyomtatja The operation completed successfully: Ezt nemcsak te bizonyítottad SYSTEM megmenthető, ha SYSTEM koszos volt .LOG1/.LOG2 szekvencia eltérés, reg load csak lejátszotta a tranzakciós naplót, és megjavította a kaptárt a memóriában. Most öblítse vissza a javított fejlécet a lemezre az eltávolítással:
reg unload HKLM\TestSys
- Ismételje meg pontosan ugyanazt a be- és kirakodási tesztet SOFTWARE, SAM, SECURITY, és DEFAULT:
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
- ** Mi van, ha mind az öt reg load / reg unload A parancsok sikeresek voltak?** Ha valamelyikük betöltése 2-3 másodpercig tartott (az újbóli lejátszása .LOG1/.LOG2 napló), majd tisztán ki kell tölteni, próbálja meg újraindítani (wpeutil reboot) most: a piszkos napló újrajátszása ezen keresztül reg load gyakran javít 0xc000014c és BAD_SYSTEM_CONFIG_INFO teljesen. - ** Mi lenne, ha reg load sikertelen SYSTEM vagy SOFTWARE -val ERROR: The configuration registry database is corrupt vagy The file or directory is corrupted and unreadable?** Most már tudja a pontosan eltört kaptárt (e.g., SYSTEM), és tudja, hogy a másik négy csalánkiütés egészséges. Azonnal folytassa a 3. fázissal csak a VSS Shadow Copy törött kaptárának cseréjéhez.


3. fázis: Egészséges anyakönyvi csalánkiütések eltávolítása VSS Árnyékmásolatok (HarddiskVolumeShadowCopyN)

Miért bontjuk ki manuálisan a törött kaptárt egy kötet árnyékmásolatából, ahelyett, hogy a grafikus felhasználói felületen a Hibaelhárítás -> Speciális beállítások -> Rendszer-visszaállítás elemre kattintanánk? 1. Először is, ha SYSTEM vagy SOFTWARE olvashatatlan, a grafikus System Restore (rstrui.exe) varázsló gyakran összeomlik System Restore failed to extract the original copy of the directory from the restore point (0x80070002 / 0x80070017). 2. Másodszor, a grafikus rendszer-visszaállítás lecseréli az összes kaptárt, és több száz illesztőprogram-/végrehajtható fájlt görget vissza a lemezen, miközben csak a sérült fájl másolása. SYSTEM vagy SOFTWARE kaptárból HarddiskVolumeShadowCopyN 10 másodpercig tart, és elhagyja a többi csalánkiütést (SAM, SECURITY) érintetlenül.

1. lépés: Sorolja fel a lemezen található összes elérhető kötet árnyékmásolatát

A WinRE Parancssor, futtassa:

vssadmin list shadows
Tekintse meg az árnyékmásolatok listáját és azok létrehozásának időbélyegeit (Contained 1 shadow copies at creation time: 10/30/2026 11:14:02 PM):
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
Határozza meg a legnagyobb számú (legutóbbi) Shadow Copy Volume az összeomlás megkezdése előtt jött létre (például \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2 vagy HarddiskVolumeShadowCopy1).

2. lépés: Ellenőrizze az árnyékmásolat-köteten belüli beállításjegyzék-szerkezeteket

Mert standard cd vagy dir parancsok néha megfojtják a \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 kernel névtér elérési útja, akkor az elérési utat idézőjelben adhatja át a címnek dir, vagy hozzon létre egy kényelmes szimbolikus linket (mklink /d) bekapcsolva D:\ egyenesen az árnyékmásolatra mutatva:

# 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
Ezt ellenőrizd SYSTEM (-15-35 MB) és SOFTWARE (-80-180 MB) belül D:\ShadowMount\Windows\System32\config egészséges, nullától eltérő fájlmérettel és legutóbbi dátummal rendelkeznek.

3. lépés: Másolja CSAK a sérült kaptár(oka)t az árnyékmásolatból ide D:\Windows\System32\config\

Tegyük fel, hogy a 2. fázis 3. lépésében végzett teszt azt mutatta, hogy SYSTEM nem sikerült betölteni (vagy mindkettő SYSTEM és SOFTWARE nem sikerült).

Warning

** Törölje vagy helyezze át a régit .LOG1 és .LOG2 fájlokat a cserélni kívánt kaptárhoz**: Ha sérült SYSTEM fájl egy egészséges SYSTEM fájlt a tegnapi Shadow Copy-ból, a mait is át kell helyezni vagy törölni kell SYSTEM.LOG1 és SYSTEM.LOG2 fájlok (amelyekre már készített biztonsági másolatot D:\Config_Emergency_Backup a 2. fázis 1. lépésében). Ha elhagyod a mai napot .LOG1 és .LOG2 a tegnapi mellett ülve SYSTEM hive, a Windows megpróbálhatja alkalmazni a mai nem egyező tranzakciós naplót a tegnapi hive-re.

Futtassa pontosan ezeket a parancsokat a törött cseréhez SYSTEM (és/vagy SOFTWARE) kaptár tisztán:

# 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. lépés: Ellenőrizze a visszaállított kaptárterhelések tisztaságát (reg load) és ellenőrizze CurrentControlSet

Tesztelje, hogy az újonnan másolt SYSTEM kaptár betöltése nulla hibával:

reg load HKLM\TestRestored D:\Windows\System32\config\SYSTEM
reg query HKLM\TestRestored\Select
reg unload HKLM\TestRestored
Nézd meg a kimenetet reg query HKLM\TestRestored\Select:
HKEY_LOCAL_MACHINE\TestRestored\Select
    Current    REG_DWORD    0x1
    Default    REG_DWORD    0x1
    Failed     REG_DWORD    0x0
    LastKnownGood    REG_DWORD    0x2
Most írja be wpeutil reboot (vagy zárja be a Parancssort, és kattintson a Tovább a Windows 10/11-re lehetőségre). A számítógép tisztán indul a Windows bejelentkezési képernyőjén.


4. fázis: Mi van, ha vssadmin list shadows Műsorok No items found (0 árnyékmásolat)?

Mi van, ha a rendszervédelem (VSS) teljesen ki volt kapcsolva a meghajtón, RegBack üres, és reg load sikertelen SYSTEM vagy SOFTWARE? Még mindig három tartalék helyreállítási útvonala van a Windows újratelepítése előtt:

1. tartalék: Váltás Default hogy LastKnownGood (ControlSet002) belül SYSTEM

Ha reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM sikeres, és a BSOD (BAD_SYSTEM_CONFIG_INFO) történik, mert egy illesztőprogram vagy szervizkulcs van benne ControlSet001 (Current = 0x1) megsérült, miközben ControlSet002 (LastKnownGood = 0x2) ugyanabban SYSTEM kaptár ép:

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
(Windows 10 és 11 rendszerben nyomja meg a F8 a "Last Known Good Configuration" eltávolítása a rendszerindító menüből, de a Select\Default rendszerleíró mutató benne SYSTEM továbbra is kitüntetéseket ControlSet002 kézi átkapcsoláskor keresztül reg add.)

2. tartalék: Ellenőrizze C:\Windows\System32\config\TxR\ és C:\Windows.old\Windows\System32\config\

Ellenőrizze, hogy a nemrégiben frissített számítógépen van-e (22H2 -> 23H2 -> 24H2) vagy rendelkezik Kernel Tranzakciókezelővel (TxR) konténernaplók:

dir /a D:\Windows.old\Windows\System32\config
dir /a D:\Windows\System32\config\TxR
Ha D:\Windows.old\Windows\System32\config\SYSTEM egy friss Windows szolgáltatásfrissítésből származik, megvizsgálhatja és kimentheti belőle a hardver-/szolgáltatásfákat, vagy visszaállíthatja a szolgáltatásfrissítést (Troubleshoot -> Advanced options -> Uninstall Updates -> Uninstall latest feature update).

3. tartalék: A félig telepített kumulatív frissítés visszaállítása (dism /RevertPendingActions)

Gyakran, BAD_SYSTEM_CONFIG_INFO vagy CRITICAL_PROCESS_DIED akkor fordul elő, mert a számítógép áramszünetben van 30% alatt Working on updates... Don't turn off your computer, távozik SOFTWARE és \Windows\WinSxS\pending.xml nincs szinkronban. A WinRE Parancssor, mondja el a telepítési képfájl szolgáltatásának és kezelésének (DISM) motor az összes nem véglegesített frissítési tranzakció visszaállításához az offline Windows lemezképhez (D:\):

mkdir D:\Scratch
dism /Image:D:\ /Cleanup-Image /RevertPendingActions /ScratchDir:D:\Scratch
Ha dism /RevertPendingActions sikeresen befejeződött, törölje D:\Scratch és indítsa újra.

4. tartalék: Olvashatatlan rendszerindítási konfigurációs adatok javítása (BCD) bolt (bootrec /rebuildbcd és bcdboot)

Mi van, ha mind az öt nyilvántartó kaptár benne van D:\Windows\System32\config\ -val töltse fel és töltse ki tisztán reg load, a PC mégis dob 0xc000014c (The Boot Configuration Data for your PC is missing or contains errors) vagy 0xc000000f? Mert a Windows BCD fájl a rejtett 100 MB FAT32 EFI rendszerpartíció (\EFI\Microsoft\Boot\BCD) pontosan ugyanabban a binárisban van tárolva regf registry hive formátum mint SYSTEM és SOFTWARE, az áramkimaradás megrongálhatja a BCD kaptár távozás közben D:\Windows\System32\config\ érintetlen. Építs újjá egy teljesen újat BCD kaptár az EFI rendszerpartíción 15 másodperc alatt:

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

Tip

Ellenőrizze a lemez SMART állapotát (wmic diskdrive get status) és fájlrendszer (chkdsk D: /f) biztonsági mentés után: A rendszerleíró adatbázisok nem korrumpálják magukat a semmiből, hacsak nem szakították meg az áramellátást írás közben, a RAM-ban instabil XMP/EXPO-túlhúzás van, vagy az SSD/HDD-n hibás szektorok fejlődtek ki. \Windows\System32\config\. Miután biztonsági másolatot készített D:\Config_Emergency_Backup (és lemásolta a kritikus felhasználói dokumentumokat D:\Users\ USB-meghajtóra), futtassa chkdsk D: /f WinRE-ben, mielőtt újraindul a Windows rendszerbe.


5. fázis: Automatikus újraengedélyezés RegBack biztonsági mentések Windows 10 és Windows 11 rendszerben

Miután a Windows PC újra az asztalra került, engedélyezze újra a Microsoft beépített funkcióját RegIdleBackup feladat úgy C:\Windows\System32\config\RegBack\ minden héten automatikusan feltöltődik, és ellenőrizze a rendszer-visszaállítást (VSS) aktív:

  • Az automatikus engedélyezés újra RegBack hive biztonsági mentések Windows 10 (1803+) és Windows 11 rendszerben: Nyisson meg egy emelt szintű parancssort (Run as Administrator) és futtassa ezt az egyetlen hivatalos registry parancsot (KB4509719):
    reg add "HKLM\System\CurrentControlSet\Control\Session Manager\Configuration Manager" /v EnablePeriodicBackup /t REG_DWORD /d 1 /f
    
    Ezután azonnal indítsa el a biztonsági mentési feladatot az ellenőrzéshez C:\Windows\System32\config\RegBack megtelik mind az öt kaptár egészséges másolataival:
    schtasks /run /tn "\Microsoft\Windows\Registry\RegIdleBackup"
    dir C:\Windows\System32\config\RegBack
    
  • A rendszervédelem ellenőrzése (VSS Visszaállítási pontok) be van kapcsolva ON számára C:: Nyomja meg a Win + R, típus sysdm.cpl ,4, válassza ki a sajátját C: meghajtót, kattintson a Konfigurálás elemre, válassza a Rendszervédelem bekapcsolása lehetőséget, és állítsa a Max. használat értékre 5% (10 GB hogy 25 GB), majd kattintson a Létrehozás gombra, hogy azonnal készítsen tiszta alapvonal-árnyékmásolatot.
  • Fuss sfc /scannow és DISM /Online /Cleanup-Image /RestoreHealth ha egyszer elindult a Windows rendszerbe, hogy ellenőrizze, nincsenek rendszer DLL-ek vagy komponenstároló jegyzékek (COMPONENTS kaptár) megsérültek az ütközés során.

Regionális segélyhívó számok és ügynökségi protokollok

Míg egy Windows BAD_SYSTEM_CONFIG_INFO A BSOD általában belső informatikai vagy személyi számítógép-javítási probléma, a kórházakat, a segélyszolgálatot vagy a nyilvános infrastruktúrát érintő munkaállomás- vagy szerverhibák azonnali eszkalációt igényelnek:

  • Egyesült Államok és Kanada: Tárcsázza 911 ha a Windows összeomlása letiltja a klinikai betegfigyelést, a sürgősségi kiszállítást (CAD), vagy az életbiztonsági vezérlőket, és váltson át a létesítmény leállási eljárására. Jelentse a biztonsági ügynök frissítései vagy számítógépes incidensek által okozott széles körben elterjedt vállalati rendszerindítási ciklusokat a CISA-nak (1-844-Say-CISA / cisa.gov/report) vagy a Canadian Center for Cyber Security (1-833-CYBER-88).
  • Egyesült Királyság: Tárcsázza 999 életveszély vagy akut NHS klinikai zavarok esetén. Jelentse a fontosabb kiber- vagy rendelkezésre állási incidenseket az NCSC-nek (ncsc.gov.uk) vagy az NHS England Cyber Operations.
  • Európai Unió: Tárcsázza 112 az EU összes tagállamában. A NIS2 irányelv hatálya alá tartozó entitásoknak 24 órán belül jelenteniük kell a jelentős működési kieséseket nemzeti CSIRT-jüknek.
  • Ausztrália és Új-Zéland: Tárcsázza 000 Ausztráliában vagy 111 Új-Zélandon; jelentse a kritikus infrastrukturális eseményeket az ACSC-nek (1300 CYBER1).
  • India és Ázsia-csendes-óceáni térség: Tárcsázza 112 Indiában katasztrófaelhárításra; jelentse az infrastrukturális vagy kiberincidenseket a CERT-Innek (incident@cert-in.org.in).

Gyakran ismételt kérdések

Mi van, ha a felhasználói profilom nem jelentkezik be a rendszerindítás után ("We can't sign in to your account" / Ideiglenes Profil) mert NTUSER.DAT sérült?

Amellett, hogy az öt rendszer kaptár belsejében `\Windows\System32\config\`, minden egyéni felhasználói fióknak saját rendszerleíró adatbázisa van (`HKEY_CURRENT_USER`) tárolva **`C:\Users\\NTUSER.DAT`** (plusz `AppData\Local\Microsoft\Windows\UsrClass.dat`). Ha a számítógép jól indul a bejelentkezési képernyőn, de a bejelentkezés egy üres ideiglenes asztalt tölt be, mert `NTUSER.DAT` áramszünet során megsérült, nyisson meg emelt szintű parancssort, futtassa `vssadmin list shadows`, és másolja az egészséges `NTUSER.DAT` ki `\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\\NTUSER.DAT` (miközben bejelentkezett egy második rendszergazdai fiókba vagy a WinRE-be, így a fájl nincs zárolva).

Miért tette WinRE kérjen egy 48 számjegyű BitLocker helyreállítási kulcsot, mielőtt engedélyezte volna a Parancssor megnyitását, amikor soha nem kapcsoltam be magamon a BitLockert?

Szinte minden modern Windows 11 (és Windows 10) laptopon `TPM 2.0` és Modern készenléti módban, ha a kezdeti beállítás során Microsoft-fiókkal bejelentkezik, automatikusan engedélyezi az **Eszköztitkosítást (`BitLocker`)** a háttérben, és feltölti a 48 számjegyű helyreállítási kulcsot Microsoft-fiókjába. Nyitva**`https://aka.ms/myrecoverykey`** okostelefonján jelentkezzen be Microsoft fiókjával (`@outlook.com`, `@hotmail.com`, `@gmail.com`) vagy munkahelyi/iskolai belépési azonosító (`myaccount.microsoft.com`) használja az adott számítógépen, és adja meg a 48 számjegyű kulcsot, amely megfelel a `Key ID` képernyőn látható. Miután feloldotta, `D:\Windows\System32\config` teljesen elérhető a WinRE parancssorban.

Mi van ha copy nem sikerül The process cannot access the file because it is being used by another process amikor megpróbálom felülírni SYSTEM vagy SOFTWARE WinRE-ben?

Ez a hiba két okból következik be: (1) véletlenül gépelt be `C:\Windows\System32\config\SYSTEM` mikor `C:` vagy `X:` valójában az élőben futó WinRE RAM lemez (`X:\Windows\System32\config\SYSTEM` maga a WinRE zárolja; mindig ellenőrizze a valódi offline SSD-meghajtó betűjelét `D:` vagy `E:` -val `diskpart -> list vol`); vagy (2) elfutottál `reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM` korábban a munkamenetben, és elfelejtettem futtatni **`reg unload HKLM\TestSys`** futás előtt `copy`.

Miért omlik össze a számítógépem BAD_SYSTEM_CONFIG_INFO (0x00000074) akár vadonatúj Windows USB-telepítőn is, mielőtt hozzáér az SSD-hez?

Ha `BAD_SYSTEM_CONFIG_INFO` (`0x00000074`) egy **vadonatúj Windows 10/11 USB telepítőkártya** indításakor fordul elő (ahol a telepítő a sajátját tölti be `boot.wim` RAM rendszerleíró adatbázis a rendszermemóriába), az SSD beállításjegyzéke **nem** a probléma: **a rendszer RAM (`DDR4 / DDR5`) megsérti a rendszerleíró adatbázist a memóriában, miközben kicsomagolja**. Adja meg az alaplapját `BIOS / UEFI` beállítás (`Del` vagy `F2`), tiltsa le `XMP / EXPO` memória túlhúzási profilokat, hogy a RAM szabványos JEDEC sebességgel fusson, vagy tesztelje egyszerre egy RAM-mal `MemTest86`.

Képes-e harmadik féltől származó víruskereső vagy végpontészlelés (EDR) a kernel-illesztőprogram frissítése BSOD hurkot okoz, ami úgy néz ki, mint a rendszerleíró adatbázis sérülése?

Igen. Kernel módú biztonsági illesztőprogramok (`BOOT_START` járművezetők `Start = 0` belül `HKLM\SYSTEM\ControlSet001\Services\`) tölti be `winload.efi` mellett a `SYSTEM` hive, mielőtt a Windows még inicializálná a videót. Ha hibás `.sys` fájl be `D:\Windows\System32\drivers\` rendszerindításkor összeomlik, még a rendszerleíró adatbázist sem kell cserélnie: egyszerűen nevezze át a problémát `.sys` fájl be `D:\Windows\System32\drivers\` (vagy betölt `D:\Windows\System32\config\SYSTEM` -val `reg load HKLM\TestSys` és cserélje ki a meghibásodott szolgáltatást `Start` értéktől `0` hogy `4` [Letiltva]).

Mi az a COMPONENTS kaptár belsejében C:\Windows\System32\config\, és miért 100 MB?

Ellentétben `SYSTEM`, `SOFTWARE`, `SAM`, `SECURITY`, és `DEFAULT` (amelyek minden rendszerindításkor betöltődnek), a **`COMPONENTS`** kaptár (`C:\Windows\System32\config\COMPONENTS`) csak akkor töltődik be dinamikusan, ha a **Windows Update (`TiWorker.exe` / Alkatrész-alapú szervizelés)** ill `sfc /scannow` fut. Egy sérült `COMPONENTS` A hive **soha** nem akadályozza meg a Windows rendszerindítását (`0x00000074`), bár ez a Windows frissítések sikertelenségét okozza `0x80073712` vel megjavításig `DISM /Online /Cleanup-Image /RestoreHealth`.


Kapcsolódó útmutatók


Források és hivatalos útmutatás

  • Microsoft Learn (learn.microsoft.com): Hibaellenőrzés 0x74: BAD_SYSTEM_CONFIG_INFO Hivatalos hibaelhárítási referencia (BCD truncatememory / numproc Kármentesítés és nyilvántartó kaptár ellenőrzése).
  • Microsoft támogatás (KB4509719): A rendszerleíró adatbázisról már nincs biztonsági másolat a RegBack a Windows 10 1803-as verziójával kezdődő mappa (EnablePeriodicBackup Registry Configuration).
  • Microsoft Windows Internals (7. kiadás, Russinovich et al.): Configuration Manager architektúra, Registry Hive bináris szerkezet (regf, hbin), és a kettős tranzakciós napló (.LOG1 / .LOG2) Helyreállítás.
  • Microsoft Server tárolási dokumentáció: * Kötet árnyékmásolási szolgáltatás (VSS) Adminisztráció (vssadmin list shadows és GLOBALROOT Eszköz névtér hozzáférés)*.
  • Nemzeti Szabványügyi és Technológiai Intézet (NIST) (Egyesült Államok): Különleges kiadvány 800-86: Windows Registry Forensic Analysis and Recovery.