Jump to content











Photo
- - - - -

Capture and apply Windows Full Flash Update (FFU) images

dism

  • Please log in to reply
129 replies to this topic

#51 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 November 2019 - 10:45 PM

UEFI and/or GPT format are not a requirement.

 

I was using a Win10XPE_x64 made using as source 10 x64 v1903 and respective Dism Version: 10.0.18362.1

 

I finally made FFU capture work, after reading this post:

 

 

I was having this exact same issue.  It appears there is a bug in ADK v1903. The WinPE ISO it produces allows for imaging an ffu to a disk, but will not capture the ffu from a disk. If, however, you use the v1809 of the ADK, this problem goes away.  I tried multiple times rebuilding the ADK using v1903 but ended up with this same error.  The ISO from v1809 works out of the gate and will image OS versions at least up to Win10v1909.

Source: https://social.techn...with-0x80070032

 

I decided to make a new Win10XPE_x64 using as source 10 x64 v1809 and also (EDIT: Previous comment is Not required) went to http://jfx.square7.ch/GWT/oldversion/and downloaded GetWaikTools_v18.10.zip, this version downloads Dism version 10.0.17763.1 (for 10 v1809).

 

After this, tried again booting this time from 10XPE_x64 (made from v1809) (EDIT: Previous comment is Not required)  + Dism version 10.0.17763.1 (for 10 v1809) and using same USB stick, this time FFU capture from DMS was successful on my CSM/MBR PC without any issue.

 

So UEFI and/or GPT format are not a requirement.

 

Attached Dism-Logs-2

 

Alacran

 

EDIT-1: I found the link to GetWaikTools_v18.10.zip is not working, I will attach it here, password is GetWaikTools

 

EDIT-2: I found Win10XPE builds made from v1809 have some troubles when dealing with a USB device, it sometimes fails creating a new file or folder or renaming a file/folder located on the USB, so I decided to go back using as source 10 v1903 and no more troubles with this issue. Of course I'm using Dism version 10.0.17763.1 (for 10 v1809) on Dism Mount Service.

 

GetWaikTools_v18.10.7z   185.5KB

Attached Files


Edited by alacran, 10 April 2020 - 07:03 PM.

  • wimb and Tokener like this

#52 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 November 2019 - 11:45 PM

No need to reboot to a WinPE when using a version of Dism without bugs for FFU capture.

 

I have a PC with Windows 10 x64 Pro 1709 (Dic 1017), just running DMS from it without rebooting from Win10XPE_x64, I was able to capture a wimboot VHD previously attached.

This was done using its internal Dism v10.0.16299.15, and also tested using Dism version 10.0.17763.1 (for 10 v1809), and FFU capture running fine too.

 

alacran


  • wimb and Tokener like this

#53 wimb

wimb

    Platinum Member

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

Posted 16 November 2019 - 07:51 AM

Good that you made FFU capture working in your PE by using the proper Dism version 17763 instead of 18362 which fails with Error 50.

 

I confirm that my earlier Error 50 for Capture when using DismMountService_x64 inside Windows 10 1909 version is solved by using File > Set Dism File to Dism of GetWaikTools_v18.10

 

In DismMountService_x64:

Mounting an FFU Image File to folder mount_ffu involves that _ffumount24615145.vhd file of 14 GB is made in C:\Users\Vx64W\AppData\Local\Temp

The file _ffumount24615145.vhd is Attached as Disk 5 without getting drive letter.

This operation works in Windows 10 but fails in Win10XPE since then RAMDISK B: of 7 GB is too small to create the temporary _ffumount24615145.vhd file

 

Attached File  FFU_Mount-2019-11-16_083052.png   486.13KB   0 downloads


  • Tokener and alacran like this

#54 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 16 November 2019 - 08:48 AM

thank you alacran and wimb for keeping us updated

wimb:

I confirm that my earlier Error 50 for Capture when using DismMountService_x64 inside Windows 10 1909 version is solved by using File > Set Dism File to Dism of GetWaikTools_v18.10

 

I tried this with no luck. Error: 32

 

Deployment Image Servicing and Management tool
Version: 10.0.17763.1
Capturing image
Error: 32
DISM failed. No operation was performed.
For more information, review the log file.

 

