JFX

Thanks for the new 1.1.9 version. Would be nice if these additional 16 pixel for DarkMode could be optional.

Sure \Boot and \EFI folder should be decompressed, I'll add this. But why you want this for drivers in Windows 10 too?

@alacran Dism uses wimgapi.dll, just like WinNTSetup there is no difference. Of course it will always append a new image to an existing WIM file. Compact apply mode have no problem, it first normal applies and than compresses. It would be an issue if it forgets some files. I don't plan to add wimboot capture mode, it's a deprecated feature. @wimb & @alacran You know that the problem only occurs because you guys replacing the internal WimBootCompress.ini? Stop do that and wimgapi will work correctly.

I took a look with debugger on it. It does not look that wimgapi does anything wrong. It extracts WimBootCompress.ini and reads the PrePopulateList entries. After applying it opens all matching files and calls NtFsControlFile with FSCTL_DELETE_EXTERNAL_BACKING code. (That exactly the same I did in Beta 7) Now the problem is that the function succeeds but the files remain WIM backed. Some fail with error code 0xc000046d - that are your 3 "empty" files. However 0xc000046d means STATUS_OBJECT_NOT_EXTERNALLY_BACKED what makes no sense as the files is a pointer file. Seems this bug is only related to identical files inside WIM, that is not bound by hard links in the image.

Tools\WimBootCompress.ini is actually supposed to help Windows version that does not natively support wimboot/compactOS. So it should only apply to Windows 7/8.x. But it wasn't for some (wimgapi only) cases until beta 8. You can still use it with command line option "/wbc:{WimBootCompress.ini}". It will not replace the internal, but append it.

Hmm guess than this is a bug in wimgapi. It does not do anything special now and should be similar to a: set WIM_SKIP_WIMBOOT_CHECK=1 Dism /Apply-Image /ImageFile:install.wim /Index:1 /ApplyDir:X:\ /WIMBoot /EA

Don't know if it helps, but there are some wimboot changes made to Beta 8.

What's the content of the internal WimBootCompress.ini?

Both are used the WIM internal by wimgapi and the Tools one later by winntsetup. First one does not decompress any driver file other than wof.sys. WofTab extend your file property dialog with WOF related infos.

You mentioned that the problem only also occurred with deleted "Tools\WimBootCompress.ini". So it this earlier test it should have been (still) a pointer file.

3 party drivers are usually directly signed (having the a signature inside the *.sys file). But also could be signed inside a *.cat files like it is with build in drivers. Use sysinternals: sigcheck.exe -i "file" to find the respected cat file.

What happens if you delete Tools\WimBootCompress.ini and try than with wimgapi + wimboot?

"Do not update the boot code" is for bootsect.exe, what you mean is the combobox next to it (in case on NONE selected). Than it would not create a BCD store or add a new entry to it. But you can have one already - for example in multi boot environment or just rolling back a captured WIM. In some cases you may still want to select some of these checkboxes.

No, this is only an option to update the MBR and PBR code of the boot disk. I also don't see a reason to grey out an option for bcd option NONE.

I don't think your problems has anything to do with wimboot at all. There are no differences for compress or uncompressed files, so the problem must be something else. Also latest Windows 10 version does not really need any excluded file. Better focus on \Windows\Inf\setupapi.dev.log for information about driver install.

Hmm, only difference are backups and diff patches of ntoskrnl.exe. These should be now excluded, too. Also for wimlib it now sets HKLM\SYSTEM\Setup, WimBoot or Compact to 1. Can't imagine that this is the cause, but if now both works or both fail we know. BTW: I assume this is not a problem with Beta version, but also the latest Final?

Properly a difference in how the exclusion list is applied. For wimlib a can update (only in memory) the internal WimBootCompress.ini and wimlib takes care of everything. For wimgapi I have to do post progressing using my own code. Can you provide file list for both, right after applying? compact /s X:\*.* > compression.txt

My WimScript.ini is more or less the build in list that imagex.exe has. Microsoft is not using the WimBootCompress.ini to create the WIM they release. Adding to many entries could slow down the process as every filter has to be checked against every single file.

It works here with imagex.exe 18362.1, if you put all reference esd and cab files in a folder, lets call it REF and use a command line like abbodi1406 showed here

@yaschir What detail you mean? For F1 Help text, yes it uses TAB's what is really not optimal, as it depends on the size of characters used. It a bit tricky to get it right. @laddanator You already used an old machine, if you want to see differences use a 6 or 8 core CPU pair with a quick SSD.

@wimb There are 2 ini files. Tools\WimBootCompress.ini is only used for wimboot/compact applies Tools\WimScript.ini is used for capturing of WIM file.

PinningFolderList is about STORAGE_TIER_CLASS. The files will get performance class. Microsoft is using WimBootCompress.ini for everything, mine is fine for what it's used. @jaclaz Nah, I've a paranoid backup solution, no need to release the source code.

No, for command line you need to add -wimlib.

If I recall correctly there were 2 problems: the UUP apply and the "registry save bug" that only occurred on x86 systems. First one seems to be gone with newer wimgapi.dll but the second one still remains.

Yes, for applying a wim wimgapi is the best solution. Now it even have multi core decompression and supporting "recent" settings like "PinningFolderList". For Capture of course wimlib is much faster so I added a new setting: [Options] UseWimLIB=2