Nasira ang Windows Registry Hive (BAD_SYSTEM_CONFIG_INFO BSOD): Bakit RegBack Walang laman sa Windows 10/11 at Paano I-restore ang Mga Pantal mula sa VSS Shadow Copies¶

Nakakakita ng Windows 10, Windows 11, o Windows Server machine crash sa panahon ng startup sa isang walang katapusang Blue Screen of Death (BSOD) pagpapakita ng loop Stop code: BAD_SYSTEM_CONFIG_INFO (0x00000074), CRITICAL_PROCESS_DIED, o isang itim na screen ng Windows Boot Manager na nagsasabi \Windows\System32\config\SYSTEM is missing or contains errors (Status: 0xc000014c / 0xc0000225) ay nangangahulugang isa o higit pa sa Windows' core binary registry hives (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) o ang Boot Configuration Data (BCD) tindahan ay napunit sa panahon ng pagkawala ng kuryente, sapilitang pagsasara, o nabigong pinagsama-samang pag-update. Mas masahol pa, kapag sinusunod ng mga administrator ang mas lumang mga online na tutorial na nagsasabi sa kanila na buksan ang Windows Recovery Environment (WinRE) Command Prompt at kopyahin ang mga backup na registry file mula sa C:\Windows\System32\config\RegBack\, natuklasan nila na ang RegBack ang folder ay ganap na walang laman (o naglalaman ng 0-byte mga file). Simula sa Windows 10 na bersyon 1803 at sa lahat ng build ng Windows 11, permanenteng hindi pinagana ng Microsoft ang RegIdleBackup gawain upang makatipid ng espasyo sa disk. Huwag punasan at muling i-install ang Windows: ang iyong PC ay halos tiyak na nagtataglay ng buo, kamakailang ginawang mga kopya ng bawat registry hive sa loob ng nakatago Volume Shadow Copy Service (VSS) mga snapshot (HarddiskVolumeShadowCopyN) at transaksyon .LOG1 / .LOG2 mga journal na maaari mong kunin sa loob ng 3 minuto mula sa WinRE. Para sa pangkalahatang pag-troubleshoot ng BSOD ng driver o hardware, tingnan ang Windows blue screen (BSOD) at pag-aayos ng boot; kung BitLocker humihingi ng 48-digit na recovery key bago buksan ang Command Prompt, kumonsulta BitLocker, FileVault, at LUKS encryption recovery key lockout at TPM reset at SSD at NVMe sudden read-only mode at TRIM disabled rescue. Kung hindi pinapagana ng pagkabigo ng system na ito ang mga klinikal na workstation ng ospital, pagpapadala ng emergency (CAD), o mga kontrol sa kaligtasan sa buhay, tawagan ang iyong lokal na numero ng emergency (911 sa Estados Unidos at Canada, 112 sa buong European Union, 999 sa United Kingdom) o tingnan ang aming direktoryo ng mga numerong pang-emergency.

Gawin ito ngayon¶

