Windows Registry Hive ເສຍຫາຍ (BAD_SYSTEM_CONFIG_INFO BSOD): ເປັນຫຍັງ RegBack ຫວ່າງເປົ່າຢູ່ໃນ Windows 10/11 ແລະວິທີການຟື້ນຟູ Hives ຈາກ VSS Shadow Copys¶

ເຫັນເຄື່ອງ Windows 10, Windows 11, ຫຼື Windows Server crash ໃນລະຫວ່າງການເລີ່ມຕົ້ນເຂົ້າໄປໃນຫນ້າຈໍສີຟ້າທີ່ບໍ່ມີສິ້ນສຸດຂອງການເສຍຊີວິດ (BSOD) ການ​ສະ​ແດງ loop Stop code: BAD_SYSTEM_CONFIG_INFO (0x00000074), CRITICAL_PROCESS_DIED, ຫຼືຫນ້າຈໍ Windows Boot Manager ສີດໍາລະບຸ \Windows\System32\config\SYSTEM is missing or contains errors (Status: 0xc000014c / 0xc0000225) ຫມາຍ​ຄວາມ​ວ່າ​ຫນຶ່ງ​ຫຼື​ຫຼາຍ​ຂອງ Windows 'core binary hives ການ​ຈົດ​ທະ​ບຽນ​ຄູ່ (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) ຫຼືຂໍ້ມູນການຕັ້ງຄ່າ Boot (BCD) ຮ້ານຖືກຈີກຂາດໃນລະຫວ່າງການປິດໄຟຟ້າ, ບັງຄັບໃຫ້ປິດເຄື່ອງ ຫຼືການອັບເດດສະສົມທີ່ລົ້ມເຫລວ. ຮ້າຍແຮງໄປກວ່ານັ້ນ, ໃນເວລາທີ່ຜູ້ບໍລິຫານປະຕິບັດຕາມຄໍາແນະນໍາອອນໄລນ໌ເກົ່າແກ່ບອກພວກເຂົາໃຫ້ເປີດ Windows Recovery Environment (WinRE) Command Prompt ແລະຄັດລອກໄຟລ໌ລີຈິດຊີສໍາຮອງອອກຈາກ C:\Windows\System32\config\RegBack\, ພວກເຂົາເຈົ້າຄົ້ນພົບວ່າ ** ໄດ້ RegBack ໂຟນເດີແມ່ນຫວ່າງຫມົດ (ຫຼືປະກອບດ້ວຍ 0-byte ໄຟລ​໌​) ​. ເລີ່ມຕົ້ນໃນ Windows 10 ຮຸ່ນ 1803 ແລະທົ່ວທຸກການກໍ່ສ້າງຂອງ Windows 11, Microsoft ໄດ້ປິດການໃຊ້ງານຢ່າງຖາວອນ. RegIdleBackup ວຽກງານເພື່ອຊ່ວຍປະຢັດພື້ນທີ່ດິດ. ຢ່າເຊັດ ແລະຕິດຕັ້ງ Windows ໃໝ່: PC ຂອງທ່ານເກືອບແນ່ນອນຈະຮັກສາໄວ້ຢ່າງບໍ່ຢຸດຢັ້ງ, ບໍ່ດົນມານີ້ໄດ້ສັນຍາສໍາເນົາຂອງທຸກໆການລົງທະບຽນພາຍໃນທີ່ເຊື່ອງໄວ້ ** Volume Shadow Copy Service (VSS) ພາບ​ຖ່າຍ (HarddiskVolumeShadowCopyN) ແລະ​ການ​ເຮັດ​ທຸ​ລະ​ກໍາ​ .LOG1 / .LOG2 ວາລະສານທີ່ທ່ານສາມາດສະກັດໃນ 3 ນາທີຈາກ WinRE. ສໍາລັບໄດເວີທົ່ວໄປຫຼືການແກ້ໄຂບັນຫາ BSOD ຮາດແວ, ເບິ່ງ Windows blue screen (BSOD) ແລະ boot ການສ້ອມແປງ; ຖ້າ BitLocker ຂໍລະຫັດການຟື້ນຕົວ 48 ຕົວເລກກ່ອນທີ່ຈະເປີດ Command Prompt, ປຶກສາຫາລື BitLocker, FileVault, ແລະ LUKS encryption key recovery lockout and TPM reset ແລະ ໂໝດອ່ານເທົ່ານັ້ນແບບກະທັນຫັນ SSD ແລະ NVMe ແລະ TRIM ປິດໃຊ້ງານການກູ້ຂໍ້ມູນ. ຖ້າຄວາມລົ້ມເຫຼວຂອງລະບົບນີ້ປິດການທໍາງານທາງດ້ານການຊ່ວຍຂອງໂຮງຫມໍ, ການຈັດສົ່ງສຸກເສີນ (CAD), ຫຼືການຄວບຄຸມຄວາມປອດໄພຊີວິດ, ໂທຫາເບີສຸກເສີນທ້ອງຖິ່ນຂອງທ່ານ (911 ໃນສະຫະລັດແລະການາດາ, 112 ໃນ​ທົ່ວ​ສະ​ຫະ​ພາບ​ເອີ​ຣົບ​, 999 ໃນສະຫະລາຊະອານາຈັກ) ຫຼືກວດເບິ່ງລາຍການຂອງພວກເຮົາ ຕົວເລກສຸກເສີນ.

ເຮັດອັນນີ້ດຽວນີ້¶

