Repeated issues with sfc/scannow

[Little_Micky_Fingers]

After a few problems the sfc utility reported corrupted files which could not be fixed.
Many thanks for taking a look at this.

 

[niemiro]

Hello again!

One minor issue which needs DISM.

To use DISM -

1. Press the Windows Key on your keyboard and X to open up the Power User Tasks Menu
2. Click (or tap) Command Prompt (admin)
3. When command prompt opens, copy and paste the following commands into it, press enter after each
   
   DISM.exe /Online /Cleanup-image /Restorehealth
   
   Wait for this to finish before you continue (approximately 15-20 minutes)
   
   sfc /scannow
   Wait for this to finish before you continue (approximately another 15 minutes)

And you are done. Check that SFC returns "Windows Resource Protection did not find any integrity violations." or that it successfully fixed all corruptions. If it doesn't, please let me know.

Richard

 

[Little_Micky_Fingers]

Hi Richard,
Many thanks for your prompt and invaluable help. Both operations completed successfully:-

C:\WINDOWS\system32>DISM.exe /Online /Cleanup-image /Restorehealth

Deployment Image Servicing and Management tool
Version: 6.3.9600.16384

Image Version: 6.3.9600.16384

[==========================100.0%==========================]
The restore operation completed successfully. The component store corruption was
repaired.
The operation completed successfully.

C:\WINDOWS\system32>sfc /scannow

Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection did not find any integrity violations.

C:\WINDOWS\system32>

The other windows 8.1 machine is currently in use. I will start a new thread at a later date.
Once again, many thanks!

LMF

 

[niemiro]

That's really excellent news!

There's actually a good chance that your other computer is affected by the same issue. It's a very common Windows 8 bug affecting certain computers (it's actually this corruption: https://www.sysnative.com/forums/wi...prncacla-inf-corruptions-windows-8-8-1-a.html)

So...I suggest you run DISM on your other computer too. It certainly won't cause any harm. If it fixes it, great! If it doesn't, come back here and post some CBS logs :)

Richard

 

[Little_Micky_Fingers]

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

 

[niemiro]

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:

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

 

[Little_Micky_Fingers]

Hi Richard,

I can't thank you enough for taking the time to write such a detailed and lengthy reply. In the past on my XP and Win 7 machines I have changed certain permissions to try and understand how various types of malware manage to hide themselves. After a certain amount of time and experience some tasks become second nature. However, in this particular instance I was out of my depth. I'm further impressed at the speed and professionalism of your service. With the information that you have provided I have already managed to solve the problem with the other 8.1 machine. Fantastic!

Regards
LMF

 

[niemiro]

Hi Richard,

I can't thank you enough for taking the time to write such a detailed and lengthy reply. In the past on my XP and Win 7 machines I have changed certain permissions to try and understand how various types of malware manage to hide themselves. After a certain amount of time and experience some tasks become second nature. However, in this particular instance I was out of my depth. I'm further impressed at the speed and professionalism of your service. With the information that you have provided I have already managed to solve the problem with the other 8.1 machine. Fantastic!

Regards
LMF

No problem, I'm very glad to have been of assistance :)

It varies a little forum to forum, but you'll find it almost everywhere (and certainly here) that you don't have to have a problem to create a thread. By this I mean that you are always more than welcome to come and ask "why" or ask for something to be explained, just because you're curious. Not just in the Windows Update section here, but everywhere. You'll find that most members here are proud of their speciality, and really enjoy teaching it. I know that over here in the Windows Update forum, whilst I get some pleasure out of repairing the really common day-in, day-out SFC and 0x800B0100 error codes, I really come here for the rare stuff, the difficult & complex registry issues, and the occasional explanation that a member desires. Those are the best days :)

See you around!

Richard