wimb

Thanks for your help and suggestion to use x64 wimgapi.dll version 10.0.15063.0 (from Windows 10 version 1703) supporting SHA1 and SHA2 GetWaikTools old Versions has GetWaikTools_v17.04 is giving x64 wimgapi.dll version 10.0.15063.0 I tried that wimgapi version in WimBoot mode, but the three drivers still have exclamation mark due to seemingly Unsigned driver. @jaclaz Indeed the wimgapi tool might be too "secure" or it might be in the code that JFX is using. In any case there must be somewhere a difference in the installation as compared to using wimlib. Until now the installation for Apply in WimBoot mode looks quite the same for wimgapi and wimlib and I haven't found the location giving the driver trouble .....

After Apply wimgapi + WimBoot Mode I tried to replace the complete registry with a backup (12 files) where drivers were working OK. It turns out that this replacement of the registry did not solve the problem. The three drivers as before were having exclamation mark due to seemingly Unsigned drivers, but as we know now it is only the Certificate that is not taken properly into account. Anyway I thought it is interesting to mention that a replacement of the registry cannot solve the issue. Where is the problem located ? Somewhere in ProgramData ? Some WOF Compressed files ? I checked in the VHD by using 7-zip that the drivers\*.sys files and Catroot folder are not WOF Compressed. Could it be that some other essential files need to be Uncompressed ? Anyway when WimBoot mode is not used in wimgapi Or when wimlib + WimBoot is used then all drivers are working OK.

Thanks for giving info about where and how to find driver certificate info. The three drivers giving problem have their signature inside the sys file. The drivers appear as Unsigned, but after Update driver then the same driver file appears as Signed. So it seems to me that the only problem is that the Certificate is not recognised ....

Removed WimBootCompress.ini and did Apply wimgapi + WimBoot Mode. Result is that system boots ok, but as before there are 3 drivers with exclamation mark due to apparently missing certificate. Do you know where the driver certificates are located ?

Testing now on my own computer ASUS-Z170 In case of wimgapi for Apply in WimBoot mode then some drivers seem to be unsigned and seem to have missing certificate. Updating the driver using the already present driver files resolves the problem. The Certificate is now visible. Where are the Certificates located and are they may be wof compressed for the drivers having problem ? ==

Thanks for your help. I will use 7-zip to investigate the vhd file to see whether the non working driver files are excluded for wof compression. Otherwise the best advice is to use wimlib for Apply in WimBoot mode, since then all drivers are working OK

The problem only occurs when wimgapi is used for Apply in WimBoot mode. In that case some non-Microsoft drivers get an exclamation mark, whereas they were properly installed in the captured installation. So it means that when the WimBoot mode is unchecked then wimgapi Apply also properly installs the drivers. It is completely dependent on using WimBoot I think it is a general problem, since I observed similar behaviour on other hardware and other architecture. Apply wimgapi + WimBoot mode makes that some non-Microsoft drivers fail to work (have exclamation) mark May be something with files present as pointers instead of as real files ...

I think it is how the [PrepopulateList] is applied in wimgapi WimBoot mode as compared to wimlib WimBoot mode. The [ExclusionList] determines the wimlib Capture, which is used for both Apply cases .... so that cannot be the source of the problem.

Thanks for 4.0 Beta 7 version including BOOTICE and wimlib wimgapi Apply in WIMBOOT Mode of same WIM file as used before is giving the same problem as before. The 5 non-Microsoft drivers appear with exclamation mark and don't work .... The wimgapi Apply in WIMBOOT Mode has progress jumping from 26 % quickly to 100 % This was observed also in the previous version, but I thought it might be important to mention it here .... For wimlib Apply in WIMBOOT Mode then all drivers are working OK (no changes needed). Version 3.9.4 wimgapi Apply WimBoot Mode gives the same driver problem: 5 non-Microsoft drivers don't work.

https://1drv.ms/u/s!AqA1-Hg3ltssgoIroves3EeeLlM7FQ?e=FFkbQS The shared file compression.zip contains: wimgapi_compression.txt wimlib_compression.txt All operations were carried out after booting with WIN10XPE from RAMDISK First wimgapi was used to Apply the wimlib Captured file W10x64_1905.wim to VHD mounted as drive D: followed by compact /s D:\*.* > C:\WimBoot\wimgapi_compression.txt After formatting drive D: then wimlib was used to Apply same wimlib Captured file W10x64_1905.wim to VHD mounted as drive D: followed by compact /s D:\*.* > C:\WimBoot\wimlib_compression.txt