1. HUWAG i-click ang "I-reset ang PC na ito -> Alisin ang lahat" o bulag na kopyahin 0-byte mga file sa labas ng C:\Windows\System32\config\RegBack\: Kung tatakbo ka copy C:\Windows\System32\config\RegBack\* C:\Windows\System32\config\ sa Windows 10 (1803+) o Windows 11 nang hindi sinusuri dir RegBack una, papatungan mo ang iyong bahagyang nasira na mga pantal sa pagpapatala 0-byte walang laman na mga file, sinisira ang natitirang mga pantal at ginagawang mas mahirap ang pagbawi.
2. Mag-boot sa Windows Recovery Environment (WinRE) at buksan Troubleshoot -> Advanced options -> Command Prompt:
3. Kung nabigo ang Windows na mag-boot nang tatlong beses nang sunud-sunod, awtomatiko nitong ilulunsad ang Awtomatikong Pag-aayos -> Mga Advanced na opsyon.
4. Bilang kahalili, mag-boot mula sa alinmang Windows 10 / 11 USB Installation Media, pindutin ang Shift + F10 (o Shift + Fn + F10 sa mga laptop) sa unang screen ng pagpili ng wika, at isang nakataas X:\Sources> Bubukas kaagad ang Command Prompt nang hindi nagki-click sa mga menu.
5. Hanapin ang totoong drive letter ng iyong Windows partition (diskpart -> list vol), gaya ng madalas D: o E: sa loob ng WinRE, HINDI C:: Sa loob ng kapaligiran sa pagbawi, C: ay madalas na nakatalaga sa 100 megabyte System Reserved o Recovery partition habang nakaupo ang iyong aktwal na pag-install ng Windows D: o E:. Takbo dir C:\Windows, dir D:\Windows, dir E:\Windows upang kumpirmahin kung aling drive letter ang naglalaman \Windows\System32\config\.
6. Palaging i-back up ang iyong umiiral na (kahit sira) config\ folder sa C:\Config_Backup\ BAGO hawakan ang isang file: Patakbuhin mkdir D:\Config_Backup at xcopy /h /i /c /k /e /r /y D:\Windows\System32\config D:\Config_Backup. Dapat mong panatilihin ang parehong limang pangunahing mga file ng pugad (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) at ang kanilang mga nakatagong file ng log ng transaksyon (SYSTEM.LOG1, SYSTEM.LOG2, SOFTWARE.LOG1, SOFTWARE.LOG2).
7. Bago palitan ang anumang pugad, subukan kung BCD (Boot Configuration Data) truncation o isang maruming log ng transaksyon sa pugad (.LOG1 / .LOG2) ang tunay na dahilan ng BAD_SYSTEM_CONFIG_INFO:
8. Sa 30% ng BAD_SYSTEM_CONFIG_INFO Mga BSOD, ang mga pantal sa pagpapatala ay 100 porsiyentong multa at ang BCD store lang ay may sira truncatememory / numproc bandila (msconfig bitag) o mga pangangailangan reg load upang i-replay ang .LOG1/.LOG2 awtomatikong log ng transaksyon.
9. Kung SYSTEM o SOFTWARE ay tunay na sira, kunin ang isang malusog na kopya nang direkta mula sa isang VSS Shadow Copy (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\) gamit vssadmin list shadows: Kahit kailan System Restore (rstrui.exe) nabigo sa isang error sa GUI, ang pinagbabatayan na dami ng VSS Shadow Copy ay umiiral sa disk at hinahayaan kang kumopya nang malinis SYSTEM at SOFTWARE pantal diretso sa \Windows\System32\config\ gamit copy o robocopy.

Puno ng desisyon: BAD_SYSTEM_CONFIG_INFO (0x00000074) at 0xc000014c registry triage¶

Gamitin ang flowchart na ito mula sa WinRE Command Prompt (Shift + F10) upang matukoy ang eksaktong sirang file at ibalik ito nang hindi nawawala ang mga naka-install na program o user account:

flowchart TD
    Start["Nag-crash ang Windows sa Boot: BAD_SYSTEM_CONFIG_INFO (0x74) o 0xc000014c"] --> OpenCmd["Mag-boot sa WinRE o Windows USB -> Buksan ang Command Prompt (Shift + F10)"]

    OpenCmd --> FindDrive["Hanapin ang True Windows Drive Letter (hal. D:) sa pamamagitan ng: diskpart -> list vol -> exit"]
    FindDrive --> BackupFirst["I-back Up ang Kasalukuyang Config Folder (Kabilang ang Nakatagong .LOG1/.LOG2): xcopy /h D:\\Windows\\System32\\config D:\\Config_Orig\\"]

    BackupFirst --> CheckBcd["Suriin 1: Patakbuhin ang bcdedit -> May Nagtakda ba ng truncatememory o numproc sa msconfig?"]
    CheckBcd -->|"Oo: truncatememory o badvalue Present"| FixBcd["Run: bcdedit /deletevalue {default} truncatememory AND bcdedit /deletevalue {default} numproc -> Reboot"]

    CheckBcd -->|"Hindi: BCD Clean"| TestReplay["Check 2: Test & Replay Transaction Logs (.LOG1/.LOG2) para sa Bawat Hive sa pamamagitan ng reg load HKLM\\TempHive"]

    TestReplay --> WhichBroken{"Nagtatagumpay ba ang reg load at Nai-replay nang Malinis ang .LOG1/.LOG2?"}
    WhichBroken -->|"Oo: reg load Na-replay ang Dirty Transaction Log -> I-unload sa pamamagitan ng reg unload"| BootFixed["I-reboot ang PC: In-Place ang Dirty Hive Header na may Zero Rollback"]

    WhichBroken -->|"Hindi: SYSTEM o SOFTWARE Ibinabalik 'Ang configuration registry database ay sira' o Ay 0 Bytes"| CheckVss["Run: vssadmin list shadows"]

    CheckVss --> HasVss{"Nakalista ba ang Mga Volume Shadow Copies (HarddiskVolumeShadowCopy1..N)?"}

    HasVss -->|"Oo: Umiiral ang Mga Shadow Copies"| CopyVss["Kopyahin LAMANG ang Corrupted Hive (hal. SYSTEM / SOFTWARE) mula sa Pinakabagong HarddiskVolumeShadowCopyN sa D:\\Windows\\System32\\config\\"]

    HasVss -->|"Hindi: 0 Shadow Copies na Nakalista"| CheckAlt["Suriin ang Mga Alternatibong Pinagmumulan ng Hive: D:\\Windows\\System32\\config\\TxR\\ O Windows.old O WinSxS Component Hive Repair"]

Phase 1: Bakit BAD_SYSTEM_CONFIG_INFO nangyayari at bakit RegBack ay walang laman sa Windows 10/11¶

Bago baguhin ang anumang mga file sa loob \Windows\System32\config\, unawain kung ano talaga ang ginagawa ng limang registry hive file at bakit ang tradisyonal RegBack hindi na gumagana ang pamamaraan.

1. Anatomy ng \Windows\System32\config\¶

Kapag ang Windows kernel (ntoskrnl.exe) at Boot Loader (winload.efi) sa panahon ng startup, naglo-load sila ng limang binary database file (tinatawag na Hives, simula sa 4-byte na ASCII na lagda regf sa byte 0) mula sa \Windows\System32\config\:

2. Bakit C:\Windows\System32\config\RegBack ay walang laman sa Windows 10 (1803+) at Windows 11¶

Mula sa Windows XP hanggang Windows 10 bersyon 1709, isang naka-iskedyul na gawain na pinangalanan \Microsoft\Windows\Registry\RegIdleBackup awtomatikong kinopya SYSTEM, SOFTWARE, SAM, SECURITY, at DEFAULT sa \Windows\System32\config\RegBack\ sa tuwing idle ang system. - Ano ang binago ng Microsoft: Simula sa Windows 10 na bersyon 1803 (Mayo 2018) at nagpapatuloy sa bawat paglabas ng Windows 11, opisyal na hindi pinagana ng Microsoft ang awtomatikong RegBack populasyon bilang default upang bawasan ang disk footprint (nakadokumento sa Microsoft Support KB4509719). - Ang resulta: Maliban kung manu-mano mong idinagdag ang EnablePeriodicBackup = 1 DWORD sa HKLM\System\CurrentControlSet\Control\Session Manager\Configuration Manager bago nag-crash ang PC mo, tumatakbo dir D:\Windows\System32\config\RegBack magpapakita 0 File(s) (o limang file na may sukat 0 byte). - Bakit may backup ka pa: Kahit na RegBack ay walang laman, awtomatikong gumagawa ang Windows 10 at Windows 11 Volume Shadow Copy (VSS) mga snapshot bago ang Windows Updates, pag-install ng MSI application, pag-install ng driver, at lingguhang restore checkpoint. Ang bawat snapshot ng VSS ay naglalaman ng isang kumpletong, point-in-time na nakapirming kopya ng \Windows\System32\config\.

