[SOLVED] 0x800703f1 - ERROR_BADDB after trying to fix COMPONENTS hive

[Acaimo]

First of all, thank you for your valuable help about Windows Update deep problems. I have already made a donation because I have been able to solve some problems in the past just reading the existing threads.

It always come to my mind that it would be nice if you shared a bit more of information so that advanced users can solve the same repetitive problems on their own, but I can understand some cases need to be analysed individually.

I came across some [HRESULT = 0x800703f1 - ERROR_BADDB] errors because of a corrupted COMPONENTS hive in Windows 2019 servers, preventing them from any update installation. There are several threads with this same error here, many of them successfully answered by you guys. Finally I was able to reproduce it in a test machine so I followed this small tutorial by rhelmer based on some sysnative threads&tools to replace COMPONENTS hive, which it seems to have worked (or at least to have done anything) because now sfc completes its execution, unlike with the old hive.

But the Windows update keep failing, now with a different error in CBS.log. It is again a BADDB, but it does not mention COMPONENTS hive anymore. Instead it seems to be related with SCHEMA.DAT file (as per some threads like this).

CBS

2024-03-22 12:32:10, Error                 CSI    00000001 (F) HRESULT_FROM_WIN32(1009) #1# from LoadStore(target = NULL)
[gle=0x80004005]
2024-03-22 12:32:10, Error                 CSI    00005fca@2024/3/22:11:32:10.512 (F) onecore\base\wcp\componentstore\com\store.cpp(5260): Error NTSTATUS_FROM_WIN32(1009) originated in function Windows::COM::CComponentStore::MountSMISchemaHive expression: MountSMISchemaHive
[gle=0x80004005]
2024-03-22 12:32:10, Error                 CSI    00005fcb (F) HRESULT_FROM_WIN32(1009) #45504955# from Windows::COM::CComponentStore::InternalTransact(...)[gle=0x800703f1]
2024-03-22 12:32:10, Error                 CSI    00005fcc (F) HRESULT_FROM_WIN32(1009) #45504953# from Windows::ServicingAPI::CCSITransaction::ICSITransaction_Commit(Flags = 38, pSink = NULL, disp = 0)[gle=0x800703f1]
2024-03-22 12:32:10, Error                 CSI    00005fcd (F) HRESULT_FROM_WIN32(1009) #45504952# 11539 us from Windows::ServicingAPI::CCSITransaction_ICSITransaction::Commit(flags = 0x00000026, pSink = NULL, disp = 0)
[gle=0x800703f1]
2024-03-22 12:32:10, Error                 CBS    Exec: Failed to commit CSI transaction to resolve execution chain. [HRESULT = 0x800703f1 - ERROR_BADDB]

EventLog

Windows update "Security Update for Windows (KB5035849)" could not be installed because of error 2147943409 "The configuration registry database is corrupt." (Command line: ""C:\windows\system32\wusa.exe" "C:\temp\windows10.0-kb5035849-x64.msu" ")

Unfortunately I cannot run any external .exe there so I cannot use your great diagnosis/repair tools.

My questions are:
- was my assumption right and the problematic file is now SCHEMA.DAT?
- if so, is there anything I can do for repairing the corruption there? I think I can upload the file here, but I wanted to know how to fix it in case I face this same error in the future.

Thank you very much, for this and for all the assistance in previous threads.

 

[Maxstar]

Hi and welcome to Sysnative,

Upload the SCHEMA.DAT file

• Navigate to C:\Windows\System32\SMI\Store\Machine and copy the SCHEMA.DAT file to your desktop.
• Right-click on this file on your desktop and select Send To > Compressed (zipped) folder. This will create a file named SCHEMA.ZIP on your desktop.
• Attach this ZIP-file to your next reply.

 

[Acaimo]

Hello, thannks for helping here.

Find attached the file.

If the problem is effectively with this file, could you plase share any clue of what I can do if I find this same situation in the future?

 

[Maxstar]

Hi,

This problem has to do with the primary and secondary sequence numbers does not match. Only for the COMPONENTS hive there is a public tool available to fix this issue.

Replace the SCHEMA.DAT file
Warning: this fix is specific to the user in this thread. No one else should follow these instructions as it may cause more harm than good. If you are after assistance, please start a thread of your own.

• Download the attached Schema.zip file and save it to your desktop, right-click on it and select Extract all.
• Navigate to C:\Windows\System32\SMI\Store\Machine and rename the SCHEMA.DAT file to SCHEMA.old
• Copy the SCHEMA.DAT file on your desktop into the above directory.

Afterwards reboot the server and attempt to update. If it fails attach a new copy of the CBS logs.

 

[Acaimo]

Thank you very much. I will try and come here with the result, although I need some days to be able to check it.

I understand there is no tool for fixing it, but is there anything to read the data in schema.dat and search for any mismatch?
I am starting to understand (mainly thank you guys in this subforum) this deep world of update corruptions, but I am still lost in some things

 

[Maxstar]

You're welcome. For such corruptions we use a specific tool which is not publicly available. A litte bit more information about dirty hives can be found in this manual of Registry Explorer (page 28). And this blog post might be interesting too.

 

[Acaimo]

Hello again Maxstar,

It worked!
The computer is now able to install updates.
And the links you have shared have been of great help for understanding what is going on down there.

I have checked this and some other pairs of corrupted/repaired reg/dat files with an HEX visor and have found that indeed, there was a mismatch between primary and secondary sequence numbers (in yellow and green in the screenshot) as you explained to me - and could find much more detailed in the post in Medium you shared.
I understand that given that we do not have the transactional logs available we just try to make it readable by the OS to able to go ahead and check any further corruption if it exists.
Apart from this change, the only difference with the new&functioning file is a number down there, highlighted with a blue underline.
Is it any type of checksum or byte verification? If so, do you know how to calculate it?

Thank you again for you help!! It is much appreciated.

 

[Maxstar]

Hi,

You're welcome. Glad to hear the problem has been resolved.

If you're interested in such problems and Windows Update in general and how to solve them - and if you have ambitions to become a volunteer as well you can always sign-up for our Update Academy.

 

[Acaimo]

Just to add info that can help readers with my same curiosity:

I have found this REGF file documentation and that last dword (4 bytes) is a checksum obtained with XOR-32 of the previous 508 bytes. Just grouping those 508 bytes in sets of 4 and doing bitwise XOR between them gives the result.