Jump to content











Photo
- - - - -

Capture and apply Windows Full Flash Update (FFU) images

dism

  • Please log in to reply
115 replies to this topic

#1 alacran

alacran

    Gold Member

  • .script developer
  • 1165 posts
  •  
    Mexico

Posted 4 weeks ago

Capture and apply Windows Full Flash Update (FFU) images

 

Has very interesting info about .ffu format I haven't seen before and I wanted to share it:

 

There is a new format FFU (Unlike the file-based WIM format, FFU is a sector-based file container that stores one or more partitions or the full HD layout).

 

To capture, deploy, and mount FFU images with DISM, you'll need to work in a Windows 10, version 1709 or later, or WinPE for Windows 10, version 1709 or later environment.

 

Compression:

 

Xpress-Huffman is used by default when an FFU is captured with DISM

 

Source: https://docs.microso...ge-file-formats

 

See also: FFU image format: https://docs.microso...fu-image-format

 

DismMoutService a GUI tool for Dism and also capable to captue/apply FFU files: http://reboot.pro/to...-mount-service/made by my good friend Retokener.

 

EDIT: UEFI and/or GPT format are not a requirement.
 

EDIT-2: Using DMS to create wimboot VHDs:  http://reboot.pro/to...e-4#entry213355

 

alacran


Edited by alacran, 2 weeks ago.

  • ReTokener likes this

#2 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Nice and good to know, nice find. :)

 

This is very handy:

https://docs.microso...ge-file-formats

 

Though still it is not clear (to me) if there are any particular advantages to this format (outside the very narrow scope it seems to have been developed for).

 

The whole idea of a "gang programmer"  :hyper: is entirely new to me, and - as always happen with MS documentation everything and the contrary of it seem like being "detailed" (in the most confusing and vague and contradicting possible way).

 

(please note how this is not in the "desktop" path but rather in "mobile" - while still under "manufacture"):

https://docs.microso.../flashing-tools

 

 

 

 

Each manufacturer has different techniques and tooling that they will use to manufacture and service a Windows 10 Mobile device. The best technical expertise regarding manufacturing resides within those who built the OEM manufacturing line. This means that the OEM will need to determine which flashing and manufacturing process will work best for them. OEM service centers may have unique needs that will also influence the selection of flashing tools. The OEM will need to determine how to test and validate that the selected tools and processes meets their cost, quality, and other unique manufacturing objectives.

The OEM uses the Microsoft supplied imaging tools to create the FFU OS images that are flashed to the device.

and later:

 

 

The Microsoft provided FFUTool full flash update (FFU) technology is designed for engineering development, and testing purposes; it is not supported for use in manufacturing.

 

So, in an article dedicated to mass manufacturing, they suggest to use a tool NOT INTENDED FOR MANUFACTURING and to the intended audience (highly experienced hardware developing and manufacturing engineers) besides some generic "do the right thing" suggestions they add these pearls of wisdom as caveats:

 

 

FFUTool known issues

Using the FFUTool has a number of significant limitations that are summarized here.

USB hub activity may cause flashing failures

Some USB hubs have been known to cause reliability issues even when flashing devices in serial due to hardware interference to the streaming FFU data.

Multiple devices that share a single USB hub cannot be connected and disconnected while other connected device are flashing. This uncovers a known hardware issue with some USB controllers. For more info, see KB908673. You should not unplug USB devices when device flashing is underway.

USB cable length is limited to 3 feet

Flashing may be less reliable when using USB cables longer than 3 feet (.91 meters), or if your flashing setup contains consecutive cables that total to more than 3 feet. This is due to hardware limitations of data transfer in longer cables.

Flashing time per phone

You will need to evaluate whether the flashing time per device meets their objectives for your manufacturing line.

 

It is still good ol' MS alright.  :rolleyes:

 

I'll add a picture:

Spoiler

 

:duff:

Wonko



#3 alacran

alacran

    Gold Member

  • .script developer
  • 1165 posts
  •  
    Mexico

Posted 4 weeks ago

Nice and good to know, nice find. :)

 

Though still it is not clear (to me) if there are any particular advantages to this format (outside the very narrow scope it seems to have been developed for).

 

 

My good friend Retokener is making some updates/additions to his Dism Mount Service program (a GUI for mounting *.wim images with Dism) and he sendeded it to me to take a look, give some ideas (if possible) and run some tests, on it there is a link to a page with good info about Dism: https://ss64.com/nt/dism.html, then during reading this info I found a link to Full Flash Update ( FFU), next quote from it:

 

 

Sector-based imaging means that FFUs take less time to deploy, but have larger files sizes than WIMs

 