Phase 2: Mabilis na Non-Rollback na Pag-aayos (msconfig BCD Trap & .LOG1/.LOG2 Replay ng Transaksyon)¶

Bago palitan SYSTEM o SOFTWARE mula sa isang shadow copy, subukan ang dalawang zero-rollback na pag-aayos na ito sa WinRE Command Prompt (Shift + F10). Higit sa kalahati ng lahat BAD_SYSTEM_CONFIG_INFO (0x00000074) naresolba ang mga pag-crash dito mismo sa loob ng 60 segundo nang hindi ibinabalik ang isang setting.

Hakbang 1: Kilalanin ang iyong totoong Windows drive letter (D: vs C:) at i-back up config\¶

Sa X:\Sources> Command Prompt window, hanapin kung aling drive letter ang nagtataglay ng iyong pag-install ng Windows:

diskpart
list volume
exit

Agad na gumawa ng kumpletong backup ng D:\Windows\System32\config (gamit ang /h kaya nakatago .LOG1 at .LOG2 Kasama ang mga file ng transaksyon):

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

Hakbang 2: Suriin ang Pag-aayos A: May nagbago ba Number of processors o Maximum memory sa msconfig?¶

Opisyal na dokumentasyon ng Microsoft para sa Pagsusuri ng Bug 0x74 (BAD_SYSTEM_CONFIG_INFO) ay nagha-highlight ng isang kilalang-kilala na bitag: ang mga user ay nagbubukas msconfig -> Boot -> Mga advanced na pagpipilian kasunod ng isang masamang "pag-optimize ng gaming" na video, tingnan Number of processorso Maximum memory (pagtatakda nito sa 0 o isang masamang halaga), at i-reboot. Kaagad sa pag-reboot, ang Windows ay tumama sa isang permanenteng BAD_SYSTEM_CONFIG_INFO BSOD bago pa man hawakan ang registry hives.

Suriin ang iyong Boot Configuration Data (BCD) tindahan ngayon:

bcdedit /enum {default}

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

Hakbang 3: Suriin ang Ayusin B: I-replay na marumi .LOG1 / .LOG2 mga log ng transaksyon sa pugad sa lugar gamit ang reg load¶

Paano kung naputol ang kuryente habang sinusulatan ang Windows SYSTEM o 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 |
+-------------------------------------------------------------------------+

Subukan ang bawat isa sa limang pantal (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) isa-isa sa WinRE Command Prompt gamit ang 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

Phase 3: Pagkuha ng Healthy Registry Hives mula sa VSS Mga Shadow Copy (HarddiskVolumeShadowCopyN)¶

Bakit namin kinukuha nang manu-mano ang sirang pugad mula sa isang Volume Shadow Copy sa halip na i-click ang Troubleshoot -> Advanced na mga opsyon -> System Restore sa GUI? 1. Una, kung SYSTEM o SOFTWARE ay hindi nababasa, ang graphical System Restore (rstrui.exe) madalas na nagkaka-crash ang wizard System Restore failed to extract the original copy of the directory from the restore point (0x80070002 / 0x80070017). 2. Pangalawa, pinapalitan ng graphical System Restore ang lahat ng mga pantal at ibinabalik ang daan-daang driver/executable file sa buong disk, samantalang ang pagkopya lamang ng solong sira SYSTEM o SOFTWARE pugad mula sa HarddiskVolumeShadowCopyN tumatagal ng 10 segundo at umalis sa iba mo pang mga pantal (SAM, SECURITY) hindi nagalaw.

