Windows Registry Hive დაზიანებულია (BAD_SYSTEM_CONFIG_INFO BSOD): რატომ RegBack ცარიელია Windows 10/11-ში და როგორ აღვადგინოთ ჭინჭრის ციება VSS ჩრდილოვანი ასლებიდან¶

Windows 10-ის, Windows 11-ის ან Windows Server-ის აპარატის ავარიის დანახვა გაშვების დროს სიკვდილის გაუთავებელ ლურჯ ეკრანზე (BSOD) მარყუჟის ჩვენება **Stop code: BAD_SYSTEM_CONFIG_INFO (0x00000074) , CRITICAL_PROCESS_DIED, ან შავი Windows Boot Manager ეკრანი, რომელშიც ნათქვამია \Windows\System32\config\SYSTEM is missing or contains errors (Status: 0xc000014c / 0xc0000225) ნიშნავს Windows-ის ერთ ან რამდენიმე ძირითად ორობითი რეესტრის hive (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) ან ჩატვირთვის კონფიგურაციის მონაცემები (BCD) მაღაზია დაიშალა ელექტროენერგიის გათიშვის, იძულებითი გამორთვის ან კუმულაციური განახლების წარუმატებლობის დროს. კიდევ უფრო უარესი, როდესაც ადმინისტრატორები მიჰყვებიან ძველ ონლაინ გაკვეთილებს, რომლებიც ეუბნებიან, რომ გახსნან Windows Recovery Environment (WinRE) Command Prompt და დააკოპირეთ სარეზერვო რეესტრის ფაილები C:\Windows\System32\config\RegBack\, ისინი აღმოაჩენენ, რომ ** RegBack საქაღალდე მთლიანად ცარიელია (ან შეიცავს 0-byte ფაილები). Windows 10-ის 1803 ვერსიიდან და Windows 11-ის ყველა ვერსიიდან დაწყებული, Microsoft-მა სამუდამოდ გამორთო RegIdleBackup დავალება დისკზე სივრცის დაზოგვის მიზნით. არ წაშალოთ და ხელახლა დააინსტალიროთ ვინდოუსი: თქვენს კომპიუტერში თითქმის ინახავს ხელუხლებელი, ახლახან ჩაწერილი ყველა რეესტრის ასლები დამალული Volume Shadow Copy Service (VSS) კადრები (HarddiskVolumeShadowCopyN) და ტრანზაქცია .LOG1 / .LOG2 ჟურნალები, საიდანაც შეგიძლიათ ამოიღოთ 3 წუთში WinRE. ზოგადი დრაივერის ან აპარატურის BSOD პრობლემების აღმოსაფხვრელად იხ Windows ლურჯი ეკრანი (BSOD) და ჩატვირთვის შეკეთება; თუ BitLocker ითხოვს აღდგენის 48-ციფრიან გასაღებს Command Prompt-ის გახსნამდე, გაიარეთ კონსულტაცია BitLocker, FileVault და LUKS დაშიფვრის აღდგენის გასაღების დაბლოკვა და TPM გადატვირთვა და SSD და NVMe უეცარი მხოლოდ წაკითხვის რეჟიმი და TRIM გამორთვა სამაშველო. თუ ამ სისტემის გაუმართაობა გამორთავს საავადმყოფოს კლინიკურ სამუშაო სადგურებს, სასწრაფო დახმარების გაგზავნა (CAD), ან სიცოცხლის უსაფრთხოების სამართავებზე, დარეკეთ ადგილობრივ გადაუდებელ ნომერზე (911 შეერთებულ შტატებსა და კანადაში, 112 ევროკავშირის მასშტაბით, 999 გაერთიანებულ სამეფოში) ან შეამოწმეთ ჩვენი დირექტორია გადაუდებელი ნომრები.

გააკეთე ეს ახლა¶