FYI I recently updated DismMountService in the download section of Reboot.pro.

 

thanks again   T.

 


  • wimb and alacran like this

#55 wimb

wimb

    Platinum Member

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

Posted 16 November 2019 - 09:42 AM

I tried this with no luck. Error: 32

 

 

Error 32 occurs when the Disk is in use

Try to use it on offline VHD file (double click VHD to mount as Disk)


  • Tokener likes this

#56 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 16 November 2019 - 10:15 AM

Thanks a lot

I tried the following:

- mounted VHD

- set offline

Result: Error: 21

 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
191116-105203
D:\AKTUELL\AUTOIT\GUI\DISM\DismMountService\DMS\DismMountService_x64.exe    19.11.16.1
Windows Build:    18362.1.amd64fre.19h1_release.190318-1202
2019-11-16 10:52:04 : Duration (sec):    0
dism.exe  /capture-ffu /capturedrive=\\.\PHYSICALDRIVE4 /name:"Disk 4" /description:"Microsoft virtueller Datenträger - 1.95 GiB" /imagefile="D:\TEMP\xvffdgbdfgb.ffu" /English
Deployment Image Servicing and Management tool
Version: 10.0.17763.1
Capturing image
Error: 21
DISM failed. No operation was performed.
For more information, review the log file.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
191116-105204
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 

then I tried

- mounted VHD

- removed letter

Result: Error: 87

 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
191116-105526
D:\AKTUELL\AUTOIT\GUI\DISM\DismMountService\DMS\DismMountService_x64.exe    19.11.16.1
Windows Build:    18362.1.amd64fre.19h1_release.190318-1202
2019-11-16 10:55:26 : Duration (sec):    0
dism.exe  /capture-ffu /capturedrive=\\.\PHYSICALDRIVE4 /name:"Disk 4" /description:"Microsoft virtueller Datenträger - 1.95 GiB" /imagefile="D:\TEMP\xvffdgbdfgb.ffu" /English
Deployment Image Servicing and Management tool
Version: 10.0.17763.1
Capturing image
Error: 87
An error occurred while processing the command.
Ensure that the command-line arguments are valid. For more information, review the log file.
The DISM log file can be found at C:\Windows\Logs\DISM\dism.log
191116-105526
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 

to this error 87 I found this:

 

 The machine is using the wrong version of DISM – This scenario is typically encountered in those situations where the user tries to apply a Windows 10 image using an older DISM version. In this case, the solution is to apply the Windows 10 image using the correct DISM version using the wofadk.sys filter driver.

https://appuals.com/fix-dism-error-87-on-windows-10/

I did not check the wofadk, will do this as soon as possible.

 

Thanks a lot   T.



#57 wimb

wimb

    Platinum Member

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

Posted 16 November 2019 - 10:19 AM

In Windows 10 x64 environment I only double clicked on the VHD file to mount as Disk, and nothing else like you mentioned .....

 

In DismMountService_x64 I used File > Set Dism File to Dism of GetWaikTools_v18.10



#58 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 17 November 2019 - 12:35 AM

 

Try to use it on offline VHD file (...)

I took it literally ...

 

Made some more tests and found that the only (mounted) vhd(x)s I could not capture in real windows, were vhd(x)s  I created running  Win10_1909. Virtual Disks created in PE / Win7 and containing Windows systems could be captured. :hyper:

 

Regards   T.

 

 


  • alacran likes this

#59 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 November 2019 - 02:41 AM

@ Retokener

 

Yes, it is important to remember Win10 1903 and 1909 are a surce of troubles for FFU: https://social.techn...with-0x80070032

 

@ All

 

A little late since wimb has already posted his very informative comparative tests info, but trying to give some additional info, this are my test using 10 1809 for create, capture (standard compression) and apply .ffu images (Tests made on CPU i3225 4 GB Ram 1333 MHz, single Sata II HDD MBR formated).

 

1 .- 10x64-WB.vhd is a fixed size Wimboot VHD 1.5 GB, used size is 450 MB, 10x64-WB.ffu size is 157 MB, made in 15 seconds, after formating (for testing pourposes) the VHD, the 10x64-WB.ffu image was applied in 12 seconds.

 

