Jump to content











Photo
- - - - -

Capture and apply Windows Full Flash Update (FFU) images

dism

  • Please log in to reply
115 replies to this topic

#26 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15105 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

For those not familiar with the (official) tool, it is here  :good:  :

http://reboot.pro/fi...-mount-service/

:duff:
Wonko


  • ReTokener likes this

#27 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

After booting with Win10XPE then first I have used Windows Disk Management to mount a VHD (used for WIMBOOT)

In DismMountService_x64.exe on Disks tab I used r-mouse menu to Capture Disk to File 

 

Then I formatted the mounted VHD and used again DismMountService_x64.exe on Disks tab with r-mouse menu to Apply File to Disk

Then I used Disk Management to Unmount the VHD and Rebooted with the VHD

 

The procedure to Capture and Apply FFU file is very fast and VHD is booting OK in WIMBOOT mode as before ...  :)

 

Then I repeated the procedure but now inside a running Windows 10 x64 OS

Capture of mounted VHD is giving Dism Error 50

After format of mounted VHD I can use DismMountService_x64.exe with the previous FFU file for Apply to Disk and rebooting with VHD is OK  :)

 

The VHD is a simple case having MBR with only one partition.

Such VHD mounted as PhysicalDrive can be used in Win10XPE for Capture and Apply of FFU backup file.

The process is fast and handy.  :)

In this case we don't have the problem of loosing other partitions .....


  • ReTokener likes this

#28 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15105 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

Quoting myself:

 

Now, back to FFU, what happens on a non-partitioned \\.\PhysicalDrive?

Is there a way (via Arsenal Image Mounter) to map a disk extent to a \\.\Physicaldrive? (in analogy with IMDISK that can mount a disk extent to a \\.\logicaldrive)

 

Provided that:
1) the disk containing the extent to be imaged/captured is \\.\PhysicalDrive1

2) that the extent you want to map is starting at offset 2048 sectors and is 1,000,000 sectors in size (i.e. in bytes 1,048,576 and 512,000,000 respectively

 

It should be something *like*:

 

aim_ll.exe -a -f \\?\physicaldrive1 -b 1048576 -s 512000000

 

Cannot say if it actually works (i.e. a new \\.\PhysicalDrive will be actually attached) nor, if it does, how will DISM /capture-ffu would manage that. :unsure:

 

:duff:

Wonko



#29 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 224 posts

Posted 3 weeks ago

@ wimb

Thanks for testing

 

 

In this case we don't have the problem of loosing other partitions .....

 

 

Selecting the wrong disk to apply an image can get you in trouble by one click. A demand on proceeding will be added at that point.

 

The previous link is updated to the new version.

 

Regards   T.

 

PS. One thing I forgot to mention: by selecting the "DISKS" tab, an information about attached disks is available in the "INFO" tab (backgrounded), to identify disks by numbers.


Edited by ReTokener, 3 weeks ago.


#30 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

PS. One thing I forgot to mention: by selecting the "DISKS" tab, an information about attached disks is available in the "INFO" tab (backgrounded), to identify disks by numbers.

 

For INFO the partition numbering should start with 1 instead of 0 so that it corresponds with diskpart numbering of partitions.


  • ReTokener likes this

#31 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 224 posts

Posted 3 weeks ago

@wimb

my diskpart starts counting from zero, vmount (1.0.0.13) also.

Attached File  Zwischenablage_cmd.jpg   201.49KB   0 downloads

what version of diskpart do you use?

regards  T.

 

 



#32 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

Numbering of disks starts counting from zero, but numbering of partitions starts counting from 1


  • ReTokener likes this

#33 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 224 posts

Posted 3 weeks ago

 

corresponds with diskpart numbering of partitions.

sorry I missed that part, I will take a look.



#34 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

For a fresh installed W10x64 1909 in VHD of 25 GB I did a comparison for Capture and Apply of wim and ffu files.

 

For Capture and Apply of wim files I used WinNTSetup with wimlib and XPRESS compression giving wim file size = 6.4 GB

For Capture and Apply of ffu files I used DismMountService_x64 with XPRESS compression giving ffu file size = 9.3 GB

 

All operations were carried out in Win10XPE environment.

 

wim file Capture = 92 seconds and Apply = 150 seconds

ffu file Capture = 59 seconds and Apply = 85 seconds

 

So Capture and Apply of FFU files is slightly faster as compared to WIM files

 

WIM files are more interesting since they can be used in WIMBOOT mode and can be applied to a partition without loosing other partitions of a disk.



#35 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15105 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

For a fresh installed W10x64 1909 in VHD of 25 GB I did a comparison for Capture and Apply of wim and ffu files.

 

For Capture and Apply of wim files I used WinNTSetup with wimlib and XPRESS compression giving wim file size = 6.4 GB

For Capture and Apply of ffu files I used DismMountService_x64 with XPRESS compression giving ffu file size = 9.3 GB

 

All operations were carried out in Win10XPE environment.

 

wim file Capture = 92 seconds and Apply = 88 seconds

ffu file Capture = 59 seconds and Apply = 85 seconds

 

So Capture and Apply of FFU files is slightly faster as compared to WIM files

 

WIM files are more interesting since they can be used in WIMBOOT mode and can be applied to a partition without loosing other partitions of a disk.

Good :), so -as expected BTW - the dramatic differences in capturing and applying times previously reported were probably due to the different compressions algorithms and exacerbated by the (slow) hardware (or non-hardware) used.

 