About advantages of this new format I still haven't tested this format to check speed/compression ratio on Capture/Apply compared to usuall (/compress:maximum with DISM or wimlib-imagex default LZX compression) or XPRESS .wim images made by Dism or wimlib-imagex. 

 

Only thing I can comment so far is as said on first post the compression used by default is Xpress-Huffman wich has a Compression ratio higher than COMPRESS_ALGORITHM_XPRESS according with this info:https://docs.microso...compression-api

 

Xpress-Huffman seems to be equivalent to Wimboot compression:

 

 

XPRESS HUFFMAN = Wimboot compression

 

Source: https://msfn.org/boa...up-v394-40-rc1/

 

alacran



#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Yep :),
what I suspect is that:
1) it is not-so-new (due to the various references to mobile and phone manufacturing) and at least for anything related to mobile is discontinued, not supported or both:
https://en.wikipedia...ndows_10_Mobile
2) it has never been used (due to the listed caveats) by actual manufacturers
 
So maybe it is useful for our little projects, maybe it is not.
 
From the comparison page, the only seemingly added feature is the hashing/verifying function, I don't think (but I may well be wrong) that it uses a "different" compression algorithm, the difference is seemingly that it uses by default the "Xpress-Huffman", but that should be the SAME one as using DISM with /compress:fast  (or at least this is what I understand from here):
https://wimlib.net/c...ion.html#XPRESS

 

Whilst from here:

https://github.com/c...ife/ms-compress

 

 

 

Xpress

Used for Windows XP and newer hibernation file, Directory Replication Service (LDAP/RPC/AD), Exchange Server HTML compression, Windows Update Services, and Windows CE.

 and:

 

 

 

Xpress Huffman

Xpress algorithm with Huffman encoding, used in WIM files, Distributed File System Replication, Windows 7 SuperFetch, and Windows 8 bootmgr.

As always, it  is confusing, as everyone uses different termes/names, compare with:
 
https://docs.microso...3b-5e14273b96f8
 
https://winprotocold...CA/[MS-XCA].pdf

 

But it seems to me like "XPRESS" (only) compression is not used anymore and that in DISM or more generally in .wim files "XPRESS-HUFFMAN" is used, i.e. in the parameters of DISM :unsure::

/Compress:{fast|max|none}

fast=XPRESS-HUFFMANN

max=LZX

none=no compression

 

:duff:

Wonko



#5 alacran

alacran

    Gold Member

  • .script developer
  • 1165 posts
  •  
    Mexico

Posted 4 weeks ago

Looking more carefully to: https://docs.microso...ge-file-formats

 

We can say this .ffu format is very simmilar to a VHD/VHDX

 

Diferences are:

 

1 .- It is compressed by default (we can also make a Compact mode VHD/VHDX, in fact I have made some VHDs with WinNTSetup with several compression levels).
 

2.- It can only be mount (to a folder) and modiffy by Dism.

 

3 ,-  It is not natively bootable until it is applied to a HD.

 

4.- It can be deployed to a new HD (I assume also to a virtual HD but not tested yet).

 

5.- Includes a catalog and hash table to validate a signature upfront before flashing onto a device. The hash table is generated during capture, and validated when applying the image (wimlib-imagex is capable of similar procedure on all images created)

 

alacran



#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Well, as I see it, it is very different from VHD/VHDX exactly because of the (IMHO huge) differences you list, it is more similar to an .E01 or to some of the possible ways to make (in the good ol' times) a Norton .gho (GHOST) image.

 

Though I don't see why (your #4) a .vhd (at least a "static" one) cannot be deployed to a new hard disk.

 

:duff:

Wonko



#7 alacran

alacran

    Gold Member

  • .script developer
  • 1165 posts
  •  
    Mexico

Posted 4 weeks ago

Well, as said looking carefuly to https://docs.microso...ge-file-formats

Will try to make more clear my way of  thinking it:

This .ffu format is more similar to VHD/VHDX (even having those differences) than to a .wim image file.

 

I haven't seen or use .E01 files.

 

About .gho images,  I'm agree, I also saw the similarity with a .gho (Symantec Ghost) image file (which by the way is usually compressed too) but forgot to mention it.

 

alacran



#8 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 484 posts
  •  
    Italy

Posted 4 weeks ago

sorry to butt in, as usual, ... have u checked if it can be loaded by bootmgr or by g4d?



#9 alacran

alacran

    Gold Member

  • .script developer
  • 1165 posts
  •  
    Mexico

Posted 4 weeks ago

@antonino61

 

I haven't made a FFU image yet, but I don't think it can be loaded by bootmgr, or grub4dos by means of SVBus driver, because all info is compressed in a single file like in a .wim file, but including also all partitions layout of the source disk, not only files/folders and respective metadatas.

 

