A potential issue has come to my attention concerning dual-boot configurations, where multiple operating system volumes are installed on the same computer. This issue can affect the integrity of incremental backup image files. Fortunately there is a simple workaround. I'm going to describe both the issue and the workaround as well as I can.
When ShadowProtect backs up a volume, it either creates a full backup of all of the in-use sectors on that volume, or it creates an incremental backup which contains only the sectors which were modified since the previous backup occurred. An incremental backup is therefore dependent upon the previous backup image file. Now when ShadowProtect creates an incremental backup it can use one of two methods to do this. The first (preferred) method is that ShadowProtect uses the stcvsm.sys driver's "incremental change tracking" feature to instantly determine all of the sectors which have been changed since the last backup. stcvsm.sys maintains a very efficient list, in RAM, of the sectors which have been changed since the previous backup, and this list of changed sectors can be used to make a new incremental image file very quickly (often in seconds). The other technique (less preferred because it is far slower) is for ShadowProtect to compare all of the current data on the volume with the data in a previous backup image file and to then make a new incremental which contains the sectors which are different (and hence were changed). This "comparison" technique we often call a "diff," and an incremental which is created with this technique we will call a "differential." A differential in ShadowProtect isn't necessarily directly dependent upon a base/full image file. A ShadowProtect differential can be dependent upon any previous image file (including the base or some earlier incremental). It's easiest to just say that a ShadowProtect differential is simply an incremental which was created with the diff/comparison technique rather than the fast/incremental-change-tracking technique. When a backup job which includes incrementals is created in ShadowProtect, the in-RAM incremental-change-tracking is turned on in stcvsm.sys in order to provide fast incrementals for that job. The change list is kept in RAM so that it does not affect system performance. The drawback of this is that if the system crashes, that list of changes in RAM is lost, and so the next incremental has to be generated using a diff technique and so it'll take about as long as a base/full to be created. The incremental following it will be back to the fast technique. If the system is gracefully shutdown, then stcvsm.sys writes that in-RAM incremental-change-tracking information to a .IDX file in the root of the volume which is being monitored. This map is then read back into RAM when the system boots. Here lies the crux of the issue. If you are on a dual-boot system, and you have ShadowProtect installed one one of the OS volumes, but not on the other, then when the OS volume on which ShadowProtect is NOT installed is booted, the user can make changes to a volume for which incremental change tracking was occurring in the other OS volume, and those changes will be made without the knowledge of stcvsm.sys on the other OS volume. When you boot back into the volume where ShadowProtect is installed, if you then create a fast incremental backup image file, that incremtnal will not contain the sectors which were changed during the boot session of the OS on which ShadowProtect is not installed.
Fortunately the workaround is easy. Install stcvsm.sys on all installed operating systems (I'll provide details below on how to do this - it's a simply file copy and import of a .reg file). This workaround will not work if one or more of your operating systems are not supported by stcvsm.sys (see the supported list below). In a case where you have an operating system installed which is not supported by stcvsm.sys then you should not use any job types that support incrementals unless you are 100% positive that no changes can be made to the change-tracked volumes when you are booted into an OS on which stcvsm.sys is not installed. For instance, if you have a Windows partition and a Linux partition, as long as you don't mount your windows FAT32 and NTFS volumes within the Linux boot sessions then you can safely use jobs that have incremental tracking capability within the Windows OS.
Operating systems that are supported by stcvsm.sys are:
Windows NT4 SP6a (x86)
Windows 2000 (all flavors)
Windows XP (all flavors, including 32-bit and x64 versions)
Windows Server 2003 (all flavors, including 32-bit and x64 versions)
Windows Vista (all flavors, including 32-bit and x64 versions)
Windows Server 2008 (all flavors, including x64 versions)
To install stcvsm.sys, simply locate the version of stcvsm.sys in the attachment which matches your platform and copy the stcvsm.sys file to the System32\drivers directory. Then import the attached .reg file. Finally reboot.
As long as you install stcvsm.sys on all of your boot volumes and then reboot BEFORE you create a job with incrementals, you will be safe and your incrementals will all be solid. If you already have a multi-boot system and already have created backup jobs with incrementals then install stcvsm.sys on all of your boot volumes and reboot and tell all of your existing backup jobs to create new base/full image files.