For Build 17017 of the Insider Preview at least, and possibly for other recent Win10 builds or releases, a runtime error involving volsnap.sys may appear. These days, such errors are called “GSODs” because the screen that reports the problem is green. But I see reports of similar issues all the way back to Windows 7 days (when the error was called a BSOD, for “Blue Screen of Death”). Thanks to some nice detective work from Scot Hanselman, though, I knew just what to do when my Dell Venue Pro 11 hybrid PC fell prey to this problem. And as it turns out, Fixing Win10 Volsnap.sys issues is pretty simple, as long as you’ve got the right ingredients.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
On the GSOD, an unhappy face emoticon sez the OS knows something ain’t right…
Ingredients for Fixing Win10 Volsnap.sys Issues
You need two things to address this problem. First, you need a known good working copy of volsnap.sys. I grabbed mine from one of my production PCs running the latest 1709 release. For the record, it lives in the %windir%\System32\Drivers folder. Second, you need a bootable Windows 10 installation or repair disk. I used the 1709 Windows 10 installer I built last week with the Microsoft Media Creation Tool (click “Download tool now” on the Download Windows 10 page).
Fixing Win10 Volsnap.sys Issues at the Command Line
The problem with replacing OS runtime files is that the OS that’s running, for all kinds of good reasons, won’t let you replace them while it’s running. You must instead boot to the install or repair media and make the replacement at the command line prompt therein. Because I used an MCT-based UFD, I booted to that drive, let the auto-start feature fire up the installer, then elected to repair an existing installation on the second screen in the sequence. From there, I took the Troubleshoot option, then opened the command prompt where I was quickly able to make the switch. To make my job as easy as possible (and following Scott’s suggestion from the afore-cited blog) I had already copied the known good working volsnap.sys to the root of the UFD from whence I’d just booted.
Here’s the sequence of commands I used to get myself going:
rem this opens the disk partition utility so you can identify installed disks
- list volumes
rem shows you the letters associated with disks on your PC
rem for this example C: is my OS disk, E: is the UFD I need to copy from
- cd <s>:\Windows\System32\Drivers
rem navigate to the proper directory for file replacement
rem <s> is the drive letter for your actual OS drive
- ren volsnap.sys volsnap.bak
rem keeps the old, broken version around under a different name
- copy e:\volsnap.sys volsnap.sys
rem copies the known good working copy into the proper directory
After you copy the good copy into the right directory, you can exit Command Prompt and restart your PC. When it resumes operations, any problems resulting from the damaged or buggy copy of volsnap.sys should be fixed. In my case, I immediately upgraded to Build 17025 on the affected PC. So far, no similar reports of volsnap.sys issues are reported for this more recent OS version.