2 .- 10x64-EC4.vhd (made from same Wimboot 10x64-WB.wim as previous VHD), is an expandable max. size VHD 7 GB, (full install, no wimboot this time), installed as Compact 4K, used size is 4.58 GB, 10x64-EC4.ffu size is 4.55 GB, made in 3:22 min., after formating (for testing pourposes) the VHD, the 10x64-EC4.ffu image was applied in 2:45 min.

 

3 .- Both re-applied VHDs were tested and they boot fine.

 

Taking also in consideration wimb tests results I may conclude:

  • FFU is the faster option for capture/apply, but not the smaller image size.
  • I admit it is not the best for backup pourposes of the full main HD since when applying it always overwrites all partitions (something we may not want to happend), but for deploying first install of OS(s) it is unbeatable.
  • Also for backup (capture/apply) of VHD(s) it is unbeatable.
  • It is important to notice on No. 2 it is capable to make images of expandable + also Compact installed VHDs.
  • Also it is important to notice on No. 2 the used space of the source VHD (installed as Compact 4k using wimlib-clc) and the size of the .ffu image (standard compressed) are almost the same, I assume this is because compression used is the same on both cases.
  • I may then also conclude XPRESS HUFFMAN = Compact 4K = Wimboot (standard is 4K too)

 

Best Regards

 

alacran



#60 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 November 2019 - 04:33 AM

JFYI

 

I have been using DismMountService_191115 for all previous tests, I noticed if I open Options Tab and select Compression only valid options for FFU Capture are Default and None, all other fail with Error 87.

 

Then using None I made another 10x64-WB.ffu

 

 

2019-11-16 21:18:03 : Duration (sec):    19 >>> 455 MB

C:\Windows\System32\dism.exe  /capture-ffu /capturedrive=\\.\PHYSICALDRIVE1 /name:"Disk 1" /description:"Disco virtual de Microsoft - 1.49 GiB" /imagefile="F:\10x64-WB.ffu" /Compress:none /English

 

It takes 4 extra seconds to make it uncompressed, but anyway now it can be opened with 7zip, to see what is inside.

I noticed only some files/folders are seen on 7zip, so many more info is coded on some way that is not accessible by 7zip.

 

Attached comparative with source VHD (located on left side of pictures)

 

Alacran

Attached Files

  • Attached File  1.png   358.77KB   0 downloads
  • Attached File  2.png   268.41KB   0 downloads
  • Attached File  Pictures.7z   409.39KB   1 downloads


#61 wimb

wimb

    Platinum Member

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

Posted 17 November 2019 - 07:29 AM

 

Made some more tests and found that the only (mounted) vhd(x)s I could not capture in real windows, were vhd(x)s  I created running  Win10_1909. Virtual Disks created in PE / Win7 and containing Windows systems could be captured. :hyper:

 

 

OK good that you in real Windows can do now FFU Capture of mounted VHD files.

The VHD's that I create in Windows 10x64 1909 with WinNTSetup Or with VHD_WIMBOOT can always be used for FFU Capture.

So I don't understand the limitation that you reported about.

 

@alacran

For me WIM files remain by far the most interesting for Capture and Apply of Windows installations.

For Full Windows I think FFU Capture and Apply is only slightly faster as compared to WIM Capture and Apply.

The difference in time is not so important for me. In most aspects FFU is not as good or handy as WIM for Capture and Apply.



#62 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 17 November 2019 - 08:30 AM

The VHD's that I create in Windows 10x64 1909 with WinNTSetup Or with VHD_WIMBOOT can always be used for FFU Capture.

So I don't understand the limitation that you reported about.

@wimb

I create vhd(x) mostly with vmount, for the tests above I tried also diskmgmt.msc.

so we used different tools to create our vdisks.

I will create vdisks your way and report.

regards   t.

 



#63 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 November 2019 - 10:40 AM

@ Retokener

 

I always prefer to create my VHDs (fixed or expandable) directly with Windows Disk Management, of course the two tools wimb mentioned also make use of it.

 

@ All

 