1. ** არ დააწკაპუნოთ "ამ კომპიუტერის გადატვირთვა -> ამოიღეთ ყველაფერი" ან ბრმად არ დააკოპიროთ 0-byte ფაილები გარეთ C:\Windows\System32\config\RegBack\**: თუ გარბიხარ copy C:\Windows\System32\config\RegBack\* C:\Windows\System32\config\ Windows 10-ზე (1803+) ან Windows 11-ზე შემოწმების გარეშე dir RegBack პირველ რიგში, თქვენ გადაწერთ თქვენი ნაწილობრივ დაზიანებული რეესტრის ჭინჭრის ციებით 0-byte ცარიელი ფაილები, ანადგურებს დარჩენილი ჭინჭრის ციებას და ართულებს აღდგენას.
2. ** ჩატვირთვა Windows-ის აღდგენის გარემოში (WinRE) და გახსენით Troubleshoot -> Advanced options -> Command Prompt**:
3. თუ Windows ზედიზედ სამჯერ ვერ ჩაიტვირთება, ის ავტომატურად იწყებს ავტომატური შეკეთება -> გაფართოებული ოფციები.
4. ალტერნატიულად, ჩატვირთეთ ნებისმიერი Windows 10/11 USB საინსტალაციო მედიიდან, დააჭირეთ Shift + F10 (ან Shift + Fn + F10 ლეპტოპებზე) პირდაპირ ენის შერჩევის ეკრანზე და ამაღლებული X:\Sources> Command Prompt იხსნება დაუყოვნებლივ მენიუს დაწკაპუნების გარეშე.
5. ** იპოვეთ თქვენი Windows დანაყოფის ნამდვილი დისკის ასო (diskpart -> list vol), როგორც ეს ხშირად ხდება D: ან E: WinRE-ის შიგნით, არა C:**: აღდგენის გარემოში, C: ხშირად ენიჭება 100 მეგაბაიტს System Reserved ან Recovery დანაყოფი, სანამ თქვენი ფაქტობრივი Windows ინსტალაცია ზის D: ან E:. გაიქეცი dir C:\Windows, dir D:\Windows, dir E:\Windows იმის დასადასტურებლად, თუ რომელი დისკის ასო შეიცავს \Windows\System32\config\.
6. ** ყოველთვის შექმენით თქვენი არსებული (თუნდაც გატეხილი) სარეზერვო ასლი config\ საქაღალდეში C:\Config_Backup\ ერთ ფაილზე შეხებამდე**: გაუშვით mkdir D:\Config_Backup და xcopy /h /i /c /k /e /r /y D:\Windows\System32\config D:\Config_Backup. თქვენ უნდა შეინახოთ ორივე ძირითადი hive ფაილი (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) ** და ** მათი ფარული ტრანზაქციის ჟურნალის ფაილები (SYSTEM.LOG1, SYSTEM.LOG2, SOFTWARE.LOG1, SOFTWARE.LOG2).
7. ** ნებისმიერი სკირის გამოცვლამდე შეამოწმეთ თუ არა BCD (Boot Configuration Data) შეკვეცა ან ჭუჭყიანი ბუდის ტრანზაქციის ჟურნალი (.LOG1 / .LOG2) არის ნამდვილი მიზეზი BAD_SYSTEM_CONFIG_INFO**:
8. In 30% დან BAD_SYSTEM_CONFIG_INFO BSODs, რეესტრის ჭინჭრის ციება 100 პროცენტით ჯარიმაა და BCD მაღაზია უბრალოდ დაზიანებულია truncatememory / numproc დროშა (msconfig ხაფანგი) ან საჭიროებებს reg load გამეორება .LOG1/.LOG2 ტრანზაქციის ჟურნალი ავტომატურად.
9. ** თუ SYSTEM ან SOFTWARE ნამდვილად დაზიანებულია, ამოიღეთ ჯანსაღი ასლი პირდაპირ VSS Shadow Copy-დან (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\) გამოყენებით vssadmin list shadows**: მაშინაც კი, როცა System Restore (rstrui.exe) ვერ ხერხდება GUI-ში შეცდომით, VSS Shadow Copy მოცულობა არსებობს დისკზე და საშუალებას გაძლევთ დააკოპიროთ სუფთად SYSTEM და SOFTWARE ჭინჭრის ციება პირდაპირ \Windows\System32\config\ გამოყენებით copy ან robocopy.

გადაწყვეტილების ხე: BAD_SYSTEM_CONFIG_INFO (0x00000074) და 0xc000014c რეესტრის ტრიაჟი¶

გამოიყენეთ ეს დიაგრამა WinRE ბრძანების ხაზი (Shift + F10) ზუსტად დაადგინეთ დაზიანებული ფაილი და აღადგინოთ ის დაინსტალირებული პროგრამების ან მომხმარებლის ანგარიშების დაკარგვის გარეშე:

