Hello again,
Thanks for the link; I do like to understand the nature of problems and the techniques involved in solving issues such as this. It certainly looks as if I chose exactly the right forum! I'm off to do some reading.
Kind regards
LMF
No problem :)
The guide's actually a tad outdated now. SFCFix AutoAnalysis:: now automatically resolves most instances of the corruption by itself.
For your own interest, here's a quick breakdown of the work I do:
First I work out what part of Windows Update the error originates from. 99% of the time it's CBS (the part which deals with the installation and uninstallation of components, files, and registry keys), hence why we collect CBS logs as standard, but just occasionally it comes from SMI , CSI, Windows Update user interface, Windows Update networking module, BITS (again, networking), the early boot process part, or the driver installation parts, Windows Installer (.net, office, SQL server, VC++ products, primarily). Each have their own logfiles, diagnosis techniques, repair methods, and groups of error codes. Obviously, we need to understand them all in enough depth to be able to fix the rare error codes. I usually do this by checking CBS logs. 99% of the time I'll find the problem, but if I find nothing, I start to investigate further and think about which logfiles/logging techniques need to be used.
Here I pulled these lines out of your logfile:
Code:
2014-04-03 09:56:48, Info CSI 0000081b [SR] Repairing 1 components
2014-04-03 09:56:48, Info CSI 0000081c [SR] Beginning Verify and Repair transaction
2014-04-03 09:56:48, Info CSI 0000081d Hashes for file member \SystemRoot\WinSxS\amd64_prncacla.inf_31bf3856ad364e35_6.3.9600.16384_none_9590ba64d5b91f79\Amd64\CNBJ2530.DPB do not match actual file [l:36{18}]"Amd64\CNBJ2530.DPB" :
Found: {l:32 b:Ka2W3xf+N0AYDlbZGYZN3SyUOdG1v9GKCm0q2fVi3Fw=} Expected: {l:32 b:n520k714Uu3utHa5JGQ6HQYbZphKhlMWq5pEmfnCDuw=}
2014-04-03 09:56:48, Info CSI 0000081e [SR] Cannot repair member file [l:36{18}]"Amd64\CNBJ2530.DPB" of prncacla.inf, Version = 6.3.9600.16384, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral in the store, hash mismatch
2014-04-03 09:56:48, Info CSI 0000081f Hashes for file member \SystemRoot\WinSxS\amd64_prncacla.inf_31bf3856ad364e35_6.3.9600.16384_none_9590ba64d5b91f79\Amd64\CNBJ2530.DPB do not match actual file [l:36{18}]"Amd64\CNBJ2530.DPB" :
Found: {l:32 b:Ka2W3xf+N0AYDlbZGYZN3SyUOdG1v9GKCm0q2fVi3Fw=} Expected: {l:32 b:n520k714Uu3utHa5JGQ6HQYbZphKhlMWq5pEmfnCDuw=}
2014-04-03 09:56:48, Info CSI 00000820 [SR] Cannot repair member file [l:36{18}]"Amd64\CNBJ2530.DPB" of prncacla.inf, Version = 6.3.9600.16384, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type = [l:24{12}]"driverUpdate", TypeName neutral, PublicKey neutral in the store, hash mismatch
2014-04-03 09:56:48, Info CSI 00000821 [SR] This component was referenced by [l:186{93}]"Microsoft-Windows-Printer-Drivers-Package~31bf3856ad364e35~amd64~~6.3.9600.16384.INF_prncacla"
2014-04-03 09:56:48, Info CSI 00000822 [SR] Repair complete
2014-04-03 09:56:48, Info CSI 00000823 [SR] Committing transaction
That immediately tells me that I'm dealing with one of our "standard" corruptions, of which there are about 10. I know that for this one, DISM fixes the issue.
Next I think about root causes and whether there are any underlying issues. I check for further issues in CBS.log I also question whether the SURT needs to be run. On your system, the SURT hasn't been run. However, given that you only have the one standard corruption, I'm not overly concerned. I have to assume that the pattern on your computer matches everybody else's for this standard corruption, but why shouldn't it? So I say that SURT doesn't need to be run, there's no underlying cause to be found. Next I think about hardware: are the files corrupt due to failing hardware? After all, if I fix 100 corruptions and in two weeks time your HDD dies and you lose all of your data, that's partially my fault for missing the warning signs. However, on your system, all is well: standard corruption is software related, and no other markers to suggest hardware failure. No need to warn user. I also think about malware: is your corruption actually an infection? Yours? No.
I also think about whether there's anything I want to test. If you have a rare error code, I might need to trial run (with user consent), and under my supervision (i.e. SFCFix posts back to me for review what it would automatically fix prior to automatically fixing) a fix for future users. Or I may need to collect some data so that I can develop a fix for an error code I've never successfully repaired before, and have no idea how to go about fixing.
If it's none of those, I start the repair (assuming it's a non-standard corruption, a corrupt file). First, I source a good replacement for the file. I use Microsoft's update servers & some complex Googling (complex enough to get my account banned once for generating unusual traffic!) to source origins. I also use large databases I've compiled, the user's own system registry, my own computers, virtual PCs, and a sprinkling of good fortune, to find the replacement (sometimes it's simple - en_us explorer.exe from Windows 7 SP1 would be dead easy to find. A driver file for some crazy rare printer in Norwegian language for Windows Server 2008 R1 pre service pack 1 is trickier).
Once sourced, I make the replacement. I am very careful of file permissions and ownership. Mangling them causes a security risk for the PC. I use SFCFix, which correctly restores permissions and ownership leaving no such security hole. Alternatively, a Linux/Windows bootable DVD can be used, but that's a pain in comparison to dropping a script on top of SFCFix.
So what if the corruption is not just a simple corrupt file? There are about 250 classes of corruption (mostly registry related) under SURT, each with their own considerations, methods of fix, sub-categorisations, etc. etc. (for example, a "cannot open registry key {x}" is very different if caused by registry key missing, or registry key permissions prevent opening). I would say that after five years on the job, I have all but ~5 nailed down and where possible documented.
But that's only what's detected by the SURT! I also learn error codes and conflict pairs (for example between old versions of Driver Sweeper and Windows 7 SP1, with its own corruption pattern in CBS.log), WiseFixer registry cleaner and certain corruption patterns in SURT, old versions of AMD graphics card drivers which cause Windows 7 SP1 not to show up in Windows Update, etc. etc.
Basically, it's a very easy job to do: look at bottom of CBS.log, destroy permissions on Windows folder, copy corrupt file from one computer to another. But I would argue that it's a job very difficult to do well, because so much of it is experience based, and learning all of the different corruption types, logfiles, conflicts, error codes, and fixes. All people see me do is copy files around and think "anyone could do that!", but I like to think (whether for right or wrong) that there's a little bit more to what I do than just that.
Richard
