Now that I’ve been living with Vista SP2 for three whole days, I’m getting some experience with the new environment on some production machines. I did encounter a situation where SP2 froze at 48% through its Phase 1 (of 3) changes prior to the restart between Phase 2 (before restart) and Phase 3 (post restart), but a reset on the machine caused it to start over with Phase 1, after which the entire remaining process completed successfully. Having made a complete backup before starting, and wondering if the admonition not to power off the PC while in process was as dire as stated, I was both surprised and pleased that the SP application proceeded and succeeded on a second try without having to restore the backup and start over. Is it possible MS has improved its SP application tools?
At any rate, with the SP now in place I’m watching my systems closely for stability and reliability. I’ve also dug into the System and Application logs in Event Viewer to see if some of my chronic and persistent errors have been addressed by the new service pack. Without conducting a complete exhaustive analysis, my observation is that some have been addressed, while some have not.
Here are some details. Prior to the SP2 application, I had a decent-sized laundry list of recurring errors for which I could find no fix, but which also didn’t seem to adversely affect system stability and usability. Here’s a summary table for these items:
|Critical||DriverFrameworks-UserMode||10110||A UFD has a flaky driver|
|Warning||Servicing||4374||KB955430 not applicable to my system|
|Warning||Time Service||36||No synchronization occurred in last 24 hrs|
|Warning||Tcpip||4226||Limit of concurrent TCP connect attempts reached|
|Error||HttpEvent||15016||Unable to initialize Kerberos for server side authentication|
Of these items, I see some have disappeared, and others have morphed slightly (and more informatively) into altered forms. The time service error remains unchanged (but it always works when I synch manually, so I’m not worried about it). The UFD error code persists, but also gets a new companion code 10111 that explicitly identifies the offending device by name. Because it always works when I plug it in, my workaround here is just to remove the device whenever I finish using it. 4374 (update not applicable) has gone away completely, and 15016 (Kerberos not initializing) shows up only once (it used to appear daily) . 4226 (TCP connect attempts) hasn’t showed up, either, but this usually occurs when I’m using FTP and I haven’t done so since applying SP2. That means I give SP2 a 20-40% improvement score on those “pre-existing conditions.”
As you might expect, however, I also see some new recurring items in the Event Viewer that I didn’t see before applying SP2. I summarize these in the next table:
|Error||Service Control Manager||7000||Windows search service failed to start in timely fashion|
|Error||DistributedCOM||10005||Error 1053 when attempting to start WSearch|
|Error||BitLocker-Driver||24620||Volume information on N cannot be read|
The DCOM error is one I’ve seen before and relates to Windows Search attempts to index items that are no longer present (hence an empty search target in the error message detail), and ties of course into error 7000 as well. Likewise, Volume N relates to the UFD with the driver problems. All of these are items I can live with (and if I can figure out my search target issue for Windows Search) maybe even do away with.
My final analysis on SP2 for chronic errors: “So far, so good!”