Windows 7 Pro x86, constantly de-regestering itself

[SkrumpyJax]

There's 21 of these at 10am yesterday;

The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume C:.

Then two similar of these, at 21.11 tonight;

{Registry Hive Recovered} Registry hive (file): '\??\Volume{0cb5b047-2391-11e2-9347-806e6f6e6963}\System Volume Information\SPP\SppCbsHiveStore\{cd42efe1-f6f1-427c-b004-033192c625a4}{2EFBD7E3-7A30-4F92-BCE9-D847199483A1}' was corrupted and it has been recovered. Some data might have been lost.

 

[SkrumpyJax]

https://dl.dropbox.com/u/36376760/COMPONENTS.zip

 

[NoelDP]

OK - it turns out that the manifest problem is due to a registry error as well

That set of filesystem errors is possibly the result/cause of the entries in the CBS log - it matches the number of registry errors there.

I'll have to play with the COMPONENTS file directly and see if I can get it to work.

If you can upload it I'll start playing - but as I say please disallow Windows Updates in the meantime (I don't think they have a hope of working anyhow, but...)

 

[NoelDP]

We obviously crossed in the post.
I've got the file - now to find the errors and correct them!

 

[SkrumpyJax]

Heh indeed, thanks. I think I've already turned off windows updates but will double check.

 

[NoelDP]

OK - first attempt.
There's one I know I haven't fixed - with any luck I've got most of the others

I've uploaded a file SJXcomp.zip to my Skydrive at Noel's SkyDrive
Please download and save it - extract the contained file (COMPONENTS) to your desktop

Open Windows Explorer and navigate to the C:\Windows\System32\config folder.
Rename the existing COMPONENTS file to COMPONENTSOLD
Now move the COMPONENTS file from your desktop to the ..\config folder

Then open an Elevated Command Prompt and run the following commands...
ICACLS C:\Windows\System32\config\COMPONENTS /inheritance:e

If you now run
ICACLS C:\Windows\System32\config\COMPONENTS
it should show "NT AUTHORITY\SYSTEM" and Administrators as having (I)(F) rights - if not, then apply the rights through Explorer, or using /GRANT <idF) for each

then reboot, and run another CheckSUR report.

post the results.

(I'll be in bed by then!)

 

[SkrumpyJax]

Hi Noel, sorry for the delay, been a hectic week.

 

[NoelDP]

No problem

The results are pretty good!
we've gone from

 Found 8 errors
  CSI Could Not Open file Total count: 1
  CSI Manifest and S256H Do Not Match Total count: 1
  CSI Corrupt Component Keyform Total count: 4
  CSI Corrupt Identity Total count: 1
  CSI Located Replacement: Invalid (S256H) Total count: 9
  CSI Replacement File: CreateFile Failed Total count: 9
  CSI Missing Winning Component Key Total count: 1

to

 Found 2 errors
  CSI Manifest and S256H Do Not Match Total count: 1
  CSI Located Replacement: Invalid (S256H) Total count: 9
  CSI Missing Winning Component Key Total count: 1

I *think* the reason that it effectively ignores the 9 (w).... errors is that they are attempt to pull the data from backups in the VSS/SystemRestore system.

Please repeat the exercise of uploading the COMPONENTS file
Please also run an SFC /SCANNOW and post the new CBS.log file - it should have some data in it that I can use to check against the registry.

 

[SkrumpyJax]

Unfortunately someone has turned the computer off while I was working on it, but I got the COMPONENTS off in time.

https://dl.dropbox.com/u/36376760/COMPONENTS.zip

 

[NoelDP]

Dontcha hate it when that happens!

 

[SkrumpyJax]

Here's the CBS.log

 

[NoelDP]

As I thought - it's almost certainly a bitflip in the registry causing the manifest error.
The S256 hash value differs from the found value by only one bit....

Expected:{l:32 b:8e98bc15c20c1b3cd3e871c52786e47815e132c0ade91cbdaba5da9f2fb29bc3}
Found: {l:32 b:8e98bc15c20c1b3cd3e871c52786e47855e132c0ade91cbdaba5da9f2fb29bc3}

It's almost impossible for that to happen with a corrupted file, so the value in the registry must be wrong.

I'll adjust the COMPONENTS hive accordingly (after checking the value elsewhere) - that should get rid of the rest of the errors

 

[SkrumpyJax]

That would be grand, thanks!

 

[NoelDP]

Ooops! - this slipped off the desk

I'll do it tonight

 

[NoelDP]

OK - done and confirmed... and we have an easier way to fix it than messing around with detached COMPONENTS hives

Open an Elevated Command Prompt and run the following commands

REG LOAD HKLM\COMPONENTS C:\Windows\System32\config\COMPONENTS
REG ADD HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\x86_mdm5674a.inf_31bf3856ad364e35_6.1.7600.16385_none_e6de8df1e7b331d5 /v S256H /t REG_BINARY /d bc15c20c1b3cd3e871c52786e47855e132c0ade91cbdaba5da9f2fb29bc3 /F
REG UNLOAD HKLM\COMPONENTS

close the window, and reboot - then run another SFC scan and post the CBS.log

 

[SkrumpyJax]

Here's the CBS log

 

[NoelDP]

Hmmm -

 Line 4921: 2013-03-22 20:50:40, Info                  CSI    000001be [SR] Repairing 4 components
 Line 4922: 2013-03-22 20:50:40, Info                  CSI    000001bf [SR] Beginning Verify and Repair transaction
 Line 4927: 2013-03-22 20:50:40, Info                  CSI    000001c2 [SR] Cannot verify component files for mdm5674a.inf, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral, manifest is damaged (TRUE)
 Line 4928: 2013-03-22 20:50:40, Info                  CSI    000001c3 [SR] Cannot verify component files for Microsoft-Windows-fde, Version = 6.1.7601.17514, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral, manifest is damaged (FALSE)
 Line 4931: 2013-03-22 20:50:41, Info                  CSI    000001c5 [SR] Cannot repair member file [l:24{12}]"Wildlife.wmv" of Microsoft-Windows-VideoSamples, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch

Odd - I seem to have 'lost' the first two Bytes of data from the expiated value for the S256H....
let me try that again......

In an Elevated Command Prompt, run the following commands.

REG LOAD HKLM\COMPONENTS C:\Windows\System32\config\COMPONENTS
REG ADD HKEY_LOCAL_MACHINE\COMPONENTS\DerivedData\Components\x86_mdm5674a.inf_31bf3856ad364e35_6.1.7600.16385_none_e6de8df1e7b331d5 /v S256H /t REG_BINARY /d 8e98bc15c20c1b3cd3e871c52786e47855e132c0ade91cbdaba5da9f2fb29bc3 /F
REG UNLOAD HKLM\COMPONENTS

We also seem to have picked up another manifest problem.

Please run CheckSUR again, and post the new log

 

[SkrumpyJax]

Appologies for the delay, had a few other issues that had to take priority.
Thanks for your support so far.

 

[NoelDP]

No problem - I have plenty of other stuff to keep me over-occupied

 

[SkrumpyJax]

Thank you very much for your help Sir, you can close the ticket. The PC has been hung, drawn and quartered.
Thanks again!