If (set aside for a moment Wimlib) it took you for a plain new install "source" respectively 59 and 85 seconds, whilst the referenced resource:

https://win10.guru/w...ure-deployment/

took for a similar core (one might want to take into account the difference between the 10.4 GB of the plain install and the actual size with installed data of 13.1 GB, i.e. a 30%) respectively 5:11 (i.e. 311 seconds) and 6:15 (i.e. 375 seconds) it is clear that the performance of your real hardware when compared to the Hyper-V used there is from another planet.

 

But still there must be something else, the given source had an apply/capture ratio of 375/311=1.20, while you are reporting a 85/59=1.44 ratio :dubbio:

 

At least in theory a tool designed and intended for deployment in a "mass production" could (should) be:

1) slow as much as you want in capturing
2) as fast as possible in deploying

your report places it in the more or less *same* speed in applying while very fast (even if 33 seconds difference won't really change anyone's life) in capturing.

The 3 (88-85) seconds shaved off in the applying are 3/88=  3.4% bettering, it doesn't sound to me like such a big thing. :unsure:

 

And still, comparing Wimlib with Dism ffu isn't really-really definitive (it could well be that WimLib outperforms dism in .wim capturing and applying).

 

Can you make a "proper" comparison (on same data) with (the same) dism in "normal" .wim /compress:fast vs. -ffu mode?

 

To be fair (and this could be the actual reason why the good MS guys actually "invented" this ffu staff) in a "manufacturing" environment you would need to add the time needed to partition the brand new destination disk and format it (quick), though this - if done by a script - should be anyway a matter of a bunch of seconds.

 

:duff:

Wonko


Edited by Wonko the Sane, 3 weeks ago.


#36 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

Can you make a "proper" comparison (on same data) with (the same) dism in "normal" .wim /compress:fast vs. -ffu mode?

 

 

I repeated the experiment, but used in WinNTSetup wimgapi (= Dism) XPRESS for Capture and Apply of wim file size 6.4 GB

In WinNTSetup wimgapi has for Apply using 2x CPU cores indicated.

 

wim file Capture = 114 seconds and Apply = 100 seconds

ffu file Capture = 60 seconds and Apply = 85 seconds



#37 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 483 posts
  •  
    Italy

Posted 3 weeks ago

u mean we can think of applying it to a vhd (on a wimboot basis) in the future or, as wonko said, no dice?



#38 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

u mean we can think of applying it to a vhd (on a wimboot basis) in the future or, as wonko said, no dice?

 

FFU in general is not so useful for us.

 

For VHD WIMBOOT you need a VHD file that is related via pointers to the WIM archive file.

 

FFU can be useful to make very fast (in about 6 seconds) a backup of the almost empty VHD (has may be only 1 GB file content) used in VHD WIMBOOT.

Apply of such FFU backup of 1 GB is  then much faster than Apply of the WIM file of 7 GB to recreate the pointers and reset the VHD used in VHD WIMBOOT.

However, a disadvantage of FFU Backup is that you need PE environment, since FFU Capture does not work inside Windows 10 Operating System.



#39 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15105 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

@Wimb
JFYI, it is not very nice to silently edit data in a post, particularly if someone posts an observation based on the data that you later changed. 
 
This:
 
 

wim file Capture = 92 seconds and Apply = 150 seconds
ffu file Capture = 59 seconds and Apply = 85 seconds

 
was:
 
 

wim file Capture = 92 seconds and Apply = 88 seconds
ffu file Capture = 59 seconds and Apply = 85 seconds

 
  
