VSS failed to initialize for directives, error=0x80070002 : The system cannot find the file specified.

Hi Carlos,

Thanks for your fast answer.

This is NO cluster client. I found all the articles you mention, but the do not match :-(.

It is not one file or directory that is missing, but a whole drive.

Unfortunately it is not possible to copy - paste in this editor otherwise I would have copied the whole error I received whit -D 9, but now I have to type a part of the  message:

....

VSS .. adding D:\ to mountpoint table. .. GUID .. \\?\Volume{......

VSS .. adding G:\ to mountpoint table. .. GetVolumeNameForVolumeMountPoint failed - error 2

VSS .. Required volume for writer M, Component N was not added during InitializeVolumeTable - 0x80070002

And then comes the error that I mention in the header.

There is no G:\ drive in the system. I performed a search on G: using regedit, but nothing found.

I realy don't know where save is getting the information that there is a G:\ drive, do you have any idea?

Kind regards

Felix

Hello Felix,

Is that client a cluster?

This threat has been treated in several posts, in fact a simple search support could give you the answer.

This is a known error message (means "file not found"), and can be caused for different reasons. The most common one is when a piece of software is uninstalled, and the files were in fact removed, but the registry was not cleaned properly then, when VSS checks the registry it still finds pointers to some files but, as those were removed during the uninstallation process, VSS fails to identify/find those files and backup fails.

One of the workarounds provided is to use the following backup command for that client:

save -a '"ignore-all-missing-system-files=yes"'

Please copy and paste, as the syntax has to be exactly this one (Single quote+double quote+ignore-all-missing-system-files=yes+double quote+single quote)

If this is a cluster then the solution is different, as it's a known Microsoft issue and there is a fix for it, as described in http://support.microsoft.com/kb/980794

The problem with clusters is that, if there is a service or application running on a shared disk, and you are backing up the passive node, VSS tried to access those files to back them up but, as you are baking up the passive node, it doesn't have access to the active disk, as it's being locked/owned by active node.

Thank you.

Carlos.

I think reference to G drive comes for LUN which was created for snapshot.  This is known issue with VSS and there is a patch by MS (reference http://support.microsoft.com/kb/833167).

Please review the following articles from Microsoft.  Typically the cause of the issue is solved with the correct hotfix.:

Windows Server VSS issues:

Below are some articles that should be reviewed by a Windows server administrator. These articles pertain to VSS and possible issues that may occur.

Knowledge base articles - known Windows 2003 VSS issues:

A Volume Shadow Copy Service (VSS) update package is available for Windows Server 2003 - Last Review: July 2, 2010

http://support.microsoft.com/kb/833167

Exchange VSS backup fails on an Exchange Server 2003 server - February 20, 2010

http://support.microsoft.com/kb/924262

Various issues may occur on a Windows Server 2003-based computer that is running the Volume Shadow Copy Service - April 27, 2010 - April 27, 2010

http://support.microsoft.com/kb/940032

Exchange Server 2003 data backup and Volume Shadow Copy services

http://support.microsoft.com/kb/822896

Knowledge base articles - known Windows 2008 VSS issues:

VSS snapshot creation may fail after a LUN resynchronization on a computer that is running Windows 7 or Windows Server 2008 R2 - November 25, 2009

http://support.microsoft.com/kb/976099

Backup fails with VSS Event ID 12292 and 11 on Windows Server 2008 and Windows Server 2008 R2 - January 20, 2010

http://support.microsoft.com/kb/2009513

No VSS writers are listed when you run the “vssadmin list writers” command in Windows Server 2008 R2

http://support.microsoft.com/kb/2009550

http://support.microsoft.com/kb/2009533

Windows 2008 R2 64-bit backup failed

http://solutions.emc.com/emcsolutionview.asp?id=esg108377

General VSS articles to review:

The backup process may fail and a time-out error may occur in Volume Shadow Copy Service writers

http://www.winserverkb.com/Uwe/Forum.aspx/windows-server-sbs/77862/VSS-Writer-errors-during-backup

Event ID 9840 or 9607 is logged when a VSS backup operation fails in Exchange 2007 or in Exchange 2003

http://support.microsoft.com/kb/930800

Best Practices for Using Volume Shadow Copy Service with Exchange Server 2003

http://technet.microsoft.com/en-us/library/aa996004(EXCHG.65).aspx

Error message: "Not enough server storage is available to process this command"

http://support.microsoft.com/kb/106167

Mark

HI Mark,

Thanks for this information.

I will have a look at these, but I forgot to tell that I can create shadows without problems using vssadmin

vssadmin create shadow /for=C:

vssadmin create shadow /for=D:

These commands work fine, vssadmin lists these shadows and I can delete them without problems.

vssadmin list writers

All writers are stable and no error.

My problem is, where does save gets the information about a (none existing) G:\ drive.

Somebody just told me that a long time ago an external USB diskdrive was connected to the system, but this has been removed months ago.

Kind regards

Felix

OK - here are a couple of things that may help:

vssadmin delete shadows /for=g: /all

where g: is the drive letter that needs to be resolved

Also,  I have found out that in Windows 2008 vshadow has been replaced by Diskshadow

DiskShadow.exe is a tool that exposes the functionality offered by the Volume Shadow Copy Service (VSS). By default, DiskShadow uses an interactive command interpreter similar to that of DiskRAID or DiskPart. DiskShadow also includes a scriptable mode.

This replaces vshadow, which is used in Windows 2003.  There is an SDK for vshadow. This SDK allows:

- create, delete, query non-persistent shadow copies

- enumerate writers and their components

- select components for backup/restore, notify writers.

- executing a backup/restore CMD script

- Assigning a drive letter, a mount point or a share name to a shadow copy.

- Creating persistent vs. non-persistent shadow copies

- Creating shadow copies without involving writers.

- Hardware shadow copies - creation, import, break, deletion. (only for Advanced Server or Datacenter SKUs)

Now, this all being said, what I have found is that this occurrs from time to time with USB drives that removed without properly ejecting them first.  I beleive that if you run the command vssadmin delete shadows /for=g: /all that you should be able to address your issues.

Let me know how you make out.

As always, use caution with a command or tool you are not familar with.  If used incorrectly, unexpected results may occur.

Use at your own risk.

Mark

Hi Mark,

All vssadmin commands I try for drive G: reply that this is a none existing drive.

But I think you gave me a good tip. Probably when people removed the USB drive, they didn't eject it first (remove hardware safely). and Windows probably thinks this drive is still connected. We laready rebooted several times, because this was also one of my first thoughts (as usual with VSS related problems ).

We are going to reconnect another USB drive (the original is lost) and properly remove it, reboot and try the save again. "save -D 9 -n -s C:\" already shows the error.

I will keep you informed.

Kind regards

Felix

Hi,

We did some further testing today.

We connected a USB drive and assigned it drive letter G:, result, save ran fine.

We assigned a different drive letter to the drive (e.g. F:) backup fail, save wants a drive letter G:.

We did a search on the complete registry, there is nothing the points to a drive letter G:, although we found refferences to drive letter F: which was still connected.

To Hrvoje, there was no LUN connected to drive letter G, only USB drives with FAT files systems, so no shadow copies possible.

I think I am going to open a SR. I need to know what function/call/command save is using to find out what drives are connected to the system, once we know that we can escalte this with Microsoft.

Hi,

Using vshadow that Mark pointed out can help you determine which of the VSS writers have references to a component on the G-drive.

So you can run vshadow and list the writers metadata. You should get a list of files associated with each writer with vshadow -wm2 but take a look at the reference first http://msdn.microsoft.com/en-us/library/bb530725(v=vs.85).aspx

Rickard

Thanks Rickard,

I downloaded SDK V7.2 and will install it on the system.

Using vshadow I will try to find out if any of the writers still as a path that points to the G: drive, I think the MSDE writer is a good candidate :-).

I will keep you informed.

Kind regards

Felix

Hi,

vssadmin list writers

Works fine and tells me all writers are stable and no error.

vshadow -ws

produces the same error as the NetWorker save command....

I attached a screenshot, because copy - paste doesn't work with this editor.

I think I will pass this on to Microsoft .

Thanks for your help.

Felix

Hi Felix,

Could you please run vshadow again with the /trace option and share with us the results?

Also maybe a good idea would be to enable VSS traces as per MS:

http://support.microsoft.com/kb/887013

and share results, if you don't mind.

Thank you.

Carlos

HI Carlos,

Thanks for the advice, but I already tried adding the /trace and I didn't get more information.

I will try to enable VSS traces and share the result.

Kind regards

Felix