I am having an issue when using wimgapi for Apply in WimBoot mode using WIM files Captured with wimlib or wimgapi. The problem is that 5 non-Microsoft drivers get an exclamation mark that can be easily removed by Update of the drivers (already present in the installation). When using wimlib for Apply in WimBoot mode of the same WIM files Captured with wimlib or wimgapi then all drivers are installed correctly. In all cases I am using VHD + WimBoot mode. The wimgapi Apply problem does not occur when WimBoot mode is not used (mode unchecked). The wimgapi for Apply in WimBoot mode non-Microsoft driver problem occurs for both architectures x86 and x64 VX643-PC_System.txt

The Capture [ExclusionList] section in Tools\WimScript.ini is much shorter than in WimBootCompress.ini given by Microsoft. What is the reason not to use a lot of entries given by Microsoft ? Certainly useful can be entries like \Windows\Logs\* \Windows\Prefetch\* \Windows\Temp\*

Ok, Thanks for the Info

In VHD_WIMBOOT I am using WimBootCompress.ini file made by alacran that contains in the [PrepopulateList] files bootmgr and Boot\BCD and EFI\BCD occurring inside VHD. The files bootmgr and Boot\BCD are needed as file instead of as pointer when you want to boot with VHD from RAMDISK using SVBus driver and grub4dos menu. In your WinNTSetup.ini file the [ExclusionList] section is missing, but that section is probably useful during Capture e.g. to exclude the Windows\Prefetch folder It seems to me that your WinNTSetup.ini file is designed for Apply of WIM only and not for the new Capture of WIM option It seems to me that in your program WimBootCompress.ini is NOT used at all for the case of Capture, sice also my WimBootCompress.ini is Not effective. WimBootCompress.ini

The WinNTSetup.ini Option UseWimLIB=2 is quite convenient so that always the best solution is used: wimgapi for Apply and wimlib for Capture of WIM files What is the function of PinningFolderList section in WimBootCompress.ini ? In wimlib it is giving WARNING Unrecognized Section

Ok, so your advice is to use wimgapi for Apply of wim files, but for capture wimlib is doing much faster and the progress info is better. Capture with wimlib XPRESS takes 12 min and wimgapi for capture takes 25 min to make WIM file of about 10 GB for my OS + Programs. What do you think about using wimlib for Capture ?

Very Good I had a problem with version 1.3.4 of BOOTICE when using the UEFI tab with Edit boot entries to Add UEFI boot entry for Grub2. BootIce v1.3.4 does NOT allow me to Add UEFI boot entries, which I need for booting from Portable USB in UEFI mode with Grub2. The boot entry for booting with Grub2 from USB is not auto generated like is done for Windows OS. So you need to create the Grub2 boot entry by using a tool like BOOTICE 1.3.3.2

Various tests until now OK Still hoping that wimlib and BOOTICE will be integrated in the Download so that they are ready for use: - wimlib files libwim-15.dll - BOOTICE v1.3.3.2

The bugs are gone I think. Will continue to do more testing various cases ....

Much better and corrections are OK , but .... - The Ready dialogue has for Boot code Setting initially DoNot Update the boot code and NONE whereas it should be as in previous versions Use bootsect to Update boot code and UEFI (for my case of EFI Boot drive)

For Add Drivers and Unattend and Mode the checkbox can indeed now become unchecked when loading other ini file. So that is working OK. But there are some changes in the program in the initial case where there is no ini file yet, that are not OK: - The Boot drive does not get a drive letter, wheras it used to be auto selected as drive Z: - Mount Installation drive as is now set as E: instead of C: I think it would be better as the preset Index for the Windows 10 Edition was set to the most occurring index = 1 instead of to the highest index that is used now.

Since you have the option to Load an ini file, it is expected that all settings are adjusted accordingly. The Settings for the Apply of a Captured WIM file will be quite different as compared to the Settings for install.wim from Microsoft. So it makes sence to have different ini files available. It has nothing to do with setup 2 systems in 1 run. I just want to use another ini file instead of the default loaded WinNTSetup.ini file ....

In WinNTSetup.ini I have three lines for Drivers and UnattendedFile and ApplyMode that switch on Add Drivers and Unattend and Mode Checkbox. A loaded WinNTSetup_X.ini that does not contain such lines, does not remove the Settings as given by WinNTSetup.ini In other words for Add Drivers and Unattend and Mode the loaded WinNTSetup_X.ini is not properly taken into account to switch off these settings. I am using WinNTSetup_X.ini in case of Apply of a Captured WIM file, where I don't need to use most of these settings anymore.

Thanks, Crash Fix of WinNTSetup4 Beta 4 is working OK

Wrong type of wim file like boot.wim gives now when pressing Setup - Warning Windows Source invalid So the crash is gone and this solution is OK. There is another problem present in 4.0 Beta3 and Beta4 In case wimlib is used and Mode Wimboot Selected then After pressing Setup the program crashes. Using WimGAPI (all cases) Or wimlib with Mode Wimboot Unchecked Or other Mode are working OK. In version 4.0 Beta1 and Beta2 this problem did not yet occur.