Hakbang 1: Ilista ang lahat ng available na Volume Shadow Copies sa disk¶

Sa WinRE Command Prompt, patakbuhin:

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

Hakbang 2: I-verify ang registry hives sa loob ng Shadow Copy Volume¶

Dahil standard cd o dir utos minsan sumasakal sa \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 kernel namespace path, maaari mong ipasa ang path sa mga quote sa dir, o lumikha ng isang maginhawang simbolikong link (mklink /d) sa D:\ diretsong tumuturo sa 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

Hakbang 3: Kopyahin LAMANG ang (mga) sira na pugad mula sa Shadow Copy papunta sa D:\Windows\System32\config\¶

Ipagpalagay na ang iyong pagsubok sa Phase 2 Step 3 ay nagpakita na SYSTEM nabigong mag-load (o pareho SYSTEM at SOFTWARE nabigo).

Patakbuhin ang mga eksaktong command na ito upang palitan ang nasira SYSTEM (at/o SOFTWARE) malinis na pugad:

# 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

Hakbang 4: I-verify na malinis na naglo-load ang naibalik na pugad (reg load) at suriin CurrentControlSet¶

Subukan na ang bagong kinopya SYSTEM naglo-load ang mga pugad na walang mga error:

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

Phase 4: Paano kung vssadmin list shadows Mga palabas No items found (0 Shadow Copy)?¶

Paano kung Proteksyon ng System (VSS) ay ganap na naka-off sa drive, RegBack ay walang laman, at reg load nabigo sa SYSTEM o SOFTWARE? Mayroon ka pa ring tatlong fallback recovery path bago muling i-install ang Windows:

Fallback 1: Lumipat Default sa LastKnownGood (ControlSet002) sa loob SYSTEM¶

Kung reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM nagtagumpay, at ang BSOD (BAD_SYSTEM_CONFIG_INFO) ay nangyayari dahil may driver o service key sa loob ControlSet001 (Current = 0x1) ay sira habang ControlSet002 (LastKnownGood = 0x2) sa loob ng pareho SYSTEM buo ang pugad:

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

Fallback 2: Suriin C:\Windows\System32\config\TxR\ at C:\Windows.old\Windows\System32\config\¶

Suriin kung ang PC kamakailang na-upgrade na tampok ay bumubuo (22H2 -> 23H2 -> 24H2) o may Kernel Transaction Manager (TxR) mga log ng lalagyan:

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

Fallback 3: Ibalik ang kalahating naka-install na Cumulative Update (dism /RevertPendingActions)¶

Madalas, BAD_SYSTEM_CONFIG_INFO o CRITICAL_PROCESS_DIED nangyayari dahil nawalan ng kuryente ang PC sa 30% habang Working on updates... Don't turn off your computer, aalis SOFTWARE at \Windows\WinSxS\pending.xml wala sa sync. Mula sa WinRE Command Prompt, sabihin sa Deployment Image Servicing and Management (DISM) engine upang i-revert ang lahat ng hindi nakasaad na mga transaksyon sa pag-update laban sa offline na imahe ng Windows (D:\):

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

Fallback 4: Pag-aayos ng hindi nababasang Boot Configuration Data (BCD) tindahan (bootrec /rebuildbcd at bcdboot)¶

Paano kung lahat ng limang registry hives sa loob D:\Windows\System32\config\ mag-load at magdiskarga nang malinis gamit ang reg load, ngunit ang PC ay nagtatapon pa rin 0xc000014c (The Boot Configuration Data for your PC is missing or contains errors) o 0xc000000f? Dahil ang Windows BCD file sa iyong nakatago 100 MB FAT32 EFI System Partition (\EFI\Microsoft\Boot\BCD) ay mismong nakaimbak sa eksaktong parehong binary regf registry hive format bilang SYSTEM at SOFTWARE, maaaring masira ng pagkawala ng kuryente ang BCD pugad habang umaalis D:\Windows\System32\config\ hindi nagalaw. Buuin muli ang isang bagung-bago BCD pugad sa iyong EFI System Partition sa loob ng 15 segundo:

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