So, summing it up:
WIMLIB wim file Capture = 92 seconds and Apply = 150 seconds
DISM wim file Capture = 114 seconds and Apply = 100 seconds
DISM ffu file Capture = 59 seconds and Apply = 85 seconds -> second experiment the same +/- 1 second (within timing approximation) -> 60 seconds and Apply = 85 seconds
 

Within DISM:
59/114= 0.52 around 50% is definitely a huge saving in capturing (but as said unneeded for the intended scope)

85/100=0.85 15% saving is much better than what was previously calculated

 

:duff:

Wonko



#40 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

@Wimb
JFYI, it is not very nice to silently edit data in a post, particularly if someone posts an observation based on the data that you later changed. 
 

 

You are quite right and I am sorry for it.

I found that value suspect and repeated the measurement and on editing the value then your post was not yet visible for me.

But, later I should have made a remark about it ....



#41 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15105 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

You are quite right and I am sorry for it.

I found that value suspect and repeated the measurement and on editing the value then your post was not yet visible for me.

But, later I should have made a remark about it ....

No prob :).

 

About your note of DISM "ffu capture" working only in a PE (and not in a "full" Windows) maybe one could have a PE in a VM and use it from within the VM, even if the capture process ends up as being slower, once you have the ffu backup/image ready you can apply/deploy it to "reset" the wimboot image from the "full" system. :dubbio:

 

:duff:

Wonko



#42 alacran

alacran

    Gold Member

  • .script developer
  • 1164 posts
  •  
    Mexico

Posted 3 weeks ago

For a fresh installed W10x64 1909 in VHD of 25 GB I did a comparison for Capture and Apply of wim and ffu files.

 

For Capture and Apply of wim files I used WinNTSetup with wimlib and XPRESS compression giving wim file size = 6.4 GB

For Capture and Apply of ffu files I used DismMountService_x64 with XPRESS compression giving ffu file size = 9.3 GB

 

All operations were carried out in Win10XPE environment.

 

wim file Capture = 92 seconds and Apply = 150 seconds

ffu file Capture = 59 seconds and Apply = 85 seconds

 

So Capture and Apply of FFU files is slightly faster as compared to WIM files

 

WIM files are more interesting since they can be used in WIMBOOT mode and can be applied to a partition without loosing other partitions of a disk.

 

 

I repeated the experiment, but used in WinNTSetup wimgapi (= Dism) XPRESS for Capture and Apply of wim file size 6.4 GB

In WinNTSetup wimgapi has for Apply using 2x CPU cores indicated.

 

wim file Capture = 114 seconds and Apply = 100 seconds

ffu file Capture = 60 seconds and Apply = 85 seconds

 

@ wimb

 

Hi, it is good you made all this tests, unfortunately when I tried several times to make (by coincidence) exactly same tests (I was using 10x64 1903 + Dism 10.0.18362.1) since some days ago for testing the DMS program from Retokener, first on a Wimboot VHD, and latter on a just installed Win10x64 on a VHD, I had the bad experience to find on my CSM/MBR with Secure Boot disabled PCs, even if I'm able to boot in UEFI mode from a USB device with Win10XPE_x64.wim, there is no way to capture to .ffu the VHD(s), there is very few and uncompletet info about this feature of Dism but I can confirm it did not work from two different PCs (both CSM/MBR with Secure Boot disabled).

 

EDIT: Latter I found I was using a version of Dism that has bugs for FFU capture. info on post No. 51

 

I think there is something wrong with the size on the blue remarked text, a .wim file made with Dism should always be bigger than one made with wimlib.

Also I would like to ask you for some additional info, to understand better the difference in size from the captured .wim and .ffu when both are made by Dism and with same compression level.

Please mount to a folder on your HD the .ffu image of the fresh installed W10x64, (you can use Retokeners DMS to do it, as any other Dism image), as this .ffu is a full disk sector backup, I assume some of the usual files/folders not copied by default to .wim are copied to .ffu and this explains the different size.

 

For full lists of files/folders omited by Dism and wimlib-imagex when making a .wim file see:

 

Spoiler

 

Once again, thanks for your tests and info it is good to know better this format in order to think if it could be useful in some other way for future uses.

 

Wonko has insisted twice on an idea but nobody seems to make any comments about it:

 

http://reboot.pro/to...e-2#entry213239

 

I think if we could find a driver to load on Windows this .ffu images, per sure we could find other uses for them.

 

Alacran
 


Edited by alacran, 3 weeks ago.


#43 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15105 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

Wonko has insisted twice on an idea but nobody seems to make any comments about it:

 