1. ** ຢ່າ​ຄລິກ​ໃສ່ "ຕັ້ງ PC ນີ້​ຄືນ​ໃຫມ່ -​> ລົບ​ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​" ຫຼື​ສໍາ​ເນົາ blindly​ 0-byte ໄຟລ໌ອອກຈາກ C:\Windows\System32\config\RegBack\**: ຖ້າເຈົ້າແລ່ນ copy C:\Windows\System32\config\RegBack\* C:\Windows\System32\config\ ໃນ Windows 10 (1803+) ຫຼື Windows 11 ໂດຍບໍ່ມີການກວດສອບ dir RegBack ທໍາອິດ, ທ່ານຈະຂຽນທັບ hives ທະບຽນເສຍຫາຍບາງສ່ວນຂອງທ່ານກັບ 0-byte ໄຟລ໌ເປົ່າ, ທໍາລາຍ hives ທີ່ຍັງເຫຼືອແລະເຮັດໃຫ້ການຟື້ນຕົວຫຼາຍ harder.
2. ** ເປີດ​ເຂົ້າ​ໄປ​ໃນ Windows Recovery Environment (WinRE) ແລະ​ເປີດ​ Troubleshoot -> Advanced options -> Command Prompt**:
3. ຖ້າ Windows ລົ້ມເຫລວໃນການບູດສາມຄັ້ງຕິດຕໍ່ກັນ, ມັນຈະເປີດຕົວ ** ການສ້ອມແປງອັດຕະໂນມັດ -> ທາງເລືອກຂັ້ນສູງ **.
4. ອີກທາງເລືອກ, boot ຈາກ ** Windows 10 / 11 USB Installation Media**, ກົດ Shift + F10 (ຫຼື Shift + Fn + F10 ໃນ​ແລັບ​ທັອບ​) ຢູ່​ທີ່​ຫນ້າ​ຈໍ​ການ​ຄັດ​ເລືອກ​ພາ​ສາ​ເບື້ອງ​ຕົ້ນ​, ແລະ​ສູງ​ X:\Sources> Command Prompt ເປີດທັນທີໂດຍບໍ່ຕ້ອງຄລິກຜ່ານເມນູ.
5. ** ຊອກ​ຫາ​ຕົວ​ອັກ​ສອນ​ຂັບ​ທີ່​ແທ້​ຈິງ​ຂອງ​ການ​ແບ່ງ​ປັນ Windows ຂອງ​ທ່ານ (diskpart -> list vol), ຍ້ອນວ່າມັນເປັນເລື້ອຍໆ D: ຫຼື E: ພາຍໃນ WinRE, ບໍ່ແມ່ນ C:**​: ໃນ​ສະ​ພາບ​ແວດ​ລ້ອມ​ການ​ຟື້ນ​ຕົວ​, C: ມັກຈະຖືກມອບຫມາຍໃຫ້ 100 megabyte 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. ທ່ານຕ້ອງຮັກສາທັງຫ້າໄຟລ໌ hive ຕົ້ນຕໍ (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) ** ແລະ ** ໄຟລ໌ບັນທຶກການເຮັດທຸລະກໍາທີ່ເຊື່ອງໄວ້ຂອງພວກເຂົາ (SYSTEM.LOG1, SYSTEM.LOG2, SOFTWARE.LOG1, SOFTWARE.LOG2).
7. ** ກ່ອນ​ທີ່​ຈະ​ທົດ​ແທນ​ການ hive ໃດ​, ທົດ​ສອບ​ວ່າ​ BCD (Boot Configuration Data) ການຕັດຫຼືບັນທຶກການເຮັດທຸລະກໍາທີ່ເປື້ອນ (.LOG1 / .LOG2) ເປັນສາເຫດທີ່ແທ້ຈິງຂອງ BAD_SYSTEM_CONFIG_INFO**:
8. ໃນ 30% ຂອງ BAD_SYSTEM_CONFIG_INFO BSODs, hives ການຈົດທະບຽນແມ່ນ 100 ເປີເຊັນປັບໄຫມແລະໄດ້ BCD ຮ້ານພຽງແຕ່ມີຄວາມເສຍຫາຍ truncatememory / numproc ທຸງ (msconfig trap) ຫຼືຄວາມຕ້ອງການ reg load ເພື່ອ replay ໄດ້ .LOG1/.LOG2 ບັນທຶກການເຮັດທຸລະກໍາອັດຕະໂນມັດ.
9. ** ຖ້າ SYSTEM ຫຼື SOFTWARE ແມ່ນເສຍຫາຍຢ່າງແທ້ຈິງ, ສະກັດສໍາເນົາສຸຂະພາບໂດຍກົງຈາກ VSS Shadow Copy (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\) ການ​ນໍາ​ໃຊ້​ vssadmin list shadows**: ເຖິງ​ແມ່ນ​ວ່າ​ໃນ​ເວ​ລາ​ທີ່ System Restore (rstrui.exe) ລົ້ມເຫລວກັບຄວາມຜິດພາດໃນ GUI, ປະລິມານການຄັດລອກ VSS Shadow ທີ່ຢູ່ເບື້ອງຕົ້ນມີຢູ່ໃນແຜ່ນແລະຊ່ວຍໃຫ້ທ່ານສາມາດຄັດລອກໄດ້ສະອາດ. SYSTEM ແລະ SOFTWARE hives ຊື່ເຂົ້າໄປໃນ \Windows\System32\config\ ການ​ນໍາ​ໃຊ້ copy ຫຼື robocopy.

ຕົ້ນ​ໄມ້​ການ​ຕັດ​ສິນ​ໃຈ​: BAD_SYSTEM_CONFIG_INFO (0x00000074) ແລະ 0xc000014c triage ການ​ຈົດ​ທະ​ບຽນ​¶

ໃຊ້ຕາຕະລາງຂັ້ນຕອນນີ້ຈາກ WinRE Command Prompt (Shift + F10) ເພື່ອກໍານົດໄຟລ໌ທີ່ເສຍຫາຍທີ່ແນ່ນອນແລະຟື້ນຟູມັນໂດຍບໍ່ມີການສູນເສຍໂຄງການທີ່ຕິດຕັ້ງຫຼືບັນຊີຜູ້ໃຊ້:

flowchart TD
    Start["Windows ຂັດຂ້ອງໃນເວລາ Boot: BAD_SYSTEM_CONFIG_INFO (0x74) ຫຼື 0xc000014c"] --> OpenCmd["ບູດເຂົ້າ WinRE ຫຼື Windows USB -> ເປີດ Command Prompt (Shift + F10)"]

    OpenCmd --> FindDrive["ຊອກຫາ True Windows Drive Letter (ເຊັ່ນ: D:) ຜ່ານ: diskpart -> list vol -> exit"]
    FindDrive --> BackupFirst["Back Up ໂຟນເດີ Config ປະຈຸບັນ (ລວມທັງເຊື່ອງ .LOG1/.LOG2): xcopy /h D:\\Windows\\System32\\config D:\\Config_Orig\\"]

    BackupFirst --> CheckBcd["ກວດເບິ່ງ 1: ດໍາເນີນການ bcdedit -> ມີຄົນຕັ້ງ truncatememory ຫຼື numproc ໃນ msconfig ບໍ?"]
    CheckBcd -->|"ແມ່ນ: truncatememory ຫຼື badvalue ປະຈຸບັນ"| FixBcd["Run: bcdedit /deletevalue {default} truncatememory AND bcdedit /deletevalue {default} numproc -> Reboot"]

    CheckBcd -->|"ບໍ່: BCD Clean"| TestReplay["ກວດເບິ່ງ 2: ທົດສອບ & ບັນທຶກການເຮັດທຸລະກໍາຄືນໃໝ່ (.LOG1/.LOG2) ສໍາລັບແຕ່ລະ Hive ຜ່ານ reg load HKLM\\TempHive"]

    TestReplay --> WhichBroken{"ການໂຫຼດ reg ສຳເລັດແລ້ວເປີດ .LOG1/.LOG2 ຄືນໃໝ່ໄດ້ສະອາດບໍ່?"}
    WhichBroken -->|"ແມ່ນແລ້ວ: reg load Replayed Dirty Transaction Log -> Unload via reg unload"| BootFixed["Reboot PC: Dirty Hive Header Fixed in-place with Zero Rollback"]

    WhichBroken -->|"ບໍ່: ລະບົບ ຫຼື SOFTWARE ສົ່ງຄືນ 'ຖານຂໍ້ມູນການລົງທະບຽນການກຳນົດຄ່າເສຍຫາຍ' ຫຼືແມ່ນ 0 Bytes"| CheckVss["ແລ່ນ: ເງົາລາຍຊື່ vssadmin"]

    CheckVss --> HasVss{"ມີບັນທຶກສຽງສໍາເນົາເງົາ (HarddiskVolumeShadowCopy1..N) ບໍ?"}

    HasVss -->|"ແມ່ນແລ້ວ: Shadow Copy ມີຢູ່"| CopyVss["ຄັດລອກພຽງແຕ່ Hive ທີ່ເສຍຫາຍ (ເຊັ່ນ: SYSTEM / SOFTWARE) ຈາກ HarddiskVolumeShadowCopyN ຫລ້າສຸດໄປຫາ D:\\Windows\\System32\\config\\"]

    HasVss -->|"ບໍ່ມີ: 0 Shadow Copys Listed"| CheckAlt["ກວດເບິ່ງແຫຼ່ງ Hive ທາງເລືອກ: D:\\Windows\\System32\\config\\TxR\\ OR Windows.old OR WinSxS Component Hive Repair"]

ໄລຍະທີ 1: ເປັນຫຍັງ BAD_SYSTEM_CONFIG_INFO ເກີດຂຶ້ນແລະເປັນຫຍັງ RegBack ຫວ່າງເປົ່າຢູ່ໃນ Windows 10/11¶

ກ່ອນທີ່ຈະດັດແປງໄຟລ໌ໃດໆພາຍໃນ \Windows\System32\config\, ເຂົ້າໃຈສິ່ງທີ່ຫ້າໄຟລ໌ registry hive ຕົວຈິງເຮັດແລະເປັນຫຍັງປະເພນີ RegBack ວິທີການບໍ່ເຮັດວຽກອີກຕໍ່ໄປ.

1. ການວິພາກວິພາກຂອງ \Windows\System32\config\¶