flowchart TD
    Start["Windows ავარია ჩატვირთვისას: BAD_SYSTEM_CONFIG_INFO (0x74) ან 0xc000014c"] --> OpenCmd["ჩატვირთეთ WinRE ან Windows USB -> გახსენით Command Prompt (Shift + F10)"]

    OpenCmd --> FindDrive["იპოვეთ Windows Drive-ის ჭეშმარიტი ასო (მაგ. D:) მეშვეობით: diskpart -> list vol -> exit"]
    FindDrive --> BackupFirst["მიმდინარე კონფიგურაციის საქაღალდის სარეზერვო ასლის შექმნა (მალული .LOG1/.LOG2 ჩათვლით): xcopy /h D:\\Windows\\System32\\config D:\\Config_Orig\\"]

    BackupFirst --> CheckBcd["შეამოწმეთ 1: გაუშვით bcdedit -> ვინმემ დააყენა truncatememory ან numproc msconfig-ში?"]
    CheckBcd -->|"დიახ: truncatememory ან ცუდი მნიშვნელობა აწმყო"| FixBcd["Run: bcdedit /deletevalue {default} truncatememory AND bcdedit /deletevalue {default} numproc -> Reboot"]

    CheckBcd -->|"არა: BCD Clean"| TestReplay["შეამოწმეთ 2: შეამოწმეთ და გაიმეორეთ ტრანზაქციის ჟურნალები (.LOG1/.LOG2) თითოეული Hive-ისთვის რეგისტრირებული დატვირთვით HKLM\\TempHive"]

    TestReplay --> WhichBroken{"რეგ იტვირთება წარმატებით და ხელახლა ითამაშებს .LOG1/.LOG2-ს სუფთად?"}
    WhichBroken -->|"დიახ: reg load ხელახლა დაკვრა Dirty Transaction Log -> Unload via reg unload"| BootFixed["გადატვირთეთ კომპიუტერი: Dirty Hive Header დაფიქსირდა ადგილზე ნულოვანი გადაბრუნებით"]

    WhichBroken -->|"არა: SYSTEM ან SOFTWARE აბრუნებს 'კონფიგურაციის რეესტრის მონაცემთა ბაზა დაზიანებულია' ან არის 0 ბაიტი"| CheckVss["გაშვება: vssadmin სიის ჩრდილები"]

    CheckVss --> HasVss{"არის თუ არა ჩამოთვლილი ტომის ჩრდილოვანი ასლები (HarddiskVolumeShadowCopy1..N)?"}

    HasVss -->|"დიახ: არსებობს ჩრდილოვანი ასლები"| CopyVss["დააკოპირეთ მხოლოდ დაზიანებული Hive (მაგ. SYSTEM / SOFTWARE) უახლესი HarddiskVolumeShadowCopyN-დან D:\\Windows\\System32\\config\\"]

    HasVss -->|"No: 0 ჩრდილოვანი ასლი ჩამოთვლილია"| CheckAlt["შეამოწმეთ Hive-ის ალტერნატიული წყაროები: D:\\Windows\\System32\\config\\TxR\\ OR Windows.old ან WinSxS კომპონენტი Hive შეკეთება"]

ფაზა 1: რატომ BAD_SYSTEM_CONFIG_INFO ხდება და რატომ RegBack ცარიელია Windows 10/11-ში¶

სანამ შეცვლით რაიმე ფაილს შიგნით \Windows\System32\config\, გაიგეთ, რას აკეთებს სინამდვილეში ხუთი რეესტრის ფაილი და რატომ არის ტრადიციული RegBack მეთოდი აღარ მუშაობს.

1. ანატომია \Windows\System32\config\¶

როდესაც Windows kernel (ntoskrnl.exe) და ჩამტვირთავი (winload.efi) ინიციალიზდება გაშვების დროს, ისინი იტვირთება ხუთი ორობითი მონაცემთა ბაზის ფაილი (ე.წ. Hives, დაწყებული 4-ბაიტიანი ASCII ხელმოწერით. regf ბაიტზე 0)-დან \Windows\System32\config\:

2. რატომ C:\Windows\System32\config\RegBack ცარიელია Windows 10 (1803+) და Windows 11-ში¶

