Mounting Shadow Volumes

We’ve built our SEAT VM and added our target image to it as a virtual disk.  The first thing that I do is verify that all of the shadow volumes are present.  My first post presented a screen shot from the image file (MyImage) and depicted the shadow volumes.  We can compare the shadow volumes from the image file with those in our VM.  The following video presents the steps we use to enumerate the shadow volumes with the native vssadmin command run from our administrative command prompt.

The screen populates quite quickly, but the point is that we can identify the number of shadow volumes and their respective creation dates.  To make it easy to copy, here’s the syntax: vssadmin list shadows /for=[your target volume letter followed by a colon].  Note, too, that your beginning shadow volume number will be different from mine and does not necessarily start with the number one.  Another trick is to re-run the command and export the output to a text file, by adding a space at the end followed by >[path to your text file] [name of text file]. Creating a text file is handy for documenting your findings and for copying the shadow volume names, which we’ll do later.

Now we can mount any or all of our shadow volumes for examination.  We’re going to use VSS, which is a free, command line tool written by Dan Mares, who is a creative, long-time forensic software developer and examiner.  Dan also has developed free tools that are adjuncts to X-Ways Forensics and which help users customize certain reports.  You can pick up a copy of VSS at  Be sure to check for updates, as Dan is great about implementing suggestions.  You’ll also want to check out his other tools.  Thanks, Dan!

There are a few of ways in which we can use VSS.  We can mount one shadow volume; multiple shadow volumes that are numbered consecutively; or multiple, non-consecutive shadow volumes.  The following screenshot displays the syntax.

We already have a list of shadow volumes produced by vssadmin.  It’s now a matter of selecting the correct volume to provide to VSS.  Let’s go back to an abbreviated view of vssadmin’s output.  

The screenshot identifies one shadow volume.  It may not be terribly clear, but the shadow volume path is \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5. We’ll feed that path to VSS and mount the shadow volume.  We need only choose an unused volume letter, and we’ll pick H:

After executing the command, VSS will prompt us to hit <Return> one more time and then present what the screenshot depicts.  It includes the root directory listing.  Our shadow volume (#5) now is mounted as Volume H:  You can repeat that process and mount any, or as many, shadow volumes as remaining drive letters permit.

Hint: to repeat the process, use your up-arrow and simply replace the volume letter and shadow volume number (#), i.e., ShadowCopy[#].  There is no need to copy/paste the entire path repeatedly.

Next, we’ll mount a range of shadow volumes.  First, let’s look at the syntax, which is provided in VSS’ on-screen help.

We can start with a given shadow volume and mount every shadow volume that follows, up to our choice of the last shadow volume number.  In our case, there are 19 shadow volumes and the first is #5.  (I haven’t researched the question of why shadow volume numbers often start at a number greater than #1, but it doesn’t appear that it’s because there were X previous ones.  Windows authority Troy Larson probably knows!)  Before we go forth, I want to point out that you should study the dates of the shadow volumes in relation to your case.  Several restore points can be created on the same day, perhaps within hours of one another.  You’ll cut your exam and VM overhead if you exercise some judgment in picking the shadow volumes to mount and examine.

For demonstration purposes, let’s mount them all. I’ll start with no shadow volumes mounted and enter, vss h: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5 23 AUTO.  Note that AUTO is upper case.  The first shadow volume is #5, and the last is #23.  Watch:

Actually, it was coincidental that I happened to have 19 shadow volumes and 19 open, consecutive drive letters 🙂  To unmap any or all of our shadow volumes, we proceed as in the following screenshot.  I’ll unmap them all.

Following the VSS command, you enter every volume letter, followed by a colon, which you want to unmap.  If unmapping seems to hang, just refresh your screen in Explorer with F5.

That’s it for this post.  Next time, I’ll demonstrate one or two exam approaches with X-Ways Forensics. In the meantime, if you get bored, you’re all set to examine your shadow volumes with any tools that you wish to install in your SEAT workstation.


  1. Isaac Gonzalez says:

    this saved me when I was unable to restore via the gui with a domain admin user(got access denied as these were Group policy based Folder Redirected folders/files). I ran cmd as system and then ran this tool and was able to mount the system restore and copy out what I needed. I read that mkdir /s \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyxxx should work but I got parameter incorrect when I tried to access this symlinked directory…great tool!!

  2. […] shared it.  In fact, I initially used information from his 13 Jul 2012 blog post entitled Mounting Shadow Volumes to mount the VSC of interest as a RAM disk on my analysis system.  At the time that I did […]

  3. […] where Jimmy’s blog post on mounting shadow volumes can into play.  Using vss.exe, I added the VSC in question to my analysis system as X:, which […]

  4. […] where Jimmy’s blog post on mounting shadow volumes can into play.  Using vss.exe, I added the VSC in question to my analysis system as X:, which […]

  5. Raffael says:

    How do you examine VSS on deleted/recovered partitions?

    • jimmyweg says:

      I’ll have to guess, as I haven’t done that. First, I’ll say that you can’t examine deleted shadow volumes, AFAIK, and I tried. For example, you can recover a deleted SV and copy it into the Sys Vol Info directory. That doesn’t work, and may screw up the shadow volume service. Remember that the SVs are difference files, and the “index” has to track the SVs as a whole to rebuild things. Throwing in a “foreign” SV seems to mess up the system.

      If you can recover a deleted, intact partition, I suspect that you can image it and create a VM or VMware virtual disk from the image. If you can do that, you can probaly add it to your SEAT workstation and see whether the VSS can rebuild the SVs. You also may be able to rebuild the entire physical disk (image) and boot the previously deleted partition.

      • Cal says:

        Hi, nice blog!
        What about an old snapshot of the same, working partition? I mean, every once an older shadow copy is deleted to create a newer one, due to space constraints to the VS service; however, sometimes a deleted snapshot can be recovered with a raw access to the disc, and .LOG# files in Sys Vol Info dir should hold some infos on syscache.hve changes.

        I wonder if there is a mean to verify integrity of such a recovered shadow and to access it.

        • jimmyweg says:

          The snapshots depend on linking. After deleting snapshots within a VM, VMware typically has no problem with running the VM from any given snapshots. Forensic tools, however, may be unable to mount the successive snapshots because of linking issues, I suspect. I’ve found it rather difficult to gather much any data from deleted (recovered) VSC, because the dependencies are lost.

  6. Ken Pryor says:

    I’m really enjoying and learning a lot these tutorials, Jimmy. Thanks for sharing!

  7. Raffael says:

    Hi Jimmy
    Thanks for your work!
    I usually mount disks with Encase PE. This allows to access VSC directly in my workstation (no vm). This approach does not work if you use Ftk Imager or Mount Image Pro .

    Looking forward to reading more of your posts!

    • jimmyweg says:

      Thanks very much, Raffael. Correct, mounting with FTKI or MIP will not provide access to the SVs. I don’t use EnCase, so I can’t speak to this feature, but it does seem handy. Another approach, which I’ll describe in a leter post, is mounting a VHD image. The drawback is that you have to create a VHD. If you do, however, you can access the SVs right from your host system.

      • Jimmy,

        I’m not sure how I follow that creating a VHD is a “drawback”, per se. Analysts work on a copy of the acquired image, and not the original “evidence”, and the free tool available from MS simply appends a footer (less than 1K) to the image in order to turn it into a VHD. Once you’ve done that, you can still access the acquired image via FTK Imager, etc.

        Thanks for posting this information…it’s great to see more of this sort of thing making it into the public view. Keep it up…

        • jimmyweg says:

          Thanks, Harlan. Yes, converting the dd to VHD actually is quite simple with VhdTool. In my approach, I use the original image, which is not altered. If I want to convert the image to VHD, I guess that I would make a copy for that purpose, unless you can convert the VHD back to dd, but then you’d want to hash the original again. So, although I do have one or two backups of every dd (as E01) image, having to make another to convert to VHD is something I’d rather avoid. You can build your VMware device in less than one minute. Perhaps someone may develop a tool to image a medium directly to VHD with the approriate verification, something like E01. AFAIK, that’s not do-able at the moment.

Leave a Reply

Your email address will not be published. Required fields are marked *