Three servers update failing, tried everything, trying to avoid complete re-install!

[jdamnation]

We have 3 X Windows 2008R2 severs running in VMs, none of which have been able to update for months. We have put the problem off for ages, however now we are needing to try to resolve, general feeling is a complete re-install.

That would be a lot of pain - so would like to try to avoid that if possible - especially if (perhaps) it's something simple.

We have trawled the web. We've run sfc /scannow, the MS System Update Readiness Tool, nothing has worked. There appear to be no errors (just minors) however, update is failing with the dreaded "ERROR_SXS_COMPONENT_STORE_CORRUPT" all over cbs.log.

The first error we see in CBS is:

2014-03-21 23:03:06, Error CSI 00000024@2014/3/21:23:03:06.203 (F) d:\win7sp1_gdr\base\wcp\componentstore\storelayout.cpp(11690): Store corruption detected in function ComponentStore::CRawStoreLayout::CheckFamilyIndexForDeadWinnerComponent expression: (null)

Which I simply don't understand because D: is a CD and has nothing to do with the Windows install - plus these three servers are Windows 2008R2 and now Win7.

The same error crops up on all three servers - no idea if it's a red herring, it's just the first serious error that shows up in CBS.

Aside from update problems - severs running fine, and was able to install / update office on one of them - just not able to install any updates including IE 10 / 11.

Cheers,

JD

 

[niemiro]

Hello, and welcome to Sysnative!

The D:\ drive has nothing to do with your computer. That is the network share on which Microsoft's source code file for which the failure occurred is located. This information is mostly only useful to Microsoft, as neither of us have access.

This is the source file: d:\win7sp1_gdr\base\wcp\componentstore\storelayout.cpp
and this is the line number: 11690

which allows one of their coders to hone in exactly on the problem when fixing bugs.


I think you've already seen the draft article here: https://www.sysnative.com/forums/wi...fix-windows-update-error-code-0x80073712.html

so please do as it instructs and upload the file I need to diagnose the problem. Choose any one of the servers for me to work on initially, and stick with that server. Once I've got the COMPONENTS hive, I'll be able to actually see what's going on. Also please upload the entire C:\Windows\Logs\CBS folder (whole folder, not just CBS.log).

Richard

 

[jdamnation]

Ah thanks for the reply. I think this is going to be a tough one so an not optimistic! This morning I have been cloning one of the three servers (which happens to be an AD machine) so I can have a go at at performing an in place restore (on the clone). If it works and everything remains intact... then that's a possibility I guess for the other two.

Anyway here's a link to the entire CBS directory. There are so many corruption / invalid files / yadda yadda in here that my brain just turns to mush!!!

http://1drv.ms/1dkTs98

If you can rescue it, major props!

 

[jdamnation]

Just update - the in place repair / restore on the clone of the AD system fails with a c00002e2 error (the specified procedure could not be found). MS suggested fix for this particular error only apply to multi AD systems - which is the case for these three servers.

So either the Windows Update issue can be fixed or I think it's clean re-install (which is going to be a LOT of work).

JD

 

[niemiro]

Hmmmm. I'm really sorry, but I am not able to fix this after looking through the logs and other files

I am truly very sorry.

Richard

 

[jdamnation]

Thanks for looking Richard - I thought it was pretty unlikely CBS just looks like a complete car crash.

Bit more info in case you see this again, these three servers were 'restored' using DoubleTake Recover Now, from three other identical servers (so these servers are a replica of another set of three). The servers used as the restore source actually update fine. Immediately after performing the DT restore, some updates worked, then we hit this wall - on all three of the restored servers.

Now I think what's likely, is that we will delete all three servers, and create a new set from the perfectly up to date source servers.

If the newly restored servers again fail to update, we will get back on to VisionSolutions (people that make DoubleTake) and try them again. It's clear that something is not quite right with DoubleTake - shame, because absolutely everything else worked - and it's a great product - we use it a lot.

It's possible that there was something wrong with the three 'target' servers we used to restore the live server to.

Anyway, thanks again... I will let you know how we get on with the re-recovery.

JD