I mentioned a while back a weird-looking event log entry:

Event Type: Warning
Event Source: VSS
Event Category: None
Event ID: 12290
Date:  8/30/2004
Time:  12:37:19 PM
User:  N/A
Computer: SomeMachineName
Description:
Volume Shadow Copy Service warning: GetVolumeInformationW
(\\?\Volume{57d9017d-f07e-11d8-8e52-505054503030}
\,NULL,0,NULL,NULL,[0x00000000], , 260) == 0x00000005
hr = 0x00000000.

The error code (0x00000005) is the return code from the GetVolumeInformation API on the volume with the name \\?\Volume{57d9017d-f07e-11d8-8e52-505054503030} (you can see the correspondence between volume names and drive letters by running the MOUNTVOL command).

 

What this means in the context of VSS? Let's assume that you set up Y: to be the shadow storage for volume X: (i.e. when X: is shadowed, the shadow copy files for X: are stored on Y:). There are several cases that can lead to this error:

1) If the error is 0x00000005 (i.e. ERROR_ACCESS_DENIED), then you either do not have sufficient access rights on the corresponding volume (X: or Y:) for the Local System account, or there is an application (Chkdsk or Format) which acquired exclusive access to the volume. Make sure that Local System has enough access rights to the root.

2) If the error is 0x00000002 or 0x00000003 (i.e. ERROR_FILE_NOT_FOUND or ERROR_PATH_NOT_FOUND), then one of the X: or Y: volumes are missing.

 

As I already mentioned in my previous post, this is one of the classical cases where the code calls a Win32 API which is not supposed to fail (or at least the programmer that wrote the code did not expect the API to fail). But it turns out that in reality this API does fail in some ways that were not anticipated. That's why it is important to have a good feedback loop between the PSS engineers and the development team...