ເມື່ອ Windows kernel (ntoskrnl.exe) ແລະ Boot Loader (winload.efi) ເລີ່ມຕົ້ນໃນລະຫວ່າງການເລີ່ມຕົ້ນ, ພວກເຂົາໂຫລດຫ້າໄຟລ໌ຖານຂໍ້ມູນສອງ (ເອີ້ນວ່າ Hives, ເລີ່ມຕົ້ນດ້ວຍລາຍເຊັນ ASCII 4-byte. regf at byte 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 * ກ່ອນທີ່ຈະ * PC ຂອງທ່ານ crashed, ແລ່ນ dir D:\Windows\System32\config\RegBack ຈະ​ສະ​ແດງ 0 File(s) (ຫຼື​ຫ້າ​ໄຟລ​໌​ຂະ​ຫນາດ 0 ໄບຕ໌). - ເປັນ​ຫຍັງ​ທ່ານ​ຍັງ​ມີ​ການ​ສໍາ​ຮອງ **​: ເຖິງ​ແມ່ນ​ວ່າ​ RegBack ຫວ່າງເປົ່າ, Windows 10 ແລະ Windows 11 ອັດຕະໂນມັດສ້າງ ** Volumehadow Copy (VSS) ພາບຖ່າຍ ກ່ອນການອັບເດດ Windows, ການຕິດຕັ້ງແອັບພລິເຄຊັນ MSI, ການຕິດຕັ້ງໄດເວີ, ແລະຈຸດກວດຄືນປະຈໍາອາທິດ. ພາບຖ່າຍ VSS ແຕ່ລະອັນມີສຳເນົາທີ່ຈຶ້ງໄວ້ຕາມຈຸດເວລາ \Windows\System32\config\.

ໄລຍະທີ 2: ການແກ້ໄຂໄວທີ່ບໍ່ມ້ວນຄືນ (msconfig BCD ກັບດັກ & .LOG1/.LOG2 ການເຮັດທຸລະກໍາ Replay)¶

ກ່ອນທີ່ຈະປ່ຽນແທນ SYSTEM ຫຼື SOFTWARE ຈາກການຄັດລອກເງົາ, ທົດສອບການແກ້ໄຂສູນ rollback ສອງອັນນີ້ຢູ່ໃນ WinRE Command Prompt (Shift + F10). ຫຼາຍກວ່າເຄິ່ງຫນຶ່ງຂອງທັງຫມົດ BAD_SYSTEM_CONFIG_INFO (0x00000074) ການຂັດຂ້ອງຖືກແກ້ໄຂຢູ່ທີ່ນີ້ພາຍໃນເວລາບໍ່ເກີນ 60 ວິນາທີ ໂດຍບໍ່ຕ້ອງກັບຄືນການຕັ້ງຄ່າດຽວ.

ຂັ້ນ​ຕອນ​ທີ 1​: ການ​ກໍາ​ນົດ​ຕົວ​ອັກ​ສອນ Windows ຂອງ​ທ່ານ drive ທີ່​ແທ້​ຈິງ (D: ທຽບກັບ C:) ແລະ​ສໍາ​ຮອງ​ຂໍ້​ມູນ​ config\¶

ໃນ X:\Sources> ປ່ອງຢ້ຽມ Command Prompt, ຊອກຫາຕົວຫນັງສືໄດທີ່ຖືການຕິດຕັ້ງ 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 ສໍາລັບການກວດສອບ Bug 0x74 (BAD_SYSTEM_CONFIG_INFO) ເນັ້ນໃສ່ກັບດັກທີ່ມີຊື່ສຽງ: ຜູ້ໃຊ້ເປີດ **msconfig -> Boot -> ທາງເລືອກຂັ້ນສູງ ** ປະຕິບັດຕາມວິດີໂອ "ການເພີ່ມປະສິດທິພາບຂອງເກມ" ທີ່ບໍ່ດີ, ໃຫ້ກວດເບິ່ງ Number of processors ຫຼື Maximum memory (ຕັ້ງ​ມັນ​ເປັນ 0 ຫຼືຄ່າທີ່ບໍ່ດີ), ແລະ reboot. ທັນທີທີ່ reboot, Windows hits ເປັນຖາວອນ BAD_SYSTEM_CONFIG_INFO BSOD ກ່ອນທີ່ຈະສໍາຜັດກັບ hives ລີຈິດຊີ.

ກວດເບິ່ງຂໍ້ມູນການຕັ້ງຄ່າ Boot ຂອງທ່ານ (BCD) ເກັບ​ຮັກ​ສາ​ໃນ​ປັດ​ຈຸ​ບັນ​:

bcdedit /enum {default}

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

ຂັ້ນຕອນທີ 3: ກວດເບິ່ງ Fix B: Replay ເປື້ອນ .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 |
+-------------------------------------------------------------------------+

ທົດ​ສອບ​ແຕ່​ລະ​ຫ້າ hives (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) ຫນຶ່ງ​ໂດຍ​ຫນຶ່ງ​ໃນ​ WinRE Command Prompt ໂດຍໃຊ້ 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: ການສະກັດເອົາຮັງສີ Registry ສຸຂະພາບຈາກ VSS ສຳເນົາເງົາ (HarddiskVolumeShadowCopyN)¶

ເປັນ​ຫຍັງ​ພວກ​ເຮົາ​ຈຶ່ງ​ເອົາ​ຮັງ​ທີ່​ແຕກ​ຫັກ​ອອກ​ດ້ວຍ​ຕົນ​ເອງ​ຈາກ Volume Shadow Copy ແທນ​ທີ່​ຈະ​ເປັນ​ການ​ຄລິກ ການ​ແກ້​ໄຂ​ບັນ​ຫາ -> ທາງ​ເລືອກ​ຂັ້ນ​ສູງ -> System Restore ໃນ GUI? 1. ທໍາອິດ, ຖ້າ SYSTEM ຫຼື SOFTWARE ແມ່ນບໍ່ສາມາດອ່ານໄດ້, ຮູບພາບ System Restore (rstrui.exe) ຂອງຄວາມຍາວປາມັກຈະ crash ກັບ System Restore failed to extract the original copy of the directory from the restore point (0x80070002 / 0x80070017). 2. ອັນທີສອງ, ການຟື້ນຟູລະບົບກາຟິກແທນທີ່ * ທັງຫມົດ * hives ແລະ rolls ກັບຫຼາຍຮ້ອຍຄົນຂອງໄດເວີ / ປະຕິບັດການໄຟລ໌ໃນທົ່ວແຜ່ນ, ໃນຂະນະທີ່ການຄັດລອກພຽງແຕ່ຫນຶ່ງເສຍຫາຍ. SYSTEM ຫຼື SOFTWARE hive ຈາກ HarddiskVolumeShadowCopyN ໃຊ້​ເວ​ລາ 10 ວິ​ນາ​ທີ​ແລະ​ປະ​ໄວ້ hives ອື່ນໆ​ຂອງ​ທ່ານ (SAM, SECURITY) ບໍ່​ໄດ້​ສໍາ​ພັດ​.

ຂັ້ນ​ຕອນ​ທີ 1​: ບັນ​ຊີ​ລາຍ​ຊື່​ການ​ສໍາ​ເນົາ Shadow ປະ​ລິ​ມານ​ທັງ​ຫມົດ​ທີ່​ມີ​ຢູ່​ໃນ​ແຜ່ນ​ໄດ້​¶

ໃນ WinRE Command Prompt, ແລ່ນ:

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​: ກວດ​ສອບ hives ການ​ຈົດ​ທະ​ບຽນ​ໃນ​ປະ​ລິ​ມານ​ການ Copy Shadow​¶

ເພາະມາດຕະຖານ cd ຫຼື dir ຄໍາສັ່ງບາງຄັ້ງ choke ສຸດ \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 ເສັ້ນທາງ namespace kernel, ທ່ານສາມາດຜ່ານເສັ້ນທາງໃນວົງຢືມໄປຫາ dir, ຫຼືສ້າງການເຊື່ອມຕໍ່ສັນຍາລັກທີ່ສະດວກ (mklink /d) ສຸດ D:\ ຊີ້ໄປຫາ Shadow Copy:

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

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

ຂັ້ນ​ຕອນ​ທີ 3​: ສໍາ​ເນົາ​ເອົາ​ພຽງ​ແຕ່ hive ທີ່​ເສຍ​ຫາຍ​ຈາກ Shadow Copy ເຂົ້າ​ໄປ​ໃນ​ D:\Windows\System32\config\¶

ສົມ​ມຸດ​ວ່າ​ການ​ທົດ​ສອບ​ຂອງ​ທ່ານ​ໃນ​ໄລ​ຍະ 2 ຂັ້ນ​ຕອນ​ທີ 3 ສະ​ແດງ​ໃຫ້​ເຫັນ​ວ່າ SYSTEM ລົ້ມເຫລວໃນການໂຫຼດ (ຫຼືທັງສອງ SYSTEM ແລະ SOFTWARE ລົ້ມເຫລວ).

ດໍາເນີນການຄໍາສັ່ງທີ່ແນ່ນອນເຫຼົ່ານີ້ເພື່ອທົດແທນການແຕກຫັກ SYSTEM (ແລະ/ຫຼື SOFTWARE) ເຮັດ​ໃຫ້​ສະ​ອາດ​:

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

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

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

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

ຂັ້ນ​ຕອນ​ທີ 4​: ກວດ​ສອບ​ການ​ໂຫຼດ hive ຟື້ນ​ຟູ​ຢ່າງ​ສະ​ອາດ (reg load) ແລະ​ກວດ​ສອບ​ CurrentControlSet¶

ທົດສອບວ່າສຳເນົາໃໝ່ SYSTEM hive loads ມີ​ສູນ​ຄວາມ​ຜິດ​ພາດ​:

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 Shadow Copy)?¶