Phase 5: Muling pagpapagana ng awtomatiko RegBack backup sa Windows 10 at Windows 11¶

Kapag ang iyong Windows PC ay bumalik sa desktop, muling paganahin ang built-in ng Microsoft RegIdleBackup gawain kaya C:\Windows\System32\config\RegBack\ ay awtomatikong napupuno bawat linggo, at i-verify ang System Restore (VSS) ay aktibo:

• Muling paganahin ang awtomatiko RegBack mga backup ng hive sa Windows 10 (1803+) at Windows 11: Magbukas ng nakataas na Command Prompt (Run as Administrator) at patakbuhin ang nag-iisang opisyal na utos sa pagpapatala (KB4509719):

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

  Pagkatapos ay i-trigger kaagad ang backup na gawain upang ma-verify C:\Windows\System32\config\RegBack pinupuno ng malusog na mga kopya ng lahat ng limang pantal:

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

• I-verify ang Proteksyon ng System (VSS Restore Points) ay nakabukas ON para sa C:: Pindutin ang Win + R, uri sysdm.cpl ,4, piliin ang iyong C: magmaneho, i-click ang Configure, piliin ang I-on ang proteksyon ng system, itakda ang Max Usage sa 5% (10 GB sa 25 GB), at i-click ang Gumawa upang makagawa ng malinis na baseline shadow copy ngayon din.
• Tumakbo sfc /scannow at DISM /Online /Cleanup-Image /RestoreHealth sa sandaling nag-boot sa Windows upang i-verify na walang mga system DLL o mga manifest store ng component (COMPONENTS pugad) ay nasira sa panahon ng pag-crash.

Mga panrehiyong numero ng emergency at mga protocol ng ahensya¶

Habang isang Windows BAD_SYSTEM_CONFIG_INFO Ang BSOD ay karaniwang isang panloob na isyu sa pag-aayos ng IT o personal na computer, workstation o mga pagkabigo ng server na nakakaapekto sa mga ospital, emergency na dispatch, o pampublikong imprastraktura na nangangailangan ng agarang pagdami:

• Estados Unidos at Canada: I-dial 911 kung hindi pinapagana ng pag-crash ng Windows ang pagsubaybay sa klinikal na pasyente, pagpapadala ng emergency (CAD), o mga kontrol sa kaligtasan sa buhay, at lumipat sa mga pamamaraan ng downtime ng pasilidad. Iulat ang malawakang mga bootloop ng enterprise na dulot ng mga update sa ahente ng seguridad o mga insidente sa cyber sa CISA (1-844-Say-CISA / cisa.gov/report) o ang Canadian Center para sa Cyber Security (1-833-CYBER-88).
• United Kingdom: I-dial 999 para sa mga banta sa buhay o talamak na mga klinikal na pagkagambala sa NHS. Iulat ang mga pangunahing insidente sa cyber o availability sa NCSC (ncsc.gov.uk) o NHS England Cyber Operations.
• European Union: I-dial 112 sa lahat ng estadong miyembro ng EU. Ang mga sakop na entity sa ilalim ng NIS2 Directive ay dapat mag-ulat ng mga makabuluhang pagkawala ng operasyon sa kanilang pambansang CSIRT sa loob ng 24 na oras.
• Australia at New Zealand: I-dial 000 sa Australia o 111 sa New Zealand; mag-ulat ng mga kritikal na insidente sa imprastraktura sa ACSC (1300 CYBER1).
• India at Asia-Pacific: I-dial 112 sa India para sa emergency na pagtugon; iulat ang imprastraktura o mga insidente sa cyber sa CERT-In (incident@cert-in.org.in).

