Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 

JFX

WinNTSetup v4.0

Recommended Posts

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

Share this post


Link to post
Share on other sites
34 minutes ago, JFX said:

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

The internal WimBootCompress.ini of the WIM file Applied with WinNTSetup is equal to my WimBootCompress.ini due to earlier Capture with wimlib in VHD_WIMBOOT

Capture with wimlib using --wimboot and --config replaces the internal WimBootCompress.ini file with the one used for Capture (property of wimlib)

Quote

However, special behavior applies if --wimboot is also specified. By default, with --wimboot specified, the file Windows/System32/WimBootCompress.ini in the directory being captured will be used as the configuration file. However, this can be overridden using --config; and this also causes the specified configuration file to be saved in the WIM image as Windows/System32/WimBootCompress.ini, overriding any that may be present on the filesystem.

WimBootCompress.ini

Edited by wimb

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Thanks for Beta 8

Driver Problem with wimgapi + WimBoot still the same, e.g. btfilter.sys file has normal size but composed of only byte zero

Edited by wimb

Share this post


Link to post
Share on other sites

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 

 

Share this post


Link to post
Share on other sites
On 9/28/2019 at 6:13 PM, JFX said:

Hmm guess than this is a bug in wimgapi. It does not do anything special now and should be similar to a: 

In Beta 8 for Apply wimgapi + WimBoot mode then most drivers are WOF pointers except for the troublesome drivers which files have normal size, but filled with byte zero.
The bug is that somehow wimgapi is treating some drivers differently .....

It seems to me that only the Internal Windows\System32\WimBootCompress.ini is used.
In what case and how is the file Tools\WimBootCompress.ini by WinNTSetup supposed to be used ?

Capture with wimlib using --wimboot and --config replaces the internal WimBootCompress.ini file with the one used for Capture (property of wimlib)
Such replacement of the internal WimBootCompress.ini does not seem to occur in WinNTSetup.

 

Edited by wimb

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for the Info.

How come that in Beta 8 for Apply wimgapi + WimBoot most drivers become WOF pointers and in Beta 7 are real files,
whereas both Internal and External WimBootCompress.ini files contain in the PrePopulateList a line \Windows\System32\drivers\*.sys ?
I assume that in Beta8 you overruled WimBootCompress.ini for drivers\*.* to be WOF pointers,  but I think it is better to have that action not hardcoded.
It is nice as a test since it has helped me to see where wimgapi is failing since there is a bunch of files not having the WOF pointer.

For Beta 8 the 3 troublesome drivers btfilter.sys and nvhda64v.sys and TeeDriverW8x64.sys are clearly visible in 7-zip (sorted for WOF) as being not a WOF pointer.

Beta8-wimgapi-drivers-2019-09-30_094115.thumb.png.8cee005bf526ddc0abf75988be5f83d9.png

Edited by wimb

Share this post


Link to post
Share on other sites

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. :ph34r:

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.

Edited by JFX
  • Like 1

Share this post


Link to post
Share on other sites

@JFX

I have been using WinNTSetup since long time ago and I love this little and very useful program, in fact AFAIR I was the first translator (spanish 2058.dll, just to do something in return for this fantactic tool and make it available to more people).

I liked now wimlib and BootIce are included on download, no more copy paste from previous folder and sometimes having copied an older version of wimlib.

This are my thoughts about future version 4:

Now that WinNTSetup is capable to capture installed OSs, it became a Backup tool and it needs to be trustable on all cases with no exception.

Not that it wasn't trustable before, but it is not so critical a new installed OS than a redeploy from your backup full with vital info, programs and third party drivers of our devices.

On new installs where no third party drivers are installed yet it seems there is not any issue, also this applies to standard installs (not wimboot) with third party drivers included.

It seems wimgapi is not a good option when dealing with wimboot when having third party drivers included on the *.wim, maybe it could be replaced by Dism for this job.

I know Dism is slower but better slow than wrong. Of course this may apply for people who only want to use MS tools.

B_7 was maybe working a little better since it was capable to extract fine all Windows (not third party) drivers (as per \Windows\System32\drivers\*.sys) and could be used on new installs including wimboot installs where no third party drivers are involved.

I think it is necesary to test Compact installs by means of wimgapi when having third party drivers included on the *.wim, to check if it can work fine on this scenario or not. And in case of troubles maybe it could be replaced by Dism for this job too.

As said before I know Dism is slower but better slow than wrong. Of course this may apply for people who only want to use MS tools.