In order to experiment the full capavilities and limitations of FFU I just ran a few more tests:

 

Using same 10x64-WB.wim and a 15 GB expandable VHD, MBR with tree partitions as following:

 

First Primary Partition FAT-32 Active:  Boot: used 9.57 MB of 512 MB

Second Primary Partition: NTFS Windows: used 7.24 GB of 10 GB

Third Primary Partition: Documents: used 908 MB of 4.5 GB

 

Installed Win to second partition by means of DismMountService_191116 (Dism 10.0.17763.1): 7.24 GB >>> 268 sec.

 

Installed all required files/folders on Boot partition, and copied some files/folders to Documents partition just to better simulate an usuall HD.

 

Then captured the 10x64-WB.vhd (8.136 GB used) as Image.ffu on 87 sec.  FFU size: 5.05 GB

 

Created a new 15 GB 10x64-WB-2.vhd only inicialized but not formated and applied the FFU on 193 sec. (193/268 = 0.72 or 28 % faster than WIM).

 

Then I mounted the FFU with DMS to a folder on my HD and only thing visible is Windows partition, the other two partitions do not appear (Yes, I have active since the source Wim and also on the running OS show all Hiden files, folders and drives and also unactivated Hide Protected files of OS), but on Windows Disk Management it is possible to assing a letter to each one of the partitions of the mounted FFU and this way all can be seen, good if we need to extract only some files/folders from a partition to a location on our HD, from the Mount folder only Windows remain visible, then removed the assigned letters and dismounted the FFU without making changes.

 

I though as a remote possibility that maybe if a partition do not exists during capture it may be possible it will not be erased during apply the FFU.

To test this I deleted Documents partition on 10x64-WB.vhd and recaptured the VHD as Image-2.ffu, dismounted it and mounted 10x64-WB-2.vhd and formated Boot and Windows partitions without touching Documents partition and re-applied the new Image-2.ffu, and when finished the 10x64-WB-2.vhd only has the Boot and Windows partitions and Documents partition dissapeared, there is a free unformated space corresponding to Documents partition location.

 

Well, only thing I can say is I'm agree with wimb: WIM files are more versatile and usefull than FFU files.

 

But also I can say: I tested all alternatives that came to my mind and I keep no doubts now about how FFU works.

 

alacran


  • wimb and Tokener like this

#64 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 17 November 2019 - 03:40 PM