Mga madalas itanong¶

Paano kung ang aking user profile mismo ay nabigo na mag-log in pagkatapos ng boot ("We can't sign in to your account" / Pansamantalang Profile) dahil NTUSER.DAT ay corrupted?¶

Bilang karagdagan sa limang sistema ng pantal sa loob `\Windows\System32\config\`, bawat indibidwal na user account ay may sariling registry hive (`HKEY_CURRENT_USER`) nakaimbak sa **`C:\Users\\NTUSER.DAT`** (plus `AppData\Local\Microsoft\Windows\UsrClass.dat`). Kung ang iyong PC ay nag-boot sa screen ng pag-login, ngunit ang pag-log in ay naglo-load ng isang walang laman na pansamantalang desktop dahil `NTUSER.DAT` ay nasira sa panahon ng pagkawala ng kuryente, buksan ang isang nakataas na Command Prompt, tumakbo `vssadmin list shadows`, at kopyahin ang malusog `NTUSER.DAT` sa labas ng `\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\\NTUSER.DAT` (habang naka-log in sa pangalawang administrator account o WinRE para hindi naka-lock ang file).

Bakit ginawa WinRE humingi ng 48-digit na BitLocker Recovery Key bago ako hayaang magbukas ng Command Prompt, kapag hindi ko kailanman nabuksan ang BitLocker sa aking sarili?¶

Sa halos lahat ng modernong Windows 11 (at Windows 10) na laptop na may `TPM 2.0` at Modern Standby, ang pag-sign in gamit ang isang Microsoft Account sa panahon ng paunang pag-setup ay awtomatikong nagbibigay-daan sa **Device Encryption (`BitLocker`)** sa background at ina-upload ang iyong 48-digit na recovery key sa iyong Microsoft Account. bukas **`https://aka.ms/myrecoverykey`** sa iyong smartphone, mag-sign in gamit ang Microsoft Account (`@outlook.com`, `@hotmail.com`, `@gmail.com`) o Work/School Entra ID (`myaccount.microsoft.com`) na ginamit sa PC na iyon, at ilagay ang 48-digit na key na tumutugma sa `Key ID` ipinapakita sa screen. Kapag na-unlock, `D:\Windows\System32\config` ay ganap na naa-access sa WinRE Command Prompt.

Paano kung copy nabigo sa The process cannot access the file because it is being used by another process kapag sinubukan kong i-overwrite SYSTEM o SOFTWARE sa WinRE?¶

Nangyayari ang error na iyon para sa isa sa dalawang dahilan: (1) hindi mo sinasadyang na-type `C:\Windows\System32\config\SYSTEM` kailan `C:` o `X:` ay talagang ang live na tumatakbong WinRE RAM disk (`X:\Windows\System32\config\SYSTEM` ay naka-lock ng WinRE mismo; palaging i-verify ang iyong tunay na offline na SSD drive letter `D:` o `E:` kasama `diskpart -> list vol`); o (2) tumakbo ka `reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM` mas maaga sa session at nakalimutang tumakbo **`reg unload HKLM\TestSys`** bago tumakbo `copy`.

Bakit nag-crash ang aking PC sa BAD_SYSTEM_CONFIG_INFO (0x00000074) kahit na sa isang bagung-bagong Windows USB installer bago hawakan ang SSD?¶

Kung `BAD_SYSTEM_CONFIG_INFO` (`0x00000074`) ay nangyayari habang nagbo-boot ng **bagong Windows 10/11 USB installer stick** (kung saan ang installer ay naglo-load ng sarili nitong `boot.wim` RAM registry hive sa system memory), ang iyong SSD registry ay **hindi** ang problema: **iyong system RAM (`DDR4 / DDR5`) ay sinisira ang registry hive sa memorya habang binubuksan nito**. Ipasok ang iyong motherboard `BIOS / UEFI` setup (`Del` o `F2`), huwag paganahin `XMP / EXPO` memory overclocking profile upang ang RAM ay tumatakbo sa karaniwang bilis ng JEDEC, o subukan gamit ang isang stick ng RAM sa isang pagkakataon gamit `MemTest86`.