Think in this FFU format as a Ghost image file (.gho) or an Acronis Image file (.tib) wich is used for backup/recovery pourposes of the entire HD (on this FFU case) and as the two mentioned backup/recovery formats is not bootable, and it is presumably never will.

 

alacran



#10 f1ult23

f1ult23

    Newbie

  • Members
  • 21 posts
  •  
    France

Posted 4 weeks ago

You can read and test this ISO :

WinPE GUI-Windows 10 – Create and Apply FFU Images – Part 3

http://www.alexcompu...-images-part-3/

 

F1ULT23



#11 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

I haven't seen or use .E01 files.

JFYI, .e01, more properly EWF, info:

http://www.forensics...ile-format.html

of course here the difference is that ALL sectors are imaged, but there is compression and hash calculation/verification, and as a matter of fact this latter is pretty much the ONLY advantage when compared to a simple RAW or dd-like image (that you can anyway hash and/or compress manually):

https://dmeforensics...nalysis-e01-dd/

 

See also (again JFYI):

http://reboot.pro/to...ng-split-image/

 

:duff:

Wonko



#12 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 484 posts
  •  
    Italy

Posted 4 weeks ago

so a compressed form of source recovery (and/or possibly install) data. Do u think wimb will ever be able to use it as a compressed replacement for wim in the wimbooting terrain (uuf+vhd instead of wim+vhd)?



#13 alacran

alacran

    Gold Member

  • .script developer
  • 1165 posts
  •  
    Mexico

Posted 4 weeks ago

@antonino61

 

From a FFU image you can NOT make a Wimboot VHD.

 

alacran



#14 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 484 posts
  •  
    Italy

Posted 4 weeks ago

it woulda been only for space-saving's sake if it coulda been done.

thanks for the info.

nino



#15 alacran

alacran

    Gold Member

  • .script developer
  • 1165 posts
  •  
    Mexico

Posted 4 weeks ago

Additional info of a link about FFU (gotten from Retokener), see this page for full info: https://win10.guru/w...ure-deployment/

 

I'm going to quote here some relevant parts of the info related to comparative tests between .wim and .ffu

 

 

My subjective opinion: Full Flash Update (FFU) imaging is the best thing that has happened to Windows deployment. Ever. Where capturing your deployment image to a WIM file takes 10 minutes, capturing it to FFU takes under two. The time required to apply an FFU image is cut to less than half of what it takes to apply a WIM image, all else being equal.

 

 

I have done extensive testing over the past months, and now really appreciate the benefits of using FFU. Your own experience will most probably be much better, because you should hopefully be better able to capture and deploy Windows faster than on my ancient hardware. Everything recited below was learned using a Hyper-V VM with 4 GB of RAM and two virtual processors for both the reference and destination machines on my loyal workhorse, a low-end Asus laptop with an i5-4210U CPU @ 1.70GHz, 12 GB RAM and 1 TB 5,400 RPM spinner.

 

 

Here are some screenshots from a recent test run. In this case, I clean installed W10 Education x64 to a reference VM with a single 127 GB VHDX, of which installation consumed 10.4 GB. I also installed additional software. On the C: drive, the space consumed when I was all finished came to 13.1 GB. Then I booted to PE, and captured an FFU image:

011018_1142_WindowsFFUi1.png?resize=1018

Capturing FFU image on this test VM took just over 5 minutes. Click screenshot to enlarge.

Here’s the same VM, immediately after the FFU capture completed, capturing a legacy WIM image (which took more than SIX TIMES as long to finish):

011018_1142_WindowsFFUi2.png?resize=1018

The same VM, same Windows image, now as WIM. Over half an hour. Click screenshot to enlarge.

 

 

Note further that an FFU image (yellow highlight in below screenshot) is somewhat bigger than its respective WIM image (blue highlight):

011018_1142_WindowsFFUi3.png?ssl=1

 

 

Now let’s talk about deploying Windows, by applying the preceding images. To deploy an FFU image I’ll boot my destination machine to PE and use the following command, drive W: in this example being the mapped network drive where the image is stored:

dism /apply-ffu /ImageFile=W:\W10EDU.ffu /ApplyDrive:\\.\PhysicalDrive0

I’m still using a Hyper-V VM as the destination on my ancient host. First comes applying the FFU image, no partitioning required:

ApplySmallFFU.jpg?resize=1019%2C550&ssl=

Apply FFU image. Click screenshot to enlarge.

Now let’s apply the same image in WIM form, to the same VM. The time shown does not include time required to partition the destination disk (for a WIM file, this is obligatory if it’s not taken care using an answer file). This screenshot shows how I run first a DISKPART script to partition the HDD (not included in the measured time shown):

ApplySmallWIM.jpg?resize=1024%2C768&ssl=

Applying WIM image. Click screenshot to enlarge.

 

You better take a look to the page yourselves, there is more good info into it.

 