After capturing to FFU failed in Win10 1909 (post #56), I wanted to know in which situation an attached disk can be captured to FFU. The procedure was this:

On Win10x64 1909

- created vDisk 37GB MBR
- mounted it

- created 37GB partition NTFS
-> could not capture this disk to FFU by DISM (any version)

- applied boot.wim from some PE5 to 37GB partition
-> successfully captured disk to FFU using DISM (10.0.17763.1)
-> could not capture this disk to FFU by DISM (10.0.18362.1)  Error: 50

- formatted 37GB partition NTFS
-> could not capture this disk to FFU by DISM (10.0.17763.1)  Error: 87
-> could not capture this disk to FFU by DISM (10.0.18362.1)  Error: 50

- copied some files to 37GB partition NTFS
-> could not capture this disk to FFU by DISM (10.0.17763.1)  Error: 87
-> could not capture this disk to FFU by DISM (10.0.18362.1)  Error: 50

- applied boot.wim from some PE5 to 37GB partition
-> successfully captured disk to FFU using DISM (10.0.17763.1)
-> could not capture this disk to FFU by DISM (10.0.18362.1)  Error: 50

- deleted System32 folder from applied Windows Directory
-> could not capture this disk to FFU by DISM (10.0.17763.1)  Error: 87

- restored System32 folder to applied Windows Directory on 37GB partition
-> successfully captured disk to FFU using DISM (10.0.17763.1)

- deleted System32\config folder from applied Windows Directory
-> could not capture this disk to FFU by DISM (10.0.17763.1)  Error: 0x8000ffff

- restored System32\config folder to applied Windows Directory
- deleted all files from System32\config but SYSTEM and SOFTWARE
-> successfully captured disk to FFU using DISM (10.0.17763.1)

- formatted 37GB partition NTFS
- created \Windows\System32\config folder
- copied SYSTEM and SOFTWARE to config folder
- copied some files to 37GB partition
-> could not capture this disk to FFU by DISM (10.0.17763.1)  Error: 87

- converted disk to GPT
-> could not capture this disk to FFU by DISM (10.0.17763.1)  Error: 87
-> successfully captured disk to FFU using DISM (10.0.18362.1)

 

btw. DismMountService was updated, download here.

 

Regards   T.



#65 wimb

wimb

    Platinum Member

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

Posted 17 November 2019 - 06:14 PM

Interesting but strange behaviour and a lot to worry about FFU Capture ..... :ph34r:

 

Does it mean that it is not the way you created the VHD, but it is mainly the content of the VHD and the Dism version that can give trouble .... ?

 

Anyway VHD with "normal"content and using proper Dism version is working OK it seems ....

FFU Capture followed by Apply is booting OK in that case ....



#66 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 November 2019 - 06:52 PM

Very good tests, ReTokener :thumbsup: 

 

 

- restored System32\config folder to applied Windows Directory
- deleted all files from System32\config but SYSTEM and SOFTWARE
-> successfully captured disk to FFU using DISM (10.0.17763.1)

- formatted 37GB partition NTFS
- created \Windows\System32\config folder
- copied SYSTEM and SOFTWARE to config folder
- copied some files to 37GB partition
-> could not capture this disk to FFU by DISM (10.0.17763.1)  Error: 87
 

More or less this means that the stupid DISM, in stupid FFU mode, reads some info in either System or Software, which is linked to the actual volume/filesystem (i.e. something that the format command changed) probably the volume serial.

 

:duff:

Wonko


  • Tokener likes this

#67 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 17 November 2019 - 07:06 PM

 

wimb:

Does it mean that it is not the way you created the VHD, but it is mainly the content of the VHD and the Dism version that can give trouble .... ?

Yes, it is not the way it is created.

 

Running systems, successfully captured to FFU and applied to disk never failed so far.

 

The rules under which a capturing succeeds, are difficult to understand.

If the disk is GPT, DISM (10.0.18362.1) captures it regardless to the content. (on Win10 1909)

 

 

wonko:

dism (...) reads some info in either System or Software (...)

The config folder must contain SYSTEM and SOFTWARE, the other files may be missing for successful capturing.

 

Regards   T.


Edited by ReTokener, 17 November 2019 - 07:06 PM.


#68 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 November 2019 - 07:52 PM

Yes, it is not the way it is created.

 

Running systems, successfully captured to FFU and applied to disk never failed so far.

 

The rules under which a capturing succeeds, are difficult to understand.

If the disk is GPT, DISM (10.0.18362.1) captures it regardless to the content. (on Win10 1909)

 

The config folder must contain SYSTEM and SOFTWARE, the other files may be missing for successful capturing.

 

Regards   T.

Sure,

but what I was trynig to highlight is that your report implies that either (or both) SYSTEM and SOFTWARE are accessed by the DISM FFU AND if in it (or them) there is a reference to the volume (the only thing that changed when you formatted it) the capture will fail.

 

Conditions:

1) a path \windows\System32\config must exist

2) inside it BOTH SYSTEM and SOFTWARE (registry hives) must exist

3) inside EITHER (or both) SYSTEM and SOFTWARE *some* references to the volume (probably the serial) are checked by DISM FFU capture

 

If any of the above  3 (three) conditions is not fulfilled, the capture will fail.

 

Corollary:

If it is found which specific keys are read, it would become trivial to create "dummy" SYSTEM and SOFTWARE hives in \windows\System32\config completely empty BUT for the values that DISM FFU checks.

 

Or add a very small partition containing just \windows\System32\config\SYSTEM AND \windows\System32\config\SOFTWARE (with the "right" data related to the volume).

 

BTW, I am only trying to explicit what comes out of your reports.

 

:duff:

Wonko


  • Tokener and antonino61 like this

#69 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 17 November 2019 - 09:28 PM

wonko:

Or add a very small partition containing just \windows\System32\config\SYSTEM AND \windows\System32\config\SOFTWARE (with the "right" data related to the volume).

 

