win7 update,unknown error.help!

karlsnooks said:

niemiro,

If we are looking for system files which SFC could not repair, then alll we need is the output of findstr as explained by Brink in his tutorial.

those cbs.log files can become very large and unwieldy as they are 99% success reports and all we need is the one percent that Brink explains how to extract.

Hello!

I still want the whole CBS.log. If you look at the actual error code given by the OP, to actually view details about what caused the error code, you need to look at the whole CBS.log.

I really seem to be fighting a losing battle here, but when I fix things in a CBS.log, I do things my way. SFC is useful, but CBS.log is more useful. The details as to why CBS failed the Windows Update is FAR more important than SFC ever is.

Nobody will ever convince me to use a parsed log again (I know that you never suggest this, this is not aimed at you, karlsnooks, but a log which is outputted to the Command Prompt is wordwrapped, and so messy that I won't even waste time reading them any more, and the top is chopped off.)

Originally, when I first started using SFC logs, I used a parsed log and an MD5 scan. But this wasted a lot of time. I now use the whole CBS.log and save myself a lot of time. I scroll down the whole log with the slider in about 10 seconds, looking at the line lengths and shapes, and this way find the relevant sections. Oh yes, it takes practice, but it speeds things up immesurably. SFC sections are incredibly distinctive. I can find them in seconds. I page down to the bottom of the SFC section, and know the result in less time than it takes to parse the log, let alone parse and read the log.

So, 10 seconds towards SFC, then I go to the bottom, and search upwards for "Error ", with that space.

This is the most important part, and is lost in a parsed log (as are useful details about SFC)

I really sound like a broken record, but I have been there, done that, with parsed logs, and now that I am better, I always use the whole CBS.log.

Richard

karlsnooks said:

Have you had an opportunity to read Brink's tutorial?

Yes, and I used to use it (and anyway, Brink just takes it from Microsoft eg: How to use the System File Checker tool to troubleshoot missing or corrupted system files on Windows Vista or on Windows 7 and other KB articles, eg: http://support.microsoft.com/kb/928228) but you will never persuade me to use it again (except to show the OP how to actually run SFC)

P.S. The Microsoft KB article on analysing SFC logs is incredibly bad. Absolutely awful. Which is why I have my own tutorials which I can PM to people when I want to, which are far more comprehensive. Also, there are many, very many, subtitles of SFC which are completely ignored. (eg "manifest may be corrupt(TRUE)" and "manifest may be corrupt(FALSE)", what these actually mean (usually there is no corrupt manifest no matter what that message says), when SFC fails with "failed to compete the repair operation" and how to fix it (you have to use the whole CBS.log, the parsed log parses out the failure reason!), how to replace hard links in winsxs, how to check that SFC has not falsely identified a corrupt file, how to repair a whole winsxs folder, how to tell when SFC could have replaced the file had it not been in use, if there is a good copy on the computer, if there isn't, which way around the hard link lies etc. etc. etc.

When I started off, I read that KB article, and jumped straight in. Now that I have the experience, I use the whole CBS.log. *Please will people lay off me for using the whole CBS.log.