Other option may be use only wimlimb on this scenarios, since it is very reliable and block wimgapi use (or hard code the automatic use of wimlib) on those scenarios where wimgapi has issues.

Maybe easier way is to do this is adding on main screen an user option for select:

new install to let the program (B_7 looks fine to me) work as usuall (with wimgapi or wimlib as selected).

or

redeploy backup to force only the use of wimlib looks like not a bad idea particularly for new users. I know select wimlib is available but not so easy to find, and as when selected the selection is not persistent (looks fine to me), then it is easy to forget re-selecting it next time.

And for capture the installed systems always use wimlib (at least as preselected option), faster, smaller size images and more reliable.

I haven't use this new feature of WinNTSetup yet but when selecting wimlib I don't see the very usefull option append (unless you aren't using capture and using directly append wich appends to existing file or creates it, if it do not exist), please would you confirm this?

Also when selecting wimlib don't see an option for wimboot capture. have you any plans for adding it?

I have been using wimlib for very long time, first on command line and latter by means of its GUI wimlib-clc (I'm beta tester and Spanish translator of this tool) for making (all included divers and programs) wimboot VHDs and  later compressed (130 MB and smaller) by lz4 (using lz4 Compressor) capable to Ramboot in just a few seconds without any issue.  Also as my backup tool for about 5 years and never had a single trouble, when I redeploy my OS from the backup image it always works flawlessly (7, 8.x or 10).

Best Regards

alacran

Edited by alacran

Share this post


Link to post
Share on other sites
On 9/30/2019 at 1:34 PM, JFX said:

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. :ph34r:

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.

Very Interesting :)
In Beta 8 wimgapi results mostly in WIM backed driver files (WOF pointers) allthough the PrePopulate list instructs to make real files.
In Beta 7 your code is doing better since then most driver files are indeed real files instead of WOF pointers.
In both cases for some drivers the process fails and the error occurs when in the WIM file there is no iNode for these files.

WIM_iNode-2019-10-04_074642.thumb.png.73bc21045b5469625529cacc84dd3ba6.png

As conclusion we can say that wimgapi cannot be used in wimboot mode and wimlib is doing fine for this purpose.

It would be better when for Capture the WimBootCompress.ini file in the WIM file is replaced by your Tools\WimBootCompress.ini file.
That is what wimlib Capture is doing when --wimboot --config option is used. 
In this way the user has easy influence on what is occurring for Apply when the Internal Windows\System32\WimBootCompress.ini is used.
As it is now the user can modify Tools\WimBootCompress.ini but these changes are not used during Apply.

Edited by wimb

Share this post


Link to post
Share on other sites

@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.

Edited by JFX

Share this post


Link to post
Share on other sites
2 hours ago, JFX said:

@alacran

@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.

Yes you are right. :)
I went back to the original Windows\System32\WimBootCompress.ini of Microsoft with simple PrePopulateList that does not contain the line \Windows\System32\drivers\*.sys
Then I did a Capture using WinNTSetup with wimlib and used the WIM file for Apply using wimgapi.
As you say indeed in that case there is no driver problem with wimgapi anymore.

It means however that we cannot PrePopulate with drivers in this way, which can be useful for booting VHD from USB in WimBoot mode on various hardware.
Also files \Boot\BCD and bootmgr inside the VHD are WOF pointers, so that booting with grub4dos from RAMDISK using SVBus driver does NOT work anymore.
For some cases it is desired to use modified WimBootCompress.ini and for that case wimgapi cannot be used in WinNTSetup, but wimlib will work fine.
It is also a bit confusing that your Tools\WimBootCompress.ini file that has the line \Windows\System32\drivers\*.sys is not used at all in case of Windows 10.
Only the WIM Internal Windows\System32\WimBootCompress.ini is used for Apply of Windows 10 with WinNTSetup.

Edited by wimb

Share this post


Link to post
Share on other sites
2 hours ago, JFX said:

@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.

Thanks for your quick answer.

Ok, as when 8.1U1 started with wimboot MS recommended to use Dim, and also I have seen DismApi.dll just next to Dism, I had the idea it used a different Api.

And yes you are right the problem is only present when using a custom WimBootCompress.ini on wimgapi, I apologize for insisting on this subject.

The key word is as you said: wimboot mode is a deprecated feature.

At least we can use wimlib for our custom lists.

Edited by alacran

Share this post


Link to post
Share on other sites

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

Edited by JFX

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...