I tried this:

post #64

 

- formatted 37GB partition NTFS
- created \Windows\System32\config folder
- copied SYSTEM and SOFTWARE to config folder  EDIT: (from previously capturable disk)
- copied some files to 37GB partition
-> could not capture this disk to FFU by DISM (10.0.17763.1)  Error: 87

it seems that more conditions have to be redeemed.

 

Best regards   T.



#70 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 November 2019 - 09:47 PM

@wonko

Do not be modest, please. If I may, you are not trying to explicit; you are trying to formalize.



#71 wimb

wimb

    Platinum Member

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

Posted 18 November 2019 - 06:45 AM

@ReTokener

Can you extend the DismMountService program so that it can be used as well for Capture and Apply of WIM files to disk drives ?

 

That would be an interesting improvement of the program  B)



#72 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 18 November 2019 - 07:37 AM

@Retokener
Yes :),
but you (of course) applied the "same" SYSTEM and SOFTWARE hives after having re-formatted the volume, hence some data in the volume changed by effect of the re-formatting, evidently making the SYSTEM and SOFTWARE hives "dis-connected" from the current volume.
 
The experiment needed is the following:
1) get to the point of a "capturable" disk with only SYSTEM and SOFTWARE hives in \Windows\System32\Config
2) make a dd-like copy of:
a. the MBR (you never know)
b. the bootsector (or $Boot file)
3) make a "normal" copy/backup of BOTH SYSTEM and SOFTWARE hives from \Windows\System32\Config
4) format the volume
5) restore the copy/backup of BOTH SYSTEM and SOFTWARE hives to \Windows\System32\Config
6) try capturing the disk (it should fail as in your report with error 87)
7) restore the dd-like copy of the bootsectror
8) try again captuing the disk (what happens? [1])
 
@antonino
JFYI <_< :
https://www.quotes.net/quote/39361
 
 

I was born modest. Not all over, but in spots.

 
:duff:
Wonko
 
 
 
 
[1] it is possible that restoring the bootsector as it was before the formatting allows DISM to work, or maybe not (it could be date/time of the directories or of the SOFTWARE/SYSTEM files or a number of other reasons, like the entry number in the NTFS $MFT for the directories or files.



#73 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 18 November 2019 - 12:25 PM

@ReTokener

Can you extend the DismMountService program so that it can be used as well for Capture and Apply of WIM files to disk drives ?

 

That would be an interesting improvement of the program  B)

 

It is already capable to apply WIM files, see:

 

From a previous post

 

Installed Win to second partition by means of DismMountService_191116 (Dism 10.0.17763.1): 7.24 GB >>> 268 sec

 

And he has also a little separate program DismCaptureGUI.

I have been testing DismCaptureGUI with excelent results, no issues found so far, all is working fine, sorry if I don't share it with you and all members of the forum but I have to respect the developer desition about release it. I'm sure you understand this.

 

alacran

Attached Files


  • wimb and Tokener like this

#74 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 18 November 2019 - 12:40 PM

 

alacran:

I have been testing DismCaptureGUI with excelent results

Thanks a lot for testing my friend.

 

I have integrated Capture capability into DMS and invite all users to test it.

Download here on Reboot.pro

 

Attached File  Zwischenablage01.jpg   106.28KB   0 downloads

 

Attached File  Zwischenablage02.jpg   113.07KB   0 downloads

 

Best regards   T.


  • wimb and alacran like this

#75 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 18 November 2019 - 01:34 PM

Thanks a lot for testing my friend.

 

Best regards   T.

 

You are welcome, it has been always a pleasure to test all your programs, (and trying to contribute with some little suggestions), starting from your great wimlib-clc several years ago; I liked a lot this new version with capture integrated (remember I asked for this addition about a week ago), and will start testing it ASAP.

 

I beg you to excuseme for start making suggestions just after seen your new version and without even tested it, but IMHO the only thing you need to add to DMS, is the same BCD_Boot-Gui you have embeded on wimlib-clc to make it a totally complete tool as wimlib-clc is.

 

Your friend

 

alacran

Attached Files


  • Tokener likes this



Also tagged with one or more of these keywords: dism

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users