New Drive Snapshot build released.

You could run a DS restore batch file directly from the TBLauncher menu but it is potentially dangerous if the HD numbers change and you aren't aware of this happening. IFW gets around this issue by using DiskIDs or Disk GUIDs instead of HD number.

 

Where do you have snapshot64.exe located.
System drive or other drive?

I just made a TB Windows RE. It messes around with the drive letter thought. My D: became E:. My F: became C:. I ran DS, and my restore drive changed from HD1 to HD2. I didn't go any further though.
Explorer++ works fine.

 

I put it in ProgramFiles during the build.

The TBLauncher.ini has...

[Menu_Item_11]
Name=Drive Snapshot
Path=%ProgramFiles%\DS\snapshot64.exe
WorkingDir=
Parameters=
Icon=0

Changing drive letters and HD numbers is fairly standard with WinPEs. We just have to accept it. I see this in Linux too. Sometimes my boot drive is first, sometimes second.

 

Yes, like I've done with Explorer++.
Do you think PE would sort my drives better than RE?
The raw WinPE I made yesterday handled it better.

 

I think PE and RE would handle drive letters the same. I just accept it.

 

OK. So yours get messed up too.
I have a Samsung SSD OS drive and 2 WD hard drives, plus a Blu-ray.
So, everything gets pretty well messed up. As long as it restores OK.

Did you use method 2?
I thought it would be easier to update the UFD.

 

PE fixed my screwed up drives, and my OS drive is back to reading how it should as HD1 in DS.
And PE is just over half the size of RE.

 

I might be using a strange method. Start the build, Settings, Build Options, Pause build before unmounting WIM file.
When it pauses I put the DS folder (contains the exe) in Mount\Program Files. Then go back a few folders so it can subsequently unmount. Use that .ini edit I mentioned. In config folder that is created just after you start.

 

Good. I find PE boots a few seconds faster.

 

True, as PE has fewer features and driver set as compared to RE. I prefer RE because it's more functional and can support Bitlocker and ReFS without issues when built with the correct Windows version.

 

I've forgotten what I used. Doesn't PE support BitLocker?

 

PE support for Bitlocker is not reliable. Sometimes it can unlock a Bitlocker encrypted drive, sometimes can't. With RE I never had any problems unlocking such partitions.

 

For my purpose in regards to DS or IFW, PE is great. I don't need the extra tools in RE. Fitness for purpose.
If I do need RE, when that time comes, I'll use it.

 

Good job. Once a good working PE is set up with DS reading the drives as expected and such it becomes an excellent convenience to turn to for almost any multiple methods you need in either accessing a fudged Windows or carrying out a routine backup/restore.

But then you already know that With Strelec and another Win 10 PE on this end I seldom concern with Windows issues any longer.

 

A WARNING to anyone who relies on PE/RE for proper drive letter detection that is the same as your LIVE System...

Detection of disk drives is an asynchronous process started by the OS (LIVE/PE/RE). It issues inquiry commands to the drives and waits for a response from those drives to tell it who/what they are. This response is random as far as the time it takes a drive to respond to the inquiry. As the OS hears back from those drives, it assigns appropriate disk #s and appropriate letters for mount detection, usually in the order it hears back from the drives. This is the reason that most PE/REs don't wind up with the same drive/letter assignment as the LIVE OS finds... the disks respond in their own timing rather than the order that the inquiry was issued, they can be busy doing other things during the inquiry.

If a PE detects the same string of drives the same way as the OS, you're very lucky. The only PE I know of that always gets it right is the one produced by Macrium REFLECT. The reason... after it gets its responses from the devices themselves (hardware identifiers, etc.), it then looks into the disk resident REGISTRY to find the devices it just found and assign the same information as the disk resident OS contains. That's the only reason it is consistent with the LIVE OS. I know of no other application PEs that do it this way... although there may be some I've never used. It's an extra step required by the application (or some process built into the PE startup) the PE/RE is supporting so that presentation to the user remains consistent.

 

Thanks @TheRollbackFrog
I must be just lucky then. PE works nicely with both UFD and optical disc.
It also did with the raw WinPE I made with Deployment and Imaging Tools.

 

I always wondered the WHY to this anomaly never seemed to change for the better no matter what PE version (or for that matter Windows version) one is equipped with. Except as you say Reflect.

 

TRF,

I guess it depends on the computer too. Macrium Reflect, TBWinPE and Active@ Boot Disk show different drive letters in my UEFI computer. None show my Win10 OS with a drive letter. I can assign a drive letter to Win10 in TBWinPE. Macrium assigns the C: drive letter to the backup partition in my second SSD.

I'm not complaining. It's the nature of WinPE. I accept it.

 

So @Brian K, as concerns this current ordeal courtesy @Hadron, (Thanks for reraising DS batch commands), we then assume that TBLauncher menu cannot and maybe should not be depended on due to the switching around drive numbers but IFW not so imposing to rely on for running the batch file directly.

This unpredictable behavior of drive assignments is exactly the anomaly i would have thought Windows might have been able to work with the manufacture of controllers to ensure full compatible synchronizing with programs, even scripts, but maybe is more involved then we/they expected or for want of software program expectations it just didn't fit in to the equation

 

EASTER,

There is no problem with running DS manually. The drive letters and HD numbers could change but that would make no difference to a manual DS backup/restore. But I would be very cautious about running a DS automatic restore script in a WinPE.

 

I see. Got it on that.

There's really no real need to i would think, to even run cmd command scripts from the PE at all then for any reason except testing purposes. Safer run inside on the O/S itself would ensure the process completes as expected.

Thanks for your explanation.

 

What do you mean by manually and automatic? What are the 2 different ways?

I could clearly see my Samsung SSD and 3 partitions.

 

Hadron,

You have a single disk so you would have no issues with restoring from a batch file in a WinPE. I have 6 disks so there is the potential issue of HD numbers changing which could cause a restore to the wrong disk (only if doing this from a batch file) and over-writing the contents of the wrong disk.

Manually= using the DS GUI in a WinPE. Automatic= restoring from a batch file in a WinPE.

 

I have 3 disks, Brian. A Samsung SSD, and two WD hard drives.
I backup the operating system SSD to my first WD hard drive and Bvckup2 backs that up to my second WD drive.
All my data is on my first WD hard drive, and Bvckup2 also handles that and ensures it goes to my second hard drive.

 

I don't think we've discussed DS restorations with batch files. Only backups.