Problem caused by VSS Doctor
This is obviously not a problem caused ATI 2020, but I don't know where else to post this cautionary tale. This problem happened after doing some research related to topic
"First backup puzzling completion process". (I apparently cannot include a link to that topic.)
In the past I had noticed that the VSS Doctor's "Assign drive letter" function will use an already assigned drive letter if the drive letter is not assigned to an actual volume. I have E: assigned to a virtual drive. I used SUBST to assign E: to a directory on a NAS. However, VSS Doctor (apparently) sees E: as an unused drive letter and "Assign drive letter" will assign it to an unmapped partition. This causes no problem for programs using the original (virtual drive) E:.
At least, it never caused a problem in the past, but this time I forgot to do an "Unassign drive letter". After a reboot E: was permanently assigned to a previously unassigned recovery partition and I no longer had my virtual drive.
Luckily, I found a description of the Windows command Mountvol on the web and was able to do "Mountvol E: /p" to get rid of the Acronis use of E: and reassign it to my virtual drive.
Now VSS Doctor no longer sees the recovery partition and Disk Management sees a couple completely empty unlabeled partitions. I hope everything is going to be OK after another reboot.
Update:
Well, I don't know if I have a problem or not. Disk Management says I have a 510MB Recovery Partition with 501MB free space and a 100MB EFI System Partition with 100MB free space. However, I was able to reboot with no trouble so I suspect the EFI partition is really not empty, and "reagentc /info" says the Windows RE status is "Enabled" so I guess I'm OK.
Patrick, is the "First backup puzzling completion process" topic the one about having Q: assigned? I've been looking for that one as I had posted the possibility of using mountvol /r and was curious as to the result of that.
Also, do you have a comparison point for the Disk Management output. It sounds like there is nothing amiss there and was probably like that before.
EDIT: Never mind. I just found that topic so I was able to see some responses.
Steve Smith wrote:... when assigning any drive letters, it is best to go to the end of the alphabet and work backwards as that is least likely to clash with any other assignments which start from the other end!
Unfortunately, VSS Doctor did not give me the option of picking the drive letter; it picked it for me. Maybe I've missed an option somewhere.
BrunoC wrote:do you have a comparison point for the Disk Management output. It sounds like there is nothing amiss there and was probably like that before.
Ah. I obviously should have checked. On another PC I also see Disk Management claiming the Recovery and EFI partitions are completely empty. I guess it just can't tell.
Patrick,
As you have found it is normal to see EFI System partitions showing as empty in Disk Management. In the case of EFI boot files those files are contained in bootmgr file which is a locked file meaning it cannot be deleted normally. In addition, files within these partitions are carry the hidden attribute so it appears that there is nothing there.
Your issue with VSS Doctor assign drive letter is interesting. I would say that the tool assigned letter E: because at the time your virtual drive was not mounted. Had it been mounted then the tool would have moved on to the next available letter.
Having said that I wonder if your virtual drive will mount successfully now? You do not mention trying that to see here. I suspect it works though as it is probably allocated on your C: partition when mounted. Using the mountvol /p switch resulted in an unmount of the system partition. I think the /d switch would have removed the drive letter assignment and left everything else unchanged.
You might wish to consider using Diskpart automount scrub command on your OS system disk. That command removes volume mount point directories and registry settings for volumes that are no longer in the system. This prevents volumes that were previously in the system from being automatically mounted and given their former volume mount point(s) when they are added back to the system. Because of this when a volume is subsequently added to the system Windows will create new entries in the registry for that volume. As a result if there is anything abnormal with your EFI System partition as a result of your experience, which at this point I do not think there is, a scrub should return things to normal.
Enchantech wrote:Your issue with VSS Doctor assign drive letter is interesting. I would say that the tool assigned letter E: because at the time your virtual drive was not mounted. Had it been mounted then the tool would have moved on to the next available letter.
I believe that was not the case. I'm pretty sure the E: drive was mounted. (It's sort of unpredictable. I issue the SUBST command at startup, but often the NAS drive I point to isn't accessible yet. File Explorer always claims the E: drive is a "Disconnected network drive".)
In any case, E: is mounted right now and pointing to the directory on the NAS drive, but VSS Doctor went ahead and assigned E: anyway. Right after doing its assignment, VSS Doctor automatically invoked File Explorer to browse E: ... and it shows the contents of the directory on the NAS drive, not the partition VSS Doctor wanted to display.
Enchantech wrote:Having said that I wonder if your virtual drive will mount successfully now? You do not mention trying that to see here.
Two different answers to that question.
- If I don't reboot while VSS Doctor has it's mapping in place I have no trouble accessing my intended use of E:. In fact, I have no way of accessing the contents of the partition VSS Doctor pointed to.
- But if I reboot while VSS Doctor has its mapping in place, Windows then has E: pointing to that partition - the recovery partition in this case. At that point I cannot map E: to the NAS directory.
By the way, I have to access the files in that NAS directory as E: because the files are full of (as in has thousands of) absolute paths containing E:.
Enchantech wrote:I suspect it works though as it is probably allocated on your C: partition when mounted. Using the mountvol /p switch resulted in an unmount of the system partition. I think the /d switch would have removed the drive letter assignment and left everything else unchanged.
I'll remember for that if there's a next time, but hopefully there won't be
Enchantech wrote:You might wish to consider using Diskpart automount scrub command on your OS system disk. That command removes volume mount point directories and registry settings for volumes that are no longer in the system. This prevents volumes that were previously in the system from being automatically mounted and given their former volume mount point(s) when they are added back to the system. Because of this when a volume is subsequently added to the system Windows will create new entries in the registry for that volume. As a result if there is anything abnormal with your EFI System partition as a result of your experience, which at this point I do not think there is, a scrub should return things to normal.
I'll give that a try.
Patrick,
(It's sort of unpredictable. I issue the SUBST command at startup, but often the NAS drive I point to isn't accessible yet. File Explorer always claims the E: drive is a "Disconnected network drive".)
Subst command has changed in Win 10. It seems that the command is not persistent the effects of which are that drive mappings are lost with each OS reboot, sound familiar?
What is necessary is to have the command be persistent so that the drive remains mapped. To accomplish that have a look at psubst. This is a bat file that when run makes the subst command become persistent. Therefore, your issues you speak of here will not be in play.
:-)
Interesting. I just read some articles about Subst being broken in Win 10 and, I must say I haven't run into the problems. It's not persistent, as you say, but the command seems to work as advertised. But I'll take a look a Psubst and see if it does a better job.
And I think I'd better use the Diskpart automount scrub command you mentioned earlier. Even though everything seems to be working now, File Explorer shows the Acronis icon on my E: drive. That definitely was not the case before I booted when the VSS Doctor had E: mapped to the recovery partition. E: is currently mapped to the directory on my NAS but the Acronis icon seems to be permanently affixed to E:.
Hmm. The Diskpart automount scrub did not get rid of the Acronis icon. That was too much to expect, I guess. But the association between the drive letter and the icon is obviously saved somewhere. Anyone care to hazard a guess?
I'll hazard a guess. The mountvol /p command you ran removed the E: mapping that Acronis VSS Doctor had assigned. So Windows Explorer last association with E: is that of Acronis.
I think if you make E: persistent then Explorer should associate E: with a network drive again rather than that of Acronis.
Question, when you see the E: volume in Explorer as shown in your screenshot can you right click on it and see Reconnect in the menu? If you can and you select that what is the result?
I found the problem. VSS Doctor set the default drive icon for drives E, G, H, I, and J. I assume I can just delete these registry keys since they are the only default drive icon keys set.
It does not feel right that I should have to modify the registry to clean up after VSS Doctor.
Enchantech wrote:Question, when you see the E: volume in Explorer as shown in your screenshot can you right click on it and see Reconnect in the menu? If you can and you select that what is the result?
There's some Windows weirdness here. There's no need to reconnect. In spite of the label, the drive is not disconnected. I click on it and immediately get to the files on the NAS. IKt is always labeled "Disconnected Network Drive", but it is, in fact, never disconnected (after I run the subst command).
Patrick, have you tried the mountvol /r option, which is to remove the registry entries. There is no drive letter given with that option.
Patrick,
My point in asking what happens when/if you select reconnect was to find out what the result would be not to discover whether or not the volume is connected. I was more interested what Explorer might say if you did that. Would it change what explorer shows? If yes and you reboot does the disconnected message reappear? Given what you have said so far I think the answer to that is yes but given what all has transpired it would be nice to verify that.
I think the possibility exists that the EFI System partition is not mounted even though your machine boots OK. If that is the case you might fix that problem by mounting the EFI volume. To do that you would need to have the volume GUID number then run:
mountvol \\\\?\volume\{GUID}\ Note: the brackets are required
The easiest way to get the volume GUID is to use an Admin instance of PowerShell. Run the following command:
GWMI -namespace root\cimv2 -class win32_volume | FL -property DriveLetter, DeviceID
Windows 10 uses volume ID's in favor of disk ID's. The above command will show your EFI, C: and Recovery volumes separate with each unique ID.
As for your NAS virtual drive, I do not know when or how you run the subst command but I assume you do so, based on what you have said, in the Start up list as a bat file. I would say doing so is problematic in that as you say the NAS may not be ready when the bat is run.
If this were a persistent command it would not matter.
I know in my own experience with Explorer mapped drives when you create one you have the option to have the mapping always run when Windows starts. If you do not take that option then you must manually reconnect the drive in Explorer prior to use. This is another reason I asked what happens when/if you do that. If Explorer reconnects successfully then changing that option may work as well.
Enchantech wrote:Patrick,
My point in asking what happens when/if you select reconnect was to find out what the result would be not to discover whether or not the volume is connected. I was more interested what Explorer might say if you did that. Would it change what explorer shows? If yes and you reboot does the disconnected message reappear? Given what you have said so far I think the answer to that is yes but given what all has transpired it would be nice to verify that.
I wasn't very clear, I guess. Once I did the "The mountvol /p" and reran my subst, File Explorer has had no trouble accessing the NAS files via the mapped E: drive. After several reboots there has been no trouble with E: pointing to the Recovery or EFI partition. The only problem I'm left with is the Acronis icon on the drive letter. I just need to get rid of those (and mountvol /r did not do it).
Enchantech wrote:I think the possibility exists that the EFI System partition is not mounted even though your machine boots OK. If that is the case you might fix that problem by mounting the EFI volume. To do that you would need to have the volume GUID number then run:
mountvol \\\\?\volume\{GUID}\ Note: the brackets are required
The easiest way to get the volume GUID is to use an Admin instance of PowerShell. Run the following command:
GWMI -namespace root\cimv2 -class win32_volume | FL -property DriveLetter, DeviceID
Windows 10 uses volume ID's in favor of disk ID's. The above command will show your EFI, C: and Recovery volumes separate with each unique ID.
Disk Management sees the EFI partition so I think I'm OK there.
Enchantech wrote:As for your NAS virtual drive, I do not know when or how you run the subst command but I assume you do so, based on what you have said, in the Start up list as a bat file. I would say doing so is problematic in that as you say the NAS may not be ready when the bat is run.
If this were a persistent command it would not matter.
I know in my own experience with Explorer mapped drives when you create one you have the option to have the mapping always run when Windows starts. If you do not take that option then you must manually reconnect the drive in Explorer prior to use. This is another reason I asked what happens when/if you do that. If Explorer reconnects successfully then changing that option may work as well.
I'll eventually get around to trying the persistent command, but I've been coping with the current situation for years so there's no big hurry. The only problem (prior to my running VSS Doctor) was if I inserted a USB flash memory drive when the mapping of E: had failed. It would get E:.
I used Regedit to remove the default drive icons that VSS Doctor had set and now I'm back to where I was before running VSS Doctor (I think). File Explorer now shows the Disconnected Network Drive icon. That is incorrect, but not as incorrect as showing the Tib Mounter Monitor icon.
Patrick,
To change Win 10 icons look at the link Here
I think the icon you need to change would be that of shortcuts. The method to do that is the last one discussed in the provided link.