ຈະເປັນແນວໃດຖ້າການປົກປ້ອງລະບົບ (VSS) ໄດ້​ຖືກ​ປິດ​ຫມົດ​ໃນ​ການ​ຂັບ​ໄດ້​, RegBack ຫວ່າງເປົ່າ, ແລະ reg load ບໍ່ສຳເລັດ SYSTEM ຫຼື SOFTWARE? ທ່ານຍັງມີສາມເສັ້ນທາງການຟື້ນຕົວຄືນກ່ອນທີ່ຈະຕິດຕັ້ງ Windows ຄືນໃໝ່:

Fallback 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 hive ແມ່ນ intact:

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: ກວດສອບ C:\Windows\System32\config\TxR\ ແລະ C:\Windows.old\Windows\System32\config\¶

ກວດ​ເບິ່ງ​ວ່າ​ຄຸນ​ສົມ​ບັດ​ທີ່​ໄດ້​ຍົກ​ລະ​ດັບ PC ບໍ່​ດົນ​ມາ​ນີ້​ສ້າງ (22H2 -> 23H2 -> 24H2) ຫຼືມີ Kernel Transaction Manager (TxR) ບັນ​ທຶກ​ບັນ​ຈຸ​:

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

Fallback 3: ກັບຄືນການອັບເດດສະສົມທີ່ຕິດຕັ້ງເຄິ່ງຫຼັງ (dism /RevertPendingActions)¶

ເລື້ອຍໆ, BAD_SYSTEM_CONFIG_INFO ຫຼື CRITICAL_PROCESS_DIED ເກີດຂຶ້ນເນື່ອງຈາກວ່າ PC ໄດ້ສູນເສຍພະລັງງານຢູ່ທີ່ 30% ໃນລະຫວ່າງ Working on updates... Don't turn off your computer, ອອກໄປ SOFTWARE ແລະ \Windows\WinSxS\pending.xml ອອກຈາກການຊິ້ງຂໍ້ມູນ. ຈາກ WinRE Command Prompt, ບອກການບໍລິການ ແລະການຄຸ້ມຄອງຮູບພາບການປັບໃຊ້ (DISM) ເຄື່ອງ​ຈັກ​ທີ່​ຈະ​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ທຸ​ລະ​ກໍາ​ການ​ປັບ​ປຸງ​ທັງ​ຫມົດ​ທີ່​ບໍ່​ຫມັ້ນ​ສັນ​ຍາ​ກັບ​ຮູບ​ພາບ Windows ອອບ​ໄລ​ນ​໌ (D:\):

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

Fallback 4: ການສ້ອມແປງຂໍ້ມູນການຕັ້ງຄ່າ Boot ທີ່ບໍ່ສາມາດອ່ານໄດ້ (BCD) ຮ້ານ (bootrec /rebuildbcd ແລະ bcdboot)¶

ຈະເປັນແນວໃດຖ້າຫາກວ່າທັງຫມົດຫ້າ hives ລົງທະບຽນພາຍໃນ D:\Windows\System32\config\ ໂຫຼດແລະ unload ສະອາດດ້ວຍ reg load, ແຕ່ PC ຍັງຖິ້ມ 0xc000014c (The Boot Configuration Data for your PC is missing or contains errors) ຫຼື 0xc000000f? ເນື່ອງຈາກວ່າ Windows BCD ໄຟລ໌ທີ່ເຊື່ອງໄວ້ຂອງທ່ານ 100 MB FAT32 EFI System Partition (\EFI\Microsoft\Boot\BCD) ຕົວຂອງມັນເອງຖືກເກັບໄວ້ໃນຄູ່ດຽວກັນຄືກັນອ້ອຍຕ້ອຍ regf registry hive ຮູບແບບເປັນ SYSTEM ແລະ SOFTWARE, ການສູນເສຍພະລັງງານສາມາດທໍາລາຍໄດ້ BCD hive ໃນ​ຂະ​ນະ​ທີ່​ອອກ​ D:\Windows\System32\config\ ບໍ່ໄດ້ແຕະຕ້ອງ. ກໍ່ສ້າງໃໝ່ອັນໃໝ່ BCD Hive ໃນ EFI System Partition ຂອງທ່ານໃນ 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 PC ຂອງທ່ານກັບມາຢູ່ເທິງເດັສທັອບ, ເປີດໃຊ້ Microsoft ທີ່ມີໃນຕົວ RegIdleBackup ວຽກ​ງານ​ດັ່ງ​ນັ້ນ​ C:\Windows\System32\config\RegBack\ ຈະຖືກເພີ່ມອັດຕະໂນມັດທຸກໆອາທິດ, ແລະກວດສອບການກູ້ຄືນລະບົບ (VSS) ມີ​ການ​ເຄື່ອນ​ໄຫວ​:

• ** ເປີດ​ໃຊ້​ງານ​ອັດ​ຕະ​ໂນ​ມັດ​ RegBack hive backup ໃນ Windows 10 (1803+) ແລະ Windows 11**: ເປີດ Command Prompt ສູງ (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 ຕື່ມຂໍ້ມູນໃສ່ກັບສໍາເນົາສຸຂະພາບຂອງ hives ທັງຫ້າ:

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

• ** ກວດ​ສອບ​ການ​ປົກ​ປັກ​ຮັກ​ສາ​ລະ​ບົບ (VSS Restore Points) ແມ່ນຫັນ ON ສໍາລັບ C:**: ກົດ Win + R, ປະ​ເພດ sysdm.cpl ,4​, ເລືອກ​ເອົາ​ຂອງ​ທ່ານ​ C: drive, ຄລິກ Configure, ເລືອກ ເປີດ​ການ​ປົກ​ປ້ອງ​ລະ​ບົບ, ຕັ້ງ Max Usage ເປັນ 5% (10 GB ກັບ 25 GB), ແລະຄລິກ ສ້າງ ເພື່ອເຮັດສຳເນົາເງົາພື້ນຖານທີ່ສະອາດໃນຕອນນີ້.
• ** ແລ່ນ sfc /scannow ແລະ DISM /Online /Cleanup-Image /RestoreHealth** ເມື່ອ booted ເຂົ້າ​ໄປ​ໃນ Windows ເພື່ອ​ກວດ​ສອບ​ການ​ບໍ່​ມີ DLLs ລະ​ບົບ​ຫຼື​ອົງ​ປະ​ກອບ​ການ manifests (COMPONENTS hive​) ໄດ້​ຮັບ​ຄວາມ​ເສຍ​ຫາຍ​ໃນ​ລະ​ຫວ່າງ​ການ​ເກີດ​ອຸ​ປະ​ຕິ​ເຫດ​.

ໝາຍເລກສຸກເສີນລະດັບພາກພື້ນ ແລະພິທີການຂອງອົງການ¶

ໃນຂະນະທີ່ເປັນ Windows BAD_SYSTEM_CONFIG_INFO BSOD ປົກກະຕິເປັນບັນຫາດ້ານໄອທີພາຍໃນ ຫຼືການສ້ອມແປງຄອມພິວເຕີສ່ວນບຸກຄົນ, ການເຮັດວຽກ ຫຼືເຊີບເວີລົ້ມເຫຼວທີ່ສົ່ງຜົນກະທົບຕໍ່ໂຮງໝໍ, ການສົ່ງສຸກເສີນ, ຫຼືໂຄງສ້າງພື້ນຖານສາທາລະນະຮຽກຮ້ອງໃຫ້ມີການເລັ່ງດ່ວນ:

• ** ສະ​ຫະ​ລັດ​ແລະ​ກາ​ນາ​ດາ **​: ໂທ 911 ຖ້າ​ຫາກ​ວ່າ​ອຸ​ປະ​ຕິ​ເຫດ Windows ປິດ​ການ​ຕິດ​ຕາມ​ກວດ​ກາ​ຄົນ​ເຈັບ​ທາງ​ດ້ານ​ການ​ຊ່ວຍ​, ການ​ສົ່ງ​ສຸກ​ເສີນ (CAD), ຫຼື​ການ​ຄວບ​ຄຸມ​ຄວາມ​ປອດ​ໄພ​ຊີ​ວິດ​, ແລະ​ສະ​ຫຼັບ​ກັບ​ຂັ້ນ​ຕອນ​ການ​ຢຸດ​ເຊົາ​ສະ​ຖານ​ທີ່​. ລາຍງານ bootloops ວິສາຫະກິດທີ່ກວ້າງຂວາງທີ່ເກີດຈາກການອັບເດດຕົວແທນຄວາມປອດໄພ ຫຼືເຫດການທາງໄຊເບີໄປຫາ CISA (1-844-Say-CISA / cisa.gov/report) ຫຼື ສູນ​ກາ​ນາ​ດາ​ສໍາ​ລັບ​ຄວາມ​ປອດ​ໄພ Cyber (1-833-CYBER-88).
• ** ສະຫະລາດຊະອານາຈັກ **: ໂທ 999 ສໍາລັບໄພຂົ່ມຂູ່ຕໍ່ຊີວິດຫຼືການຂັດຂວາງທາງດ້ານຄລີນິກຂອງ NHS ຮ້າຍແຮງ. ລາຍ​ງານ​ເຫດ​ການ​ທາງ​ອິນ​ເຕີ​ເນັດ​ຫຼື​ການ​ມີ​ຢູ່​ທີ່​ສໍາ​ຄັນ​ກັບ NCSC (ncsc.gov.uk) ຫຼື NHS England Cyber Operations.
• ** ສະ​ຫະ​ພາບ​ເອີ​ຣົບ **​: ໂທ 112 ໃນ​ທົ່ວ​ປະ​ເທດ​ສະ​ມາ​ຊິກ EU ທັງ​ຫມົດ​. ໜ່ວຍງານທີ່ໄດ້ຮັບການຄຸ້ມຄອງພາຍໃຕ້ NIS2 Directive ຈະຕ້ອງລາຍງານການຢຸດຕິການດຳເນີນງານທີ່ສຳຄັນຕໍ່ກັບ CSIRT ແຫ່ງຊາດຂອງເຂົາເຈົ້າພາຍໃນ 24 ຊົ່ວໂມງ.
• ** ອົດ​ສະ​ຕາ​ລີ​ແລະ​ນິວ​ຊີ​ແລນ **: ໂທ 000 ໃນ​ອົດ​ສະ​ຕາ​ລີ​ຫຼື 111 ໃນນິວຊີແລນ; ລາຍ​ງານ​ເຫດ​ການ​ພື້ນ​ຖານ​ໂຄງ​ລ່າງ​ທີ່​ສໍາ​ຄັນ​ກັບ ACSC (1300 CYBER1).
• ** ອິນ​ເດຍ​ແລະ​ອາ​ຊີ​ປາ​ຊີ​ຟິກ **: ໂທ 112 ໃນປະເທດອິນເດຍສໍາລັບການຕອບສະຫນອງສຸກເສີນ; ລາຍງານໂຄງສ້າງພື້ນຖານ ຫຼືເຫດການທາງໄຊເບີໃຫ້ CERT-In (incident@cert-in.org.in).

ຄຳຖາມທີ່ມັກຖາມເລື້ອຍໆ¶

ຈະເປັນແນວໃດຖ້າໂປຣໄຟລ໌ຜູ້ໃຊ້ຂອງຂ້ອຍເອງບໍ່ສາມາດເຂົ້າສູ່ລະບົບຫຼັງຈາກ boot ("We can't sign in to your account" / Profile ຊົ່ວຄາວ) ເນື່ອງຈາກວ່າ NTUSER.DAT ເສຍຫາຍບໍ?¶

ນອກເຫນືອໄປຈາກຫ້າລະບົບ hives ພາຍໃນ `\Windows\System32\config\`, ແຕ່ລະບັນຊີຜູ້ໃຊ້ແຕ່ລະຄົນມີ hive ລົງທະບຽນຂອງຕົນເອງ (`HKEY_CURRENT_USER`) ເກັບ​ຮັກ​ສາ​ໄວ້​ທີ່ **`C:\Users\\NTUSER.DAT`** (ບວກ `AppData\Local\Microsoft\Windows\UsrClass.dat`). ຖ້າ PC ຂອງ​ທ່ານ boots ກັບ​ຫນ້າ​ຈໍ​ເຂົ້າ​ສູ່​ລະ​ບົບ​ປັບ​ໄຫມ​, ແຕ່​ການ​ເຂົ້າ​ສູ່​ລະ​ບົບ​ການ​ໂຫຼດ desktop ຊົ່ວ​ຄາວ​ເປົ່າ​ເພາະ​ວ່າ​ `NTUSER.DAT` ໄດ້ເສຍຫາຍໃນລະຫວ່າງການໄຟຟ້າ, ເປີດ Command Prompt ສູງ, ດໍາເນີນການ `vssadmin list shadows`, ແລະຄັດລອກສຸຂະພາບ `NTUSER.DAT` ອອກຈາກ `\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\\NTUSER.DAT` (ໃນຂະນະທີ່ເຂົ້າສູ່ລະບົບບັນຊີຜູ້ເບິ່ງແຍງລະບົບທີສອງຫຼື WinRE ດັ່ງນັ້ນໄຟລ໌ບໍ່ໄດ້ຖືກລັອກ).

ເປັນຫຍັງ WinRE ຂໍລະຫັດການກູ້ຄືນ BitLocker 48 ຕົວເລກກ່ອນທີ່ຈະໃຫ້ຂ້ອຍເປີດ Command Prompt, ເມື່ອຂ້ອຍບໍ່ເຄີຍເປີດ BitLocker ດ້ວຍຕົວເອງບໍ?¶

ໃນເກືອບທຸກຄອມພິວເຕີ Windows 11 (ແລະ Windows 10) ທີ່ທັນສະໄຫມກັບ `TPM 2.0` ແລະ​ສະ​ແຕນ​ບາຍ​ທີ່​ທັນ​ສະ​ໄຫມ​, ການ​ເຂົ້າ​ສູ່​ລະ​ບົບ​ດ້ວຍ​ບັນ​ຊີ Microsoft ໃນ​ລະ​ຫວ່າງ​ການ​ຕັ້ງ​ຕົ້ນ​ອັດ​ຕະ​ໂນ​ມັດ​ເຮັດ​ໃຫ້ **ການ​ເຂົ້າ​ລະ​ຫັດ​ອຸ​ປະ​ກອນ (`BitLocker`)** ໃນພື້ນຫຼັງ ແລະອັບໂຫລດລະຫັດການກູ້ຂໍ້ມູນ 48 ຕົວເລກຂອງທ່ານໃສ່ບັນຊີ Microsoft ຂອງທ່ານ. ເປີດ **`https://aka.ms/myrecoverykey`** ໃນສະມາດໂຟນຂອງທ່ານ, ເຂົ້າສູ່ລະບົບດ້ວຍບັນຊີ Microsoft (`@outlook.com`, `@hotmail.com`, `@gmail.com`) ຫຼື ID ເຂົ້າວຽກ/ໂຮງຮຽນ (`myaccount.microsoft.com`) ໃຊ້ໃນ PC ນັ້ນ, ແລະໃສ່ລະຫັດ 48 ຕົວເລກທີ່ກົງກັບ `Key ID` ສະ​ແດງ​ໃຫ້​ເຫັນ​ໃນ​ຫນ້າ​ຈໍ​. ເມື່ອປົດລັອກແລ້ວ, `D:\Windows\System32\config` ແມ່ນສາມາດເຂົ້າເຖິງໄດ້ຢ່າງສົມບູນໃນ WinRE Command Prompt.

ຈະເປັນແນວໃດຖ້າ copy ລົ້ມເຫລວກັບ The process cannot access the file because it is being used by another process ເມື່ອຂ້ອຍພະຍາຍາມຂຽນທັບ SYSTEM ຫຼື SOFTWARE ໃນ WinRE?¶

ຄວາມ​ຜິດ​ພາດ​ນັ້ນ​ເກີດ​ຂຶ້ນ​ສໍາ​ລັບ​ຫນຶ່ງ​ໃນ​ສອງ​ເຫດ​ຜົນ​: (1​) ທ່ານ​ໄດ້​ພິມ​ໂດຍ​ບັງ​ເອີນ​ `C:\Windows\System32\config\SYSTEM` ເມື່ອໃດ `C:` ຫຼື `X:` ຕົວ​ຈິງ​ແລ້ວ​ແມ່ນ WinRE RAM disk ທີ່​ໃຊ້​ຊີ​ວິດ (`X:\Windows\System32\config\SYSTEM` ຖືກລັອກໂດຍ WinRE ຕົວຂອງມັນເອງ; ຢືນຢັນຕົວໜັງສືຂັບ SSD ແບບອອບໄລນ໌ແທ້ຂອງເຈົ້າສະເໝີ `D:` ຫຼື `E:` ກັບ `diskpart -> list vol`); ຫຼື (2) ເຈົ້າແລ່ນ `reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM` ກ່ອນໜ້ານີ້ໃນກອງປະຊຸມ ແລະລືມແລ່ນ **`reg unload HKLM\TestSys`** ກ່ອນ​ທີ່​ຈະ​ແລ່ນ​ `copy`.

ເປັນຫຍັງຄອມພິວເຕີຂອງຂ້ອຍຈຶ່ງຂັດຂ້ອງ BAD_SYSTEM_CONFIG_INFO (0x00000074) ແມ້ແຕ່ຢູ່ໃນຕົວຕິດຕັ້ງ Windows USB ໃໝ່ໆ ກ່ອນທີ່ຈະແຕະໃສ່ SSD?¶

ຖ້າ `BAD_SYSTEM_CONFIG_INFO` (`0x00000074`) ເກີດ​ຂຶ້ນ​ໃນ​ຂະ​ນະ​ທີ່​ການ​ບູດ​ເຄື່ອງ​ຕິດ​ຕັ້ງ USB Windows 10/11 ຍີ່​ຫໍ້ ** (ບ່ອນ​ທີ່​ຕົວ​ຕິດ​ຕັ້ງ​ແມ່ນ​ການ​ໂຫຼດ​ຂອງ​ຕົນ​ເອງ `boot.wim` ການ​ຈົດ​ທະ​ບຽນ RAM hive ເຂົ້າ​ໄປ​ໃນ​ຫນ່ວຍ​ຄວາມ​ຈໍາ​ຂອງ​ລະ​ບົບ​)​, ການ​ຈົດ​ທະ​ບຽນ SSD ຂອງ​ທ່ານ​ແມ່ນ **ບໍ່ ** ບັນ​ຫາ​: ** RAM ລະ​ບົບ​ຂອງ​ທ່ານ (`DDR4 / DDR5`) ແມ່ນ corrupting hive ລີຈິດຊີໃນຫນ່ວຍຄວາມຈໍາຍ້ອນວ່າມັນ unpacks **. ໃສ່ motherboard ຂອງທ່ານ `BIOS / UEFI` ຕັ້ງຄ່າ (`Del` ຫຼື `F2`), ປິດການໃຊ້ງານ `XMP / EXPO` ໂປໄຟການ overclocking ຫນ່ວຍຄວາມຈໍາເພື່ອໃຫ້ RAM ແລ່ນດ້ວຍຄວາມໄວມາດຕະຖານຂອງ JEDEC, ຫຼືທົດສອບດ້ວຍໄມ້ຫນຶ່ງຂອງ RAM ໃນເວລານັ້ນໂດຍໃຊ້ `MemTest86`.

ສາມາດກວດຫາ Antivirus ຫຼື Endpoint ຂອງພາກສ່ວນທີສາມໄດ້ (EDR) ການປັບປຸງ driver kernel ເຮັດໃຫ້ເກີດ BSOD loop ທີ່ຄ້າຍຄືກັບການລົງທະບຽນສໍ້ລາດບັງຫຼວງ?¶

ແມ່ນແລ້ວ. Kernel-mode ໄດເວີຄວາມປອດໄພ (`BOOT_START` ຄົນຂັບກັບ `Start = 0` ພາຍໃນ `HKLM\SYSTEM\ControlSet001\Services\`) ຖືກ​ໂຫຼດ​ໂດຍ​ `winload.efi` ຄຽງຄູ່ກັບ `SYSTEM` hive ກ່ອນ Windows ເຖິງແມ່ນເລີ່ມຕົ້ນວິດີໂອ. ຖ້າມີຂໍ້ບົກພ່ອງ `.sys` ໄຟລ໌ໃນ `D:\Windows\System32\drivers\` ຂັດຂ້ອງໃນເວລາ boot, ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງປ່ຽນແທັບລີຈິດຊີ: ພຽງແຕ່ປ່ຽນຊື່ທີ່ມີບັນຫາ. `.sys` ໄຟລ໌ໃນ `D:\Windows\System32\drivers\` (ຫຼືໂຫຼດ `D:\Windows\System32\config\SYSTEM` ກັບ `reg load HKLM\TestSys` ແລະປ່ຽນການບໍລິການທີ່ແຕກຫັກ `Start` ມູນຄ່າຈາກ `0` ກັບ `4` [ພິການ]).

ແມ່ນຫຍັງ COMPONENTS ຮັງພາຍໃນ C:\Windows\System32\config\, ແລະເປັນຫຍັງມັນເປັນ 100 MB?¶

ບໍ່ຄືກັບ `SYSTEM`, `SOFTWARE`, `SAM`, `SECURITY`, ແລະ `DEFAULT` (ເຊິ່ງຖືກໂຫລດຢູ່ໃນທຸກໆເກີບ), **`COMPONENTS`** ຮັງ (`C:\Windows\System32\config\COMPONENTS`) ຖືກໂຫລດແບບໄດນາມິກຕາມຄວາມຕ້ອງການເທົ່ານັ້ນເມື່ອ ** Windows Update (`TiWorker.exe` / Component-Based Servicing)** ຫຼື `sfc /scannow` ແລ່ນ. ເສຍຫາຍ `COMPONENTS` hive ຈະ ** ບໍ່ ** ຢຸດ Windows ຈາກ booting (`0x00000074`), ເຖິງແມ່ນວ່າມັນຈະເຮັດໃຫ້ການປັບປຸງ Windows ລົ້ມເຫລວກັບ `0x80073712` ຈົນ​ກ​່​ວາ​ການ​ສ້ອມ​ແປງ​ `DISM /Online /Cleanup-Image /RestoreHealth`.

ຄູ່ມືທີ່ກ່ຽວຂ້ອງ¶

• Windows blue screen (BSOD) ແລະ boot ການສ້ອມແປງ
• BitLocker, FileVault, ແລະ LUKS encryption key recovery lockout and TPM reset
• BIOS ແລະ UEFI ເຟີມແວອັບເດດອິດ, ການສູນເສຍພະລັງງານ, ແລະ Dual-BIOS Flashback
• ໂໝດອ່ານເທົ່ານັ້ນແບບກະທັນຫັນ SSD ແລະ NVMe, 0% ບລັອກສຳຮອງ, ແລະ TRIM ປິດໃຊ້ງານການກູ້ຂໍ້ມູນ
• ຄວາມລົ້ມເຫຼວຂອງຮາດດິດແລະການຟື້ນຕົວຂໍ້ມູນ
• ການສໍາຮອງຂໍ້ມູນຄອມພິວເຕີ, ຍຸດທະສາດ 3-2-1, ແລະການຟື້ນຟູໄພພິບັດ
• ຕົວເລກສຸກເສີນຕາມປະເທດ

ແຫຼ່ງຂໍ້ມູນແລະຄໍາແນະນໍາຢ່າງເປັນທາງການ¶

• Microsoft ຮຽນ​ຮູ້ (learn.microsoft.com): *ກວດ​ສອບ Bug​ 0x74: BAD_SYSTEM_CONFIG_INFO ການອ້າງອີງການແກ້ໄຂບັນຫາຢ່າງເປັນທາງການ (BCD truncatememory / numproc ການ​ແກ້​ໄຂ​ແລະ​ການ​ຢັ້ງ​ຢືນ Hive ການ​ຈົດ​ທະ​ບຽນ​)*​.
• ສະຫນັບສະຫນູນ Microsoft (KB4509719): ການລົງທະບຽນຂອງລະບົບບໍ່ຖືກສໍາຮອງໃສ່ໃນ RegBack ໂຟນເດີເລີ່ມຕົ້ນໃນ Windows 10 ຮຸ່ນ 1803 (EnablePeriodicBackup Registry Configuration).
• Microsoft Windows Internals (7^th Edition, Russinovich et al.): *ສະຖາປັດຕະຍະກຳຜູ້ຈັດການການຕັ້ງຄ່າ, ໂຄງສ້າງຖານສອງຂອງ Registry Hive (regf, hbin), ແລະບັນທຶກການເຮັດທຸລະກໍາຄູ່ (.LOG1 / .LOG2) ການ​ຟື້ນ​ຕົວ *.
• Microsoft Server Storage Documentation: Volume Shadow Copy Service (VSS) ການ​ບໍ​ລິ​ຫານ (vssadmin list shadows ແລະ GLOBALROOT ການເຂົ້າເຖິງ Namespace ຂອງອຸປະກອນ).
• ສະຖາບັນມາດຕະຖານ ແລະ ເຕັກໂນໂລຊີແຫ່ງຊາດ (NIST) (ສະຫະລັດ): ການພິມເຜີຍແຜ່ພິເສດ 800-86: ການວິເຄາະແລະການຟື້ນຕົວຂອງ Windows Registry Forensic.