Windows XP-დან Windows 10 ვერსიის 1709-მდე, დაგეგმილი დავალება სახელად \Microsoft\Windows\Registry\RegIdleBackup ავტომატურად კოპირებულია SYSTEM, SOFTWARE, SAM, SECURITY, და DEFAULT შევიდა \Windows\System32\config\RegBack\ როდესაც სისტემა უმოქმედო იყო. - რა შეცვალა მაიკროსოფტმა: დაწყებული Windows 10 ვერსიიდან 1803 (2018 წლის მაისი) და გაგრძელდა Windows 11 ყველა გამოშვებამდე, Microsoft-მა ოფიციალურად გამორთო ავტომატიკა RegBack ნაგულისხმევად მოსახლეობა დისკის ანაბეჭდის შესამცირებლად (დოკუმენტირებულია Microsoft Support KB4509719-ში). - შედეგი: თუ ხელით არ დაამატებთ EnablePeriodicBackup = 1 DWORD-მდე HKLM\System\CurrentControlSet\Control\Session Manager\Configuration Manager სანამ თქვენი კომპიუტერი გაფუჭდა, მუშაობს dir D:\Windows\System32\config\RegBack გამოჩნდება 0 File(s) (ან ხუთი ზომის ფაილი **0 ბაიტი **). - ** რატომ გაქვთ ჯერ კიდევ სარეზერვო ასლი **: მიუხედავად იმისა RegBack ცარიელია, Windows 10 და Windows 11 ავტომატურად ქმნიან Volume Shadow Copy (VSS) სნეპშოტები Windows-ის განახლებების, MSI აპლიკაციის ინსტალაციამდე, დრაივერის ინსტალაციამდე და ყოველკვირეული აღდგენის საგუშაგოები. ყველა VSS სნეპშოტი შეიცავს სრულ, დროში გაყინულ ასლს \Windows\System32\config\.

ფაზა 2: სწრაფი არაუკან შესწორებები (msconfig BCD ხაფანგი & .LOG1/.LOG2 ტრანზაქციის განმეორება)¶

ჩანაცვლებამდე SYSTEM ან SOFTWARE ჩრდილოვანი ასლიდან, შეამოწმეთ ეს ორი ნულოვანი უკან დაბრუნების გამოსწორება WinRE ბრძანების ხაზი (Shift + F10). ყველაფრის ნახევარზე მეტი BAD_SYSTEM_CONFIG_INFO (0x00000074) ავარიები წყდება სწორედ აქ 60 წამში, ერთი პარამეტრის უკან დაბრუნების გარეშე.