alacran



#16 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

I am not so sure/convinced that the comparison is relevant/fair/accurate.

 

The output .ffu file is 150% of the output .wim file (most probably because /compress:maximum has been used to capture the .wim, while - at least in theory - the corresponding mode to the ffu default is /compress:fast).

 

No idea about what a Hyper-V performance can be (nor all the other details of the test setup), but knowing the usual trade-offs with compression (size vs. data transfer speed vs. CPU and ram utilization) I wouldn't be surprised if the huge difference in capturing can be reduced in the real world by using a "fairer" compression level for the .wim.

 

When applying, I can understand that by-passing the filesystem (and its driver) can be much faster, though.

 

:duff:

Wonko


  • antonino61 likes this

#17 wimb

wimb

    Platinum Member

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

Posted 4 weeks ago

The most severe limitation is:

FFU Images cannot be captured from a partition and cannot be applied to a partition.

That means partitions identified by a drive letter cannot be used for capture or apply.

 

FFU Images can only be made from the entire physical disk using the disk number.

That means that all existing partitions of a disk are lost when the FFU image is applied.



#18 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Well, I don't understand.

 

Those are not limitations, they are actually features for a tool designed and intended in "mass manufacturing" to deploy an image to a new disk.

 

:duff:

Wonko



#19 wimb

wimb

    Platinum Member

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

Posted 4 weeks ago

 

Those are not limitations, they are actually features for a tool designed and intended in "mass manufacturing" to deploy an image to a new disk.

 

 

Sure  :)  But at the same time these features are experienced by me and probably by most of us as a limitation ....


  • blackbalfur and antonino61 like this

#20 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 484 posts
  •  
    Italy

Posted 4 weeks ago

wimboot is the future so far, until a better configuration and deployment system comes around, which has not yet, whether u like it or not.



#21 alacran

alacran

    Gold Member

  • .script developer
  • 1165 posts
  •  
    Mexico

Posted 4 weeks ago

Wonko the Sane, on 12 Nov 2019 - 04:06 AM, said:

Well, I don't understand.

Those are not limitations, they are actually features for a tool designed and intended in "mass manufacturing" to deploy an image to a new disk.

:duff:
Wonko


Yes, it was developed as a tool for fast capture and deploying exactly same disk layout and content, deleting all pre-existing content (if any) on HD.
 

wimb, on 12 Nov 2019 - 05:31 AM, said:

Sure :) But at the same time these features are experienced by me and probably by most of us as a limitation ....


I'm agree, this is also a severe limitation if we want to use it as a backup tool.

With Ghost (non free progam) we can make a compressed (and also spanned if we want) backup of the full disk, or a single partition, we can do same thing with Acronis True Image (there are free versions on Western Digital and Seagate pages), and also with several other free backup tools.

We can make free .wim images (with several compression options) with Dism or wimlib-imagex (or wimlib-clc) of every single partition or only the OS(s) partition(s), appending a new index respectively to each one to save space, and latter delete the older index if we want, even we can use Windows task programmer to make this capture an automatic task, as I did on my wife PC.

So .wim images are more versatile for backup pourposes.

Anyway for users having the OS on a SSD and all their documents on a separate bigger HDD, FFU may be useful to recover their OS to a pristine install state.

alacran



#22 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

Sure  :)  But at the same time these features are experienced by me and probably by most of us as a limitation ....


Sure :), I feel the same with my hammer, a tool intended and designed to drive nails into hard materials (and quite effective at it BTW).
I wish I could use it to paint walls, but *somehow* it doesn't work very well for it, or at least a brush works way better.

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)

Or with some other driver?

:duff:
Wonko
  • ReTokener likes this

#23 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 227 posts

Posted 3 weeks ago

Thanks to alacran, now we know about this feature of DISM.

It is interesting and for those of us who want to learn more, there is an new build of DismMoutService which is capabable to capture, apply and mount disks, using FFU file format. The limitations I found are: The captured disk must contain a serviceable Windows installation, the dism version must be 10.0.18362.1 and the command has to be executed running PE5.x

UEFI seems to be required anyway.

The list of requirements does not claim to be complete and will certainly be even more precise the more we find out.

 

Best regards   T.

 

Password is: dism


Edited by ReTokener, 3 weeks ago.


#24 wimb

wimb

    Platinum Member

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

Posted 3 weeks ago

The list of requirements does not claim to be complete and will certainly be even more precise the more we find out.

 

 

Thanks  :)

 

One of the requirements is to know the Password to open the 7z archive, which I found by trial and error to be Password = dism  ;)


  • ReTokener likes this

#25 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 227 posts

Posted 3 weeks ago

Sorry,

wimb is true, the password is: dism





Also tagged with one or more of these keywords: dism

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users