In keeping with my ongoing Vista troubleshooting exercise, I’ve gotten into the habit of dropping in on my Event Viewer every couple of days to see what kinds of errors and warnings are popping up. By keeping tabs on this information, and researching stuff I haven’t seen before or don’t understand, I keep learning more and more interesting stuff about Vista. This morning, I found a new error from the Volume Shadow Copy Service (which shows up in the Windows Application log as a source named VSS). Because VSS is important to maintaining Vista operating and file system integrity, I started digging more deeply into this right away.
As the following Event Viewer screenshot indicates, the error occurs when the VSS attempts to respond to a calling program (that’s what brings the IVssWriterCallback routine into play). I followed the Event Log Online Help link to learn that I needed to run VSSAdmin to pin down the source of the error (and don’t forget to use the Run as Administrator right-click option on cmd.exe if you’re not actually logged into the Administrator account when you run this command). Those results appear in the command line screenshot that follows the Event Viewer snap below.
At first blush, this error message looks pretty ominous. Who wants a shadow copy write operation to fail?
Output from vssadmin list writers command shows no outstanding errors
Notice that the “Last error” status for all writers shown is “No error.” Careful reading of the Online Help file reveals the following passage: “If the command reports that all writers are operating without errors, this means that the error condition is not writer-related. In this case, you should contact the backup software vendor that created the VSS requester application.” Not coincidentally, this error showed up the very day that I finally got around to reinstalling Carbonite backup on my Vista production box, in the wake of my recent OS reinstall and the replacement of the following components: memory, system drive(s), CPU, and graphics card.
A bit of online research into this error showed me other users reporting similar problems with different backup programs such as Mozy, Carbonite, and Macrium, among others. I also found numerous postings that indicated this code can appear during regular VSS disk snapshot activities. Then I started following the time stamps as to when this event occurred and realized it happened right after I reinstalled Carbonite on my machine. It immediately wanted to back up the machine (as you might expect from a program that hadn’t been able to do its job since I rebuilt the system some three weeks before), which caused me to reimpose the backup schedule that turns it off between the hours of 7:30 AM and 10:00 PM when I’m likely to be using the machine. I’m pretty sure that what happened is the following: between the time I reinstalled the software and it started its first backup and when I disabled Carbonite, it had already initiated contact with the VSS service. But when the VSS Service tried to respond to that request, Carbonite had been disabled for the time being, and couldn’t respond to the callback request.
Bingo! One error message I don’t have to worry about any further. Also, a great explanation as to why this error occurred only once, and why my subsequent daily late-night scheduled Carbonite backups have gone without a hitch.