Maaari bang ang isang third-party na Antivirus o Endpoint Detection (EDR) Ang pag-update ng driver ng kernel ay nagdudulot ng BSOD loop na mukhang corruption sa registry?¶

Oo. Mga driver ng seguridad ng kernel-mode (`BOOT_START` mga driver na may `Start = 0` sa loob `HKLM\SYSTEM\ControlSet001\Services\`) ay ni-load ni `winload.efi` sa tabi ng `SYSTEM` pugad bago pa man simulan ng Windows ang video. Kung may depekto `.sys` mag-file sa `D:\Windows\System32\drivers\` nag-crash sa boot, hindi mo na kailangang palitan ang registry hive: palitan lang ang pangalan ng problema `.sys` mag-file sa `D:\Windows\System32\drivers\` (o mag-load `D:\Windows\System32\config\SYSTEM` kasama `reg load HKLM\TestSys` at baguhin ang sirang serbisyo `Start` halaga mula sa `0` sa `4` [Naka-disable]).

Ano ang COMPONENTS pugad sa loob C:\Windows\System32\config\, at bakit ito 100 MB?¶

Unlike `SYSTEM`, `SOFTWARE`, `SAM`, `SECURITY`, at `DEFAULT` (na ikinakarga sa bawat boot), ang **`COMPONENTS`** pugad (`C:\Windows\System32\config\COMPONENTS`) ay dynamic na na-load lamang on-demand kapag **Windows Update (`TiWorker.exe` / Component-Based Servicing)** o `sfc /scannow` tumatakbo. Isang corrupted `COMPONENTS` hive ay **hindi** hihinto sa pag-boot ng Windows (`0x00000074`), bagama't magdudulot ito ng pagkabigo sa Windows Updates `0x80073712` hanggang sa naayos sa `DISM /Online /Cleanup-Image /RestoreHealth`.

Mga kaugnay na gabay¶

• Windows blue screen (BSOD) at pag-aayos ng boot
• BitLocker, FileVault, at LUKS encryption recovery key lockout at TPM reset
• BIOS at UEFI firmware update brick, pagkawala ng kuryente, at Dual-BIOS Flashback
• SSD at NVMe sudden read-only mode, 0% ekstrang block, at TRIM disabled rescue
• Pagkabigo ng hard drive at pagbawi ng data
• Mga pag-backup ng computer, ang 3-2-1 na diskarte, at pagbawi ng kalamidad
• Mga numerong pang-emergency ayon sa bansa

Mga mapagkukunan at opisyal na patnubay¶

• Microsoft Learn (learn.microsoft.com): Pagsusuri ng Bug 0x74: BAD_SYSTEM_CONFIG_INFO Opisyal na Sanggunian sa Pag-troubleshoot (BCD truncatememory / numproc Remediation at Registry Hive Verification).
• Suporta sa Microsoft (KB4509719): Hindi na naka-back up ang system registry sa RegBack folder na nagsisimula sa Windows 10 na bersyon 1803 (EnablePeriodicBackup Registry Configuration).
• Microsoft Windows Internals (7^th Edition, Russinovich et al.): Configuration Manager Architecture, Registry Hive Binary Structure (regf, hbin), at Dual Transaction Log (.LOG1 / .LOG2) Pagbawi.
• Dokumentasyon ng Imbakan ng Microsoft Server: Volume Shadow Copy Service (VSS) Pangangasiwa (vssadmin list shadows at GLOBALROOT Access sa Namespace ng Device).
• National Institute of Standards and Technology (NIST) (United States): Espesyal na Publikasyon 800-86: Pagsusuri at Pagbawi ng Forensic ng Windows Registry.