ნაბიჯი 1: იდენტიფიცირება თქვენი ნამდვილი Windows დისკის ასო (D: vs 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 in msconfig?¶

Microsoft-ის ოფიციალური დოკუმენტაცია შეცდომების შემოწმებისთვის 0x74 (BAD_SYSTEM_CONFIG_INFO) ხაზს უსვამს ყბადაღებულ ხაფანგს: მომხმარებლები გახსნიან msconfig -> ჩატვირთვა -> გაფართოებული პარამეტრები ცუდი "თამაშის ოპტიმიზაციის" ვიდეოს შემდეგ, შეამოწმეთ Number of processors ან Maximum memory (დაყენება 0 ან ცუდი მნიშვნელობა) და გადატვირთეთ. გადატვირთვისთანავე, Windows მუდმივ რეჟიმში მუშაობს BAD_SYSTEM_CONFIG_INFO BSOD რეესტრის ჭინჭრის შეხებამდეც კი.

შეამოწმეთ თქვენი ჩატვირთვის კონფიგურაციის მონაცემები (BCD) შეინახე ახლავე:

bcdedit /enum {default}

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

ნაბიჯი 3: შეამოწმეთ დაფიქსირება B: ხელახლა დაკვრა ბინძური .LOG1 / .LOG2 hive ტრანზაქციის ჟურნალები ადგილზე გამოყენებით reg load¶

რა მოხდება, თუ დენი გათიშული იყო Windows-ის წერის დროს SYSTEM ან SOFTWARE?

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

გამოცადეთ ხუთი ჭინჭრის ციება (SYSTEM, SOFTWARE, SAM, SECURITY, DEFAULT) სათითაოდ WinRE ბრძანების ხაზის გამოყენებით reg load:

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

reg unload HKLM\TestSys

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

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

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

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

ფაზა 3: ჯანსაღი რეესტრის ჭინჭრის ციების ამოღება VSS ჩრდილოვანი ასლები (HarddiskVolumeShadowCopyN)¶

რატომ ამოვიღებთ გატეხილ სკივარს ხელით Volume Shadow Copy-დან იმის ნაცვლად, რომ დააწკაპუნოთ Troubleshoot -> Advanced options -> System Restore GUI-ში? 1. პირველი, თუ SYSTEM ან SOFTWARE არ იკითხება, გრაფიკული System Restore (rstrui.exe) ოსტატი ხშირად ეჯახება System Restore failed to extract the original copy of the directory from the restore point (0x80070002 / 0x80070017). 2. მეორე, გრაფიკული სისტემის აღდგენა ცვლის all hives-ს და აბრუნებს ასობით დრაივერის/შემსრულებელ ფაილს დისკზე, ხოლო კოპირება მხოლოდ ერთი დაზიანებულია. SYSTEM ან SOFTWARE hive საწყისი HarddiskVolumeShadowCopyN იღებს 10 წამს და ტოვებს თქვენს სხვა ჭინჭრის ციებას (SAM, SECURITY) ხელუხლებელი.

ნაბიჯი 1: ჩამოთვალეთ ყველა ხელმისაწვდომი მოცულობის ჩრდილის ასლი დისკზე¶

ში WinRE ბრძანების სტრიქონი, გაუშვით:

vssadmin list shadows

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

ნაბიჯი 2: გადაამოწმეთ რეესტრის ჭურვები Shadow Copy Volume-ში¶

რადგან სტანდარტული cd ან dir ბრძანებები ხანდახან ახშობს \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 ბირთვის სახელთა სივრცის ბილიკი, შეგიძლიათ ან გადასცეთ გზა ბრჭყალებში dirან შექმენით მოსახერხებელი სიმბოლური ბმული (mklink /d) ზე D:\ პირდაპირ ჩრდილოვან ასლზე მიუთითებს:

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

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

ნაბიჯი 3: დააკოპირეთ მხოლოდ დაზიანებული სკივ(ები) Shadow Copy-ში D:\Windows\System32\config\¶

დავუშვათ, რომ თქვენმა ტესტმა 2 ფაზაში, მე-3 ნაბიჯი აჩვენა, რომ SYSTEM ვერ ჩაიტვირთა (ან ორივე SYSTEM და SOFTWARE წარუმატებელი).

გაუშვით ეს ზუსტი ბრძანებები გატეხილი შესაცვლელად SYSTEM (და/ან SOFTWARE) სუფთად დაასველეთ:

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

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

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

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

ნაბიჯი 4: გადაამოწმეთ აღდგენილი ჭურჭლის დატვირთვა სუფთად (reg load) და შეამოწმეთ CurrentControlSet¶

შეამოწმეთ, რომ ახლად დაკოპირებულია SYSTEM Hive დატვირთვები ნულოვანი შეცდომებით:

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

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

ფაზა 4: რა მოხდება, თუ vssadmin list shadows შოუები No items found (0 ჩრდილოვანი ასლი)?¶

რა მოხდება, თუ სისტემის დაცვა (VSS) მთლიანად გამორთული იყო დისკზე, RegBack ცარიელია და reg load ჩაიშლება SYSTEM ან SOFTWARE? Windows-ის ხელახლა ინსტალაციამდე ჯერ კიდევ გაქვთ სამი სარეაბილიტაციო გზა:

სარეზერვო 1: შეცვლა Default რომ LastKnownGood (ControlSet002) შიგნით SYSTEM¶

თუ reg load HKLM\TestSys D:\Windows\System32\config\SYSTEM წარმატებულია და BSOD (BAD_SYSTEM_CONFIG_INFO) ხდება იმის გამო, რომ შიგნით არის დრაივერი ან სერვისის გასაღები ControlSet001 (Current = 0x1) დაზიანებულია ხოლო ControlSet002 (LastKnownGood = 0x2) შიგნით იგივე SYSTEM სკა ხელუხლებელია:

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

სარეზერვო 2: შემოწმება C:\Windows\System32\config\TxR\ და C:\Windows.old\Windows\System32\config\¶

შეამოწმეთ არის თუ არა კომპიუტერის ახლახან განახლებული ფუნქცია აშენებული (22H2 -> 23H2 -> 24H2) ან აქვს ბირთვული ტრანზაქციის მენეჯერი (TxR) კონტეინერის ჟურნალები:

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

სარეზერვო 3: დააბრუნეთ ნახევრად დაინსტალირებული კუმულაციური განახლება (dism /RevertPendingActions)¶

ხშირად, BAD_SYSTEM_CONFIG_INFO ან CRITICAL_PROCESS_DIED ხდება იმის გამო, რომ კომპიუტერმა დაკარგა ენერგია 30% დროს Working on updates... Don't turn off your computer, ტოვებს SOFTWARE და \Windows\WinSxS\pending.xml სინქრონიზებული. საწყისი WinRE ბრძანების სტრიქონში, უთხარით განლაგების გამოსახულების სერვისი და მართვა (DISM) ძრავა, რათა აღადგინოს ყველა დაუსრულებელი განახლების ტრანზაქცია Windows-ის ოფლაინ გამოსახულების წინააღმდეგ (D:\):

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

სარეზერვო 4: ამოუკითხავი ჩატვირთვის კონფიგურაციის მონაცემების შეკეთება (BCD) მაღაზია (bootrec /rebuildbcd და bcdboot)¶

რა მოხდება, თუ ხუთივე რეესტრის სკაია შიგნით D:\Windows\System32\config\ სუფთად ჩატვირთვა-გადმოტვირთვა reg load, ჯერ კიდევ კომპიუტერი ისვრის 0xc000014c (The Boot Configuration Data for your PC is missing or contains errors) ან 0xc000000f? რადგან Windows BCD ფაილი თქვენს ფარულზე 100 MB FAT32 EFI სისტემის დანაყოფი (\EFI\Microsoft\Boot\BCD) თავად ინახება ზუსტად იმავე ბინარში regf რეესტრის hive ფორმატი როგორც SYSTEM და SOFTWARE, დენის დაკარგვამ შეიძლება გააფუჭოს BCD ჭინჭრის ციება წასვლისას D:\Windows\System32\config\ ხელუხლებელი. აღადგინე სრულიად ახალი BCD დააყენეთ თქვენი EFI სისტემის დანაყოფი 15 წამში:

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

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

ფაზა 5: ავტომატური ხელახალი ჩართვა RegBack სარეზერვო ასლები Windows 10-სა და Windows 11-ში¶

როდესაც თქვენი Windows კომპიუტერი დაბრუნდება სამუშაო მაგიდაზე, ხელახლა ჩართეთ Microsoft-ის ჩაშენებული RegIdleBackup დავალება ისე C:\Windows\System32\config\RegBack\ ყოველ კვირას ავტომატურად ივსება და შეამოწმეთ სისტემის აღდგენა (VSS) აქტიურია:

• ** ხელახლა ჩართეთ ავტომატური RegBack hive სარეზერვო ასლები Windows 10 (1803+) და Windows 11**: გახსენით ამაღლებული ბრძანების ხაზი (Run as Administrator) და გაუშვით ეს ერთი ოფიციალური რეესტრის ბრძანება (KB4509719):

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

  შემდეგ დაუყოვნებლივ ჩართეთ სარეზერვო დავალება ერთხელ გადამოწმებისთვის C:\Windows\System32\config\RegBack ივსება ხუთივე სკების ჯანსაღი ასლებით:

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

• ** გადაამოწმეთ სისტემის დაცვა (VSS აღდგენის ქულები) ჩართულია ON ამისთვის C:**: დააჭირეთ Win + R, აკრიფეთ sysdm.cpl ,4, აირჩიეთ თქვენი C: დისკზე, დააწკაპუნეთ Configure, აირჩიეთ ჩართეთ სისტემის დაცვა, დააყენეთ მაქსიმალური გამოყენება 5% (10 GB რომ 25 GB), და დააწკაპუნეთ შექმნა, რათა გააკეთოთ სუფთა საბაზისო ჩრდილოვანი ასლი ახლავე.
• ** გაიქეცი sfc /scannow და DISM /Online /Cleanup-Image /RestoreHealth** ერთხელ ჩაიტვირთება Windows-ში, რათა დაადასტუროს სისტემის DLL-ების ან კომპონენტების შენახვის მანიფესტები (COMPONENTS hive) დაზიანდა ავარიის დროს.

რეგიონული საგანგებო ნომრები და სააგენტოს პროტოკოლები¶

Windows-ის დროს BAD_SYSTEM_CONFIG_INFO BSOD, როგორც წესი, არის შიდა IT ან პერსონალური კომპიუტერის შეკეთების პრობლემა, სამუშაო სადგურის ან სერვერის გაუმართაობა, რომელიც გავლენას ახდენს საავადმყოფოებზე, გადაუდებელი დახმარების გაგზავნაზე ან საჯარო ინფრასტრუქტურაზე, საჭიროებს დაუყოვნებლივ ესკალაციას:

• შეერთებული შტატები და კანადა: აკრიფეთ 911 თუ Windows-ის ავარია გათიშავს პაციენტის კლინიკურ მონიტორინგს, სასწრაფო დახმარების გაგზავნა (CAD), ან სიცოცხლის უსაფრთხოების კონტროლი და გადახვიდეთ დაწესებულების შეფერხების პროცედურებზე. შეატყობინეთ ფართო საწარმოს ჩატვირთვის შესახებ, რომელიც გამოწვეულია უსაფრთხოების აგენტის განახლებით ან კიბერ ინციდენტებით CISA (1-844-Say-CISA / cisa.gov/report) ან კანადის კიბერუსაფრთხოების ცენტრი (1-833-CYBER-88).
• გაერთიანებული სამეფო: აკრიფეთ 999 სიცოცხლისთვის საფრთხის ან NHS მწვავე კლინიკური დარღვევებისთვის. შეატყობინეთ ძირითადი კიბერ ან ხელმისაწვდომობის ინციდენტების შესახებ NCSC (ncsc.gov.uk) ან NHS ინგლისის კიბერ ოპერაციები.
• ევროკავშირი: აკრიფეთ 112 ევროკავშირის ყველა წევრ ქვეყანაში. NIS2 დირექტივის დაფარულმა სუბიექტებმა უნდა შეატყობინონ მნიშვნელოვანი ოპერაციული შეფერხებების შესახებ ეროვნულ CSIRT-ს 24 საათის განმავლობაში.
• ავსტრალია და ახალი ზელანდია: აკრიფეთ 000 ავსტრალიაში ან 111 ახალ ზელანდიაში; შეატყობინეთ კრიტიკული ინფრასტრუქტურის ინციდენტების შესახებ ACSC (1300 CYBER1).
• **ინდოეთი და აზია-წყნარი ოკეანე **: აკრიფეთ 112 ინდოეთში საგანგებო რეაგირებისთვის; შეატყობინეთ ინფრასტრუქტურის ან კიბერ ინციდენტების შესახებ CERT-In (incident@cert-in.org.in).

ხშირად დასმული კითხვები¶

რა მოხდება, თუ ჩემი მომხმარებლის პროფილი თავად ვერ შედის სისტემაში ჩატვირთვის შემდეგ ("We can't sign in to your account" / დროებითი პროფილი) იმიტომ NTUSER.DAT კორუმპირებულია?¶

გარდა ამისა, ხუთი სისტემის hives შიგნით `\Windows\System32\config\`, თითოეულ ინდივიდუალურ მომხმარებლის ანგარიშს აქვს საკუთარი რეესტრის ნაწილი (`HKEY_CURRENT_USER`) ინახება **`C:\Users\\NTUSER.DAT`** (პლუს `AppData\Local\Microsoft\Windows\UsrClass.dat`). თუ თქვენი კომპიუტერი კარგად ჩაიტვირთება შესვლის ეკრანზე, მაგრამ შესვლისას იტვირთება ცარიელი დროებითი სამუშაო მაგიდა, რადგან `NTUSER.DAT` დაზიანდა ელექტროენერგიის გათიშვის დროს, გახსენით ამაღლებული ბრძანების ხაზი, გაუშვით `vssadmin list shadows`და დააკოპირეთ ჯანსაღი `NTUSER.DAT` გარეთ `\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\\NTUSER.DAT` (როდესაც შესული ხართ მეორე ადმინისტრატორის ანგარიშში ან WinRE-ში, რათა ფაილი არ დაიბლოკოს).

რატომ გააკეთა WinRE მოითხოვეთ 48-ციფრიანი BitLocker აღდგენის გასაღები, სანამ ნებას მომცემთ Command Prompt-ის გახსნას, როდესაც მე არასოდეს მიმიქცევია BitLocker ჩემს თავზე?¶

თითქმის ყველა თანამედროვე Windows 11 (და Windows 10) ლეპტოპზე `TPM 2.0` და Modern Standby, საწყისი დაყენების დროს Microsoft-ის ანგარიშით შესვლა ავტომატურად რთავს **მოწყობილობის დაშიფვრას (`BitLocker`)** ფონზე და ატვირთავს თქვენს 48-ციფრიან აღდგენის გასაღებს თქვენს Microsoft ანგარიშში. გახსნა **`https://aka.ms/myrecoverykey`** თქვენს სმარტფონზე შედით Microsoft-ის ანგარიშით (`@outlook.com`, `@hotmail.com`, `@gmail.com`) ან სამუშაო/სკოლაში შესვლის ID (`myaccount.microsoft.com`) გამოიყენება ამ კომპიუტერზე და შეიყვანეთ 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 დისკი (`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`) ხდება ** ახალი Windows 10/11 USB საინსტალაციო ჯოხის ჩატვირთვისას** (სადაც ინსტალერი იტვირთება საკუთარი `boot.wim` RAM რეესტრის ჩასმა სისტემის მეხსიერებაში), თქვენი SSD რეესტრი **არ ** პრობლემაა: **თქვენი სისტემის ოპერატიული მეხსიერება (`DDR4 / DDR5`) აფუჭებს რეესტრის ბლოკს მეხსიერებაში, რადგან ის იხსნება**. შეიყვანეთ თქვენი დედაპლატი `BIOS / UEFI` დაყენება (`Del` ან `F2`), გამორთვა `XMP / EXPO` მეხსიერების პროფილების გადატვირთვა, რათა ოპერატიული მეხსიერება იმუშაოს სტანდარტული JEDEC სიჩქარით, ან შეამოწმეთ ოპერატიული მეხსიერების ერთი ჯოხი ერთდროულად გამოყენებით `MemTest86`.

შეუძლია მესამე მხარის ანტივირუსული ან საბოლოო წერტილის გამოვლენა (EDR) ბირთვის დრაივერის განახლებამ გამოიწვია BSOD მარყუჟი, რომელიც ჰგავს რეესტრის კორუფციას?¶

დიახ. ბირთვის რეჟიმის უსაფრთხოების დრაივერები (`BOOT_START` მძღოლებთან ერთად `Start = 0` შიგნით `HKLM\SYSTEM\ControlSet001\Services\`) იტვირთება მიერ `winload.efi` გვერდით `SYSTEM` hive მანამ, სანამ ვინდოუსი ვიდეოს ინიციალიზაციასაც კი გააკეთებს. თუ დეფექტი `.sys` ფაილი `D:\Windows\System32\drivers\` ავარია ჩატვირთვისას, თქვენ არც კი გჭირდებათ რეესტრის ჩანაცვლება: უბრალოდ გადაარქვათ სახელი პრობლემურს `.sys` ფაილი `D:\Windows\System32\drivers\` (ან დატვირთეთ `D:\Windows\System32\config\SYSTEM` თან `reg load HKLM\TestSys` და შეცვალეთ გატეხილი სერვისი `Start` ღირებულება საწყისი `0` რომ `4` [გამორთული]).

რა არის COMPONENTS ბუშტი შიგნით C:\Windows\System32\config\და რატომ არის 100 მბ?¶

განსხვავებით `SYSTEM`, `SOFTWARE`, `SAM`, `SECURITY`, და `DEFAULT` (რომლებიც იტვირთება ყოველ ჩატვირთვაზე), **`COMPONENTS`** სკა (`C:\Windows\System32\config\COMPONENTS`) დინამიურად იტვირთება მხოლოდ მოთხოვნისამებრ, როდესაც **Windows Update (`TiWorker.exe` / კომპონენტზე დაფუძნებული სერვისი)** ან `sfc /scannow` ეშვება. კორუმპირებული `COMPONENTS` hive **არასდროს** შეაჩერებს Windows-ის ჩატვირთვას (`0x00000074`), თუმცა ეს გამოიწვევს Windows განახლებების წარუმატებლობას `0x80073712` გარემონტებამდე `DISM /Online /Cleanup-Image /RestoreHealth`.

დაკავშირებული გიდები¶

• Windows ლურჯი ეკრანი (BSOD) და ჩატვირთვის შეკეთება
• BitLocker, FileVault და LUKS დაშიფვრის აღდგენის გასაღების დაბლოკვა და TPM გადატვირთვა
• BIOS და UEFI პროგრამული უზრუნველყოფის განახლებები, ენერგიის დაკარგვა და Dual-BIOS Flashback
• SSD და NVMe უეცარი მხოლოდ წაკითხვის რეჟიმი, 0% სათადარიგო ბლოკები და TRIM გამორთვა სამაშველო
• მყარი დისკის უკმარისობა და მონაცემთა აღდგენა
• კომპიუტერის სარეზერვო ასლები, 3-2-1 სტრატეგია და კატასტროფის აღდგენა
• საგანგებო ნომრები ქვეყნების მიხედვით

წყაროები და ოფიციალური მითითებები¶

• Microsoft Learn (learn.microsoft.com): * შეცდომების შემოწმება 0x74: BAD_SYSTEM_CONFIG_INFO პრობლემების მოგვარების ოფიციალური მითითება (BCD truncatememory / numproc გამოსწორება და რეესტრის Hive Verification)*.
• Microsoft-ის მხარდაჭერა (KB4509719): სისტემის რეესტრის სარეზერვო ასლი აღარ არის RegBack საქაღალდე იწყება Windows 10 ვერსია 1803 (EnablePeriodicBackup რეესტრის კონფიგურაცია).
• Microsoft Windows Internals (7^th Edition, Russinovich et al.): Configuration Manager Architecture, Registry Hive Binary Structure (regf, hbin), და ორმაგი ტრანზაქციის ჟურნალი (.LOG1 / .LOG2) აღდგენა.
• Microsoft Server Storage Documentation: Volume Shadow Copy Service (VSS) ადმინისტრაცია (vssadmin list shadows და GLOBALROOT Device Namespace Access).
• სტანდარტებისა და ტექნოლოგიების ეროვნული ინსტიტუტი (NIST) (შეერთებული შტატები): სპეციალური პუბლიკაცია 800-86: Windows Registry Forensic Analysis and Recovery.