Useless to most, not useless to some.
1. First thing I am asked to do when there is a windowsupdate detection problem is to enable full logging on Windows update
http://support.microsoft.com/kb/902093/en-us
"
Microsoft Product Support Services may ask you to turn on verbose logging. To turn on verbose logging, add the following registry key with two values:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace
Value name: Flags
Value type: REG_DWORD
Value data: 00000007
Value name: Level
Value type: REG_DWORD
Value data: 00000004
This registry key turns on an extended tracing to the %systemroot%\Windowsupdate.log file. Additionally, this registry key turns on an extended tracing to any attached debuggers."
You do that and there's a ton of stuff in the log file that engineers can then tell what the client is doing/talking to what server/detection etc etc. Most often used for detection questions.
Then there is the problem of
- Hexidecimal error codes. In a perfect world Windows update (or Microsoft update if you flip over to it) works automatically and in the background. So the Windowsupdate.log and the CBS.log (component based servicing) log files are not meant to be read
by normal human beings because it should just work without issue. Thus the log files and primarily cbs log files are deep and geeky and have lots of technical content that you either have to be an engineer or read a lot of log files to understand what is
going on. The intent here is that they are not client facing - it's supposed to just work - and often it's a matter of resources. You as a user spend time on the client facing stuff, you aren't supposed to be deep in the windowsupdate log because (again
in theory) it's supposed to just work.
3. The reality is it doesn't work perfectly all the time and thus we are faced with these really annoyingly cryptic hex error codes that we all google our brains out. (Microsoft you really really need to make your help messages more human friendly because
one of the basic windows update errors occurs when the time clock is off on the PC. When this happens, WU won't work because SSL certs won't work. Instead of having a nice human readable "yo, dude, go check your clock" or better yet self fixing it (I mean
that's what syncing time to time.windows.com is all about), it throws up an hex error code that if you can't get on the web - because your time clock is off - you can't google/bingle up the error code resolution that your time is off. The number of times
I have been bitten by that, I can count on two hands. And every time it happens and I roll my eyes and wonder if just that one error code could be made more human readable.
Some resources to help you better understand and resources for error codes are:
http://support.microsoft.com/kb/902093/en-us
http://inetexplorer.mvps.org/archive/windows_update_codes.htm
http://technet.microsoft.com/en-us/library/cc720442(WS.10).aspx
4. There was a product team guy that used to blog a lot about component store servicing and you could delve into the comments and understand more of what was going on.
http://blogs.technet.com/b/joscon/ Unfortunately he's no longer blogging about CBS (he's moved on to another team) but if you want to read old posts that give deep info, it's still a good resource.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
