Registry Backup - Weirdness on drive(s?) other than C:

[Casteele]

Hi,

First, a little background.. I've used ERUNT for years to backup my Windows' registry, but I recently got a new laptop with Win8.1, which ERUNT doesn't seem to properly back everything up. So I'm giving Tweaking.com's Registry Backup a try.. However, I'm set up in a specific way, using a very large library of hand crafted tools and utilities (both batch/cmd files and binary executables) which would be a major pain to go back and change them all at this point :-( Specifically, my drives are set up so that the C: drive is mainly for booting the OS, the files needed by the OS for normal operation, and *some* applications. I've moved my user profiles and the majority of applications to the D: (Data) and P: (Programs) drives, which I set up as additional partitions after trimming the C: drive down to just what it needs. Additionally, I've got another partition, the B: (Backup - And a throwback from when I used the B: drive for a IOMega Zip disk instead of a floppy drive) drive in which I have some critical backup/restore software and their data (including the metadata needed to restore the entire  system from scratch, if need be).

Of course, I installed Registry Backup (RB) to this B: drive, and told it to use a dedicated folder on this drive for it's backup and data files. And this is where I seem to have my problem..

It looks like RB installed fine to the B: drive, and seems to start up fine, without any issues. However, when I click the button to backup manually now.. It creates a rift in the space-time continuum that seems to turn my B(ackup) drive in to a B(lack hole)! :-( First, VSS takes a long time to start (and the other problems persist even if I use the alternate method, either from the start, or by clicking the "I'm impatient" button): The B: drive just disappears, entirely and completely, from the system. RB spazzes out and fails to backup anything at all, and fails to even save a log file (it seems it can no longer find the B: drive anymore, either), File Explorer seems to think the drive has vanished, even the Disk Manager refuses to let me do anything with the B: partition. It still sees the partition, but it won't let me view it or assign it to a drive letter again. RB seems to fail because it cannot find the B: drive anymore, either--including not being able to save a log file (so I cannot provide a log file for you to look at!)

This seems to continue on even after RB fails to backup anything.. At first, I thought I would have to reboot to restore the universe to it's proper configuration.. But.. The moment I exited the RB application, my B: drive suddenly reappeared on it's own. I've tried this now four times, with the same results each time: As soon as I start the backup, the B: drive unmounts until I close RB. I tried to install RB to the C: drive and run it from there, but the same problem persists if I use the B: drive to store the data. Finally, I installed RB to the C: drive AND used the C: drive to store the RB  data.. And everything worked beautifully without any problems.

So it would seem the RB does not like using anything but the C: drive, or whatever it is doing during it's backup prep-work, it's unmounting the other drive, even though it's trying to use the drive at the same time. Thankfully, it seems temporary and goes away as soon as the RB application terminates, so it seems very likely that the problem is within the RB code.

I have NOT tried RB with another drive, such as the D: or P: drives, but given it's behavior, I suspect the results would be much the same. I am not able to test this, though, as anything that unmounts D: or P: *will* bring my system to a crashing halt.. If need be, I can create a testing drive to test it on some other drive letter; Just let me know. I'll happily provide any other information to help diagnose the problem, too.
(*EDIT: Correction, I did try this on another temporary drive--using a USB "ThumbDrive", but not a hard disk partition, and had the same issues.*)

In the meantime, I'm working around the problem by backing up the registry to the C: drive, then copying the backup to the B: drive.. Just not sure how effective this would be if I need to restore, however.

Regards,
Cas

[Shane]

I know exactly what is happening.

When the program makes the volume shadow copy it maps the copy to the drive letter B: and then backups up the registry files from it. I choose B: because it was normally used for floppy drives and people almost never use drive B:. well normally lol

So I know what has to be the part that is throwing it off. So if you set the program to always use the fallback method it will use the Windows API like erunt does to backup the registry instead of VSS.

The vss_start.exe in the files folder is what calls the proper vss exe to run on the system and it is started through a bat command. dosdev.exe is used to set the drive letter and also remove it when done, which is why it disappeared on you.

As a matter of fact here is the actual code of part of the bat file

    Open sVss For Output As fFile
        Print #fFile, "@echo on"
        Print #fFile, "set path=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;" & App.Path
       
        Print #fFile, "call " & sExtraChar & sVss_SetVar & sExtraChar
        Print #fFile, sExtraChar & App.Path & "\dosdev.exe" & sExtraChar & " -a B: %SHADOW_DEVICE_1%"
        Print #fFile, sExtraChar & App.Path & "\dosdev.exe" & sExtraChar
        Print #fFile, "dir B:"
        Print #fFile, "start " & sExtraChar & sExtraChar & " /wait " & sExtraChar & App.Path & "\vss_pause.exe" & sExtraChar
        Print #fFile, sExtraChar & App.Path & "\dosdev.exe" & sExtraChar & " -r -d B:"
    Close fFile

You can see B: in there.

So what is the fix? Easy, I will make a new version of Registry Backup where I can let the user set what drive letter to use, this way for people like yourself who have B: used you can simply change it in the program to use another one.

Till then just go to the advanced settings and have the program set to always use the fallback method and it should work fine till I get the update done for you

Shane

[Shane]

And done

Tweaking.com - Registry Backup v1.7.0 Released
http://www.tweaking.com/content/page/registry_backup.html

V1.7.0
Added a new setting to allow the user to set what drive letter the program will use to access the volume shadow copy snapshot to grab the registry files. Before it always used B: as hardly anyone uses that drive letter. But some users do and so the backup by volume shadow copy wouldn't work. They can now change what drive letter to use.

Shane

[Casteele]

Awesomeness! It looks like you used the same idea as I did, only as a temporary measure instead of an "always there" version!

Maybe a better solution than letting the user select a drive would be write something to find an unused drive letter to mount at the time the script is run? That way, even if a user changes their configuration (or plugs a USB device in that grabs the letter they tried to choose), it won't affect them at all, and won't bother them to try to choose a drive? I already do something very similar with my USB portable software drive--The autorun script tries to mount it to P:, but if P: is not available, it'll find any available drive and adjust itself accordingly. This way, whether I'm at home, at the office, or at a client site, I can plug the drive in and "it just works."

From the looks of your code, you're using VB to create a batch script to do the work.. Much the same as I am doing with my backup scripts  You could just have the VB code find an unused drive letter (I don't use VB much, so not sure how to go about that part), then when outputting the batch file, add something like "SET ""VSS_DRIVE=" & sDriveLetter & ":""" to the batch file, and replace every occurrence of ``B:'' with ``%VSS_DRIVE%'', or something similar. Or, if you'd like, I could show you some of the code from my own batch scripts that will auto-mount drives only when actually needed/used.

Cheers, and thanks for providing Registry Backup! So far, it's taken over the job that ERUNT used to do without any other problems.

[Shane]

The batch file is only needed because of the 2 other exes that need to be used and in order.

The vss exe and the dosdev.exe to map the drive letter. The vss then runs the bat file after it is done and that is how I know when the vss snap shot is ready.

There was zero code for using VSS directly in VB6 so I had to go that route. Once the drive is mapped the main program then does the rest of the work

I could have it check for drive letters, the problem comes with mapped drive letters. Just how Windows ignores mapped drive letters when giving a thumb drive a automatic drive letter.

Shane