windows:server_os:volsnap

no way to compare when less than two revisions

Differences

This shows you the differences between two versions of the page.


windows:server_os:volsnap [2019/10/31 09:06] (current) – created - external edit 127.0.0.1
Line 1: Line 1:
 +====== Fix VolSnap Error ======
 +If, in your Event Log, you encounter a VolSnap error
 +<code>The shadow copies of volume \\?\Volume{XXXXXXXX} were aborted during detection because a critical control file could not be opened.</code>
 +You might want to check if the system ran into Disk warnings and/or other service errors earlier. Those may be causing this as a consequential error or the error may result from having too many shadows or the host is simply taking too much time to create a VSS shadow.
  
 +There are several ways to fix this issue:
 +  * Check the logs for additional clues
 +  * Use vssadmin.exe to lift all VSS storage area limits to ‘unbounded’.
 +
 +<code bash>
 +Microsoft Windows [Version 10.0.10240]
 +(c) 2015 Microsoft Corporation. All rights reserved.
 + 
 +C:\WINDOWS\system32>vssadmin list shadowstorage
 +vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
 +(C) Copyright 2001-2013 Microsoft Corp.
 + 
 +Shadow Copy Storage association
 +   For volume: (C:)\\?\Volume{1d14ab39-af32-45bd-a7f8-8ba039aef229}\
 +   Shadow Copy Storage volume: (C:)\\?\Volume{1d14ab39-af32-45bd-a7f8-8ba039aef229}\
 +   Used Shadow Copy Storage space: 9,34 GB (1%)
 +   Allocated Shadow Copy Storage space: 9,64 GB (2%)
 +   Maximum Shadow Copy Storage space: 10,0 GB (2%)
 + 
 + 
 +C:\WINDOWS\system32>vssadmin resize shadowstorage /For=c: /On=c: /MaxSize=UNBOUNDED
 +vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
 +(C) Copyright 2001-2013 Microsoft Corp.
 + 
 +Successfully resized the shadow copy storage association
 + 
 +C:\WINDOWS\system32>
 +</code>
 +  * Or use vssuirun.exe to lift all VSS storage area limits to ‘no limit’.
 +{{ :windows:server_os:vss1.png |}}
 +  * There may be an excessive number of VSS shadows on the host. If you’re not using any other backup tool it’s safe to delete them all, using **vssadmin delete shadows /all**
 +  * Use VSSUIRUN to check if there is a schedule that automatically creates these shadows. It’s common when the Windows feature ‘system restore’ is being used. The ‘next run time’ column in VSSUIRUN next to each drive listed should say ‘disabled’. You should disable all schedules if you find any
 +{{ :windows:server_os:vss2.png |}}
 +  * If the issue has to do with VSS snapshot timing please check if the following key exists in the host’s registry:
 +    * **HKLM\Software\Microsoft\Windows NT\CurrentVersion\SPP\CreateTimeout**
 +    * The “CreateTimeout” key should be added as a DWORD 32-bit, and it’s value is in milliseconds. On a busy host you may want to shoot for a value of 1200000 => 20 minutes.