http://reboot.pro/to...e-2#entry213239
 

 

Sure, it is sooo difficult to find kids wishing to play with me :(.

 

If we could find a driver to load on Windows this .ffu images, per sure we could find other uses for them.

Which - for the record - is NOT what Wonko proposed, mounting of the .ffu image makes (to him) little or no sense, the proposal was about (maybe) the possibility to DISM ffu image (and restore) a single volume (as opposed to the whole disk).

 

:duff:

Wonko



#44 alacran

alacran

    Gold Member

  • .script developer
  • 1164 posts
  •  
    Mexico

Posted 3 weeks ago

 

Which - for the record - is NOT what Wonko proposed, mounting of the .ffu image makes (to him) little or no sense, the proposal was about (maybe) the possibility to DISM ffu image (and restore) a single volume (as opposed to the whole disk).

 

:duff:

Wonko

 

I just edited previous post to make obvious it was not your idea.

 

You can mount the .ffu on a folder as any other dism image, and edit it as you like and unmount committing changes, as far as I know the image only has one index, not an index for each partition.

 

alacran



#45 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

@alacran

Win10XPE is booting from RAMDISK.

I don't see why you have problem in Capture of VHD as FFU file using DismMountService_x64.exe

 

After booting with Win10XPE can you use Windows Disk Management to Attach the VHD file ?

That is the first step you need to do.

 

You are right, the Dism wimgapi Capture is slightly larger than the wimlib Capture file, but the difference is only 0.1 GB



#46 alacran

alacran

    Gold Member

  • .script developer
  • 1164 posts
  •  
    Mexico

Posted 3 weeks ago

Yes, that's the way I do it, (it is mounted as PHYSICALDRIVE3) but can't make a FFU, attached my Dism.log and DismMountService.log.

I made a new WinPE and a new wimboot VHD today, to make sure none of them is corrupt but same thing.

 

EDIT: Latter I found I was using a version of Dism that has bugs for FFU capture. info on post No. 51

 

alacran

Attached Files


Edited by alacran, 3 weeks ago.


#47 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

Strange that it does not work for you.

 

Here are some screenshots of what I see ...

 

Attached File  PE_AttachVHD-2019-11-15_151508.png   423.72KB   1 downloads == Attached File  DMS_CaptVHD-2019-11-15_151936.png   266.08KB   1 downloads

 

 



#48 alacran

alacran

    Gold Member

  • .script developer
  • 1164 posts
  •  
    Mexico

Posted 3 weeks ago

I know how to use the DMS, I suggested to Retokener to add FFU capture/apply to it last Saturday, and since last Sunday I have been trying to make it work with no success so far, but Retokener who also has his PC as CSM/MBR got it working on a UEFI VM on VirtualBox to run his tests.

 

Also I suggested to use GetWaikTools from JFX to download Dism 10.0.18362.1 (the version used by JFX on WinNTSetup_x64), and the funny thing is I can't make DMS run on my CSM/MBR PC(s).

 

EDIT: Latter I found Dism v10.0.18362.1 has bugs for FFU capture. info on post No. 51

 

alacran


Edited by alacran, 3 weeks ago.


#49 alacran

alacran

    Gold Member

  • .script developer
  • 1164 posts
  •  
    Mexico

Posted 3 weeks ago

@ wimb

 

Excuseme to insist but as you know I can't do my own test, what about this:

 

 

@ wimb

 

Also I would like to ask you for some additional info, to understand better the difference in size from the captured .wim and .ffu when both are made by Dism and with same compression level.

Please mount to a folder on your HD the .ffu image of the fresh installed W10x64, (you can use Retokeners DMS to do it, as any other Dism image), as this .ffu is a full disk sector backup, I assume some of the usual files/folders not copied by default to .wim are copied to .ffu and this explains the different size.

 

For full lists of files/folders omited by Dism and wimlib-imagex when making a .wim file see:

 

Spoiler

 

 

alacran



#50 wimb

wimb

    Platinum Member

  • Developer
  • 2681 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 weeks ago

@alacran

The File content of mounted FFU and mounted WIM is equal.

So the conclusion must be that it is probably normal that the filesize of FFU is much greater than the WIM filesize.

 

Attached File  FFU_WIM-2019-11-15_171618.png   370.59KB   1 downloads

 

Regarding your Dism Error 50:

After booting with Win10XPE, what is the size of your RAMDISK B:  (may be too small)  :unsure:

 

Where is your VHD located ? on USB or SSD Or HD ? and what type of partition ? primary  ?





Also tagged with one or more of these keywords: dism

2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users