[Solved] Error in Windows 7 Setup after integrating updates and drivers in boot.wim

[AeonX]

I integrated KB2864202 (Kernel Mode Driver Framework), KB2990941 and KB3087873 (NVMe support) and a generic usb 3.0 driver (USB 3/XHCI driver stack for Windows 7) into boot.wim and I get this error in VMware:



I think this is a typical error that occurs when the ISO file \sources\setup.exe is different from the \sources\setup.exe file in index 2 of boot.wim.

So I opened index 2 of boot.wim with 7-Zip and saw that several files there had been modified, including setup.exe.



Why is NTLite modifying all these files?

PS: I forgot to mention that I tested the latest version of NTLite (version 2.3.8.8890), version 2.3.7.8850 and version 2.3.5.8714 (the oldest version I have backup) and I get the same result.

 

[AeonX]

Update:

Version 2.3.4.8675 seems to be the last one that is working correctly. From version 2.3.5.8714 onwards, NTLite does not copy setup.exe from boot.wim to the \sources folder of the ISO files, which generates the error in windows setup.

And the files were not modified by NTLite but by one of the updates (KB2990941).

I couldn't imagine that an update that adds a driver for NVMe would modify setup files.

 

[nuhi]

Hi,

cannot replicate this issue using latest version.
Added these 2 KBs into Win7 SP1 original ISO and no issues booting setup.
Also changes in the install.wim should not influence the setup (first boot) section.

NTLite updates boot.wim setup file when a Dynamic Update is detected, not present for Win7.
Let me know if you have a repeatable scenario that fails and would need setup files synchronization.
I tried integrating these to both install.wim and boot.wim, no issue booting.

 

[garlin]

When I integrate the 3 KB's (don't forget KDMF, to support CanonKong's USB driver), my WinPE gets stuck on the boot logo.
That's on VMware, and having the system disk in SCSI, SATA and NVME modes.

 

[AeonX]

Also changes in the install.wim should not influence the setup (first boot) section.

The problem occurs when I integrate updates into index 2 of boot.wim. More specifically KB2990941 which modifies files in \sources folder inside index 2 of boot.wim. Windows 10 cumulative updates also often do this when integrated into index 2 of boot.wim.

I tried integrating these to both install.wim and boot.wim, no issue booting.

Did you integrate KB2990941 too? He's the one causing the problem.

 

[Clanger]

Did you integrate KB2990941 too? He's the one causing the problem.

I have never had a problem integrating(either of the 2 nvme updates) that into boot.wim(setup) and install.wim on a single edition iso - en_windows_7_professional_with_sp1_vl_build_x64_dvd_u_677791. I havnt tried lately though.
Ive had issues with canonkong usb3 during install, safer was to add the intel driver into both wims then update to canonkong post install.

Not sure if ive tried that universal usb3 driver either, if i had i would probably be using it, either way there is a reason im not using it.

 

[AeonX]

I have never had a problem integrating(either of the 2 nvme updates) that into boot.wim(setup) and install.wim on a single edition iso - en_windows_7_professional_with_sp1_vl_build_x64_dvd_u_677791. I havnt tried lately though.

This is a relatively recent issue, version 2.3.4.8675 (April 21, 2022) and older copies the setup.exe file from index 2 from boot.wim to \sources folder on the ISO, newer versions do not, causing the error "driver is missing". I also had no problem before but it's been a while since I created Windows 7 images and I started having this problem now. But knowing what causes this is easy to solve, just open boot.wim with 7-Zip and copy the setup.exe file from \sources in index 2 to the \sources folder of the ISO. I use this exact same ISO.

Not sure if ive tried that universal usb3 driver either

I think it's the same driver, daniel_k posted the driver (I don't know if he created them but it looks like yes) and canonkong signed them and did extensive testing. I had no problems but I tested it in a few machines. It seems to occur more problems in more modern hardware.

There was an update in June 2021 that removes Vista support and changes a few things. You can try with this update if you have an old version. I was using the old version and updated now.

 

[garlin]

For comparison, I integrated the same files using W7's DISM.
And my boot.wim still hangs right after the logo. No differences after I removed the XHCI driver.

From the original thread, two posters asked about boot.wim support -- but no answers. Maybe it's only supported on install images.

 

[Clanger]

I dont need a "universal" usb3 driver because i only use intel 8/9th gen and their "unofficial" driver works on both wims without issue.

 

[Clanger]

View attachment 8092

Ive had that warning a few times on a hardware install, i dont know whether i had a brain fart or itsa bug.

 

[nuhi]

Thanks AeonX and garlin.
I also get stuck boot logo with that KB on VMWare, so I'll need your (AeonX) confirmation that it's fixed.
Returned the copy routine to not be just on Dynamic Updates, that was an unnecessary optimization that brought the issue for Win7.
It now detects setup.exe version and triggers copy if it is higher than the one on the ISO.

Sending test version, let me know how it goes.

 

[AeonX]

It now detects setup.exe version and triggers copy if it is higher than the one on the ISO.

Amazing

so I'll need your (AeonX) confirmation that it's fixed.

Yes, that was fixed, but there was another inconvenience.

Some files in boot.wim are older (lower timestamp) and lower version than those in the ISO and are being copied to the ISO as well.

Spoiler

Spoiler

Spoiler

Other files with newer version are also copied but this is ok and is even recommended by Microsoft:
https://support.microsoft.com/en-us...455a6b#bkmk_additional_steps_of_configuration

Manually sort the folder C:\temp\mount\sources by date, and then copy the updated files to c:\temp\src\sources.

 

[AeonX]

When I integrate the 3 KB's (don't forget KDMF, to support CanonKong's USB driver), my WinPE gets stuck on the boot logo.
That's on VMware, and having the system disk in SCSI, SATA and NVME modes.

I also get stuck boot logo with that KB on VMWare

Are you using the VM on VMware in UEFI mode? In UEFI mode I also get stuck on boot logo but in BIOS mode everything works normally.

I also get stuck at boot logo if I add an NVMe drive in the VM. This appears to be a VMware incompatibility with KB2990941.

https://superuser.com/questions/1300880/windows-7-sp1-with-nvme-driver-does-not-load-on-vmware-14
https://winraid.level1techs.com/t/a...r-virtual-nvme-controllers-windows-7-64/32802

 

[AeonX]

I dont need a "universal" usb3 driver because i only use intel 8/9th gen and their "unofficial" driver works on both wims without issue.

I agree with you, better to use official drivers. It is only necessary to add usb 3.x drivers for intel and amd because the vast majority if not all motherboards with usb 3.x connector have intel or amd chipset. Drivers for other manufacturers can be installed after installation. I just need mouse, keyboard and pendrive working during installation. I like to integrate as little as necessary into the ISO. That's why I preferred to use the generic driver but it has some incompatibilities with some devices so it's safer to go with the official drivers.

 

[Clanger]

AeonX A lot of people are too pig headed to even try 8.1, EI Pro being the best edition as you know. Their time and effort, not mine.
Still chipping away with LTSC 1809 captured images.

 

[garlin]

Are you using the VM on VMware in UEFI mode?

When using VMware, I will switch BIOS modes and Guest OS version to avoid adding false errors. I've learned the hard way.

 

[AeonX]

When using VMware, I will switch BIOS modes and Guest OS version to avoid adding false errors. I've learned the hard way.

I think only Windows 7 needs special handling since it doesn't support pure UEFI only CSM (Compatibility Support Module). I didn't find in VMware an option to enable CSM so I assume it works in pure UEFI. It also doesn't natively support USB 3.x or NVMe. I think changing the Guest OS basically changes the disk recommendation to be created and the usb version recommendation.

Still chipping away with LTSC 1809 captured images.

I'm over 1 year using 21H1 Enterprise, I'm thinking of migrating to LTSC 2019 It seems to me to be the best version of Windows 10 so far. With each new version it just gets heavier. I think the lightest version is LTSB 2016 but Nvidia drivers for Turing boards onwards is not supported, some games also require newer versions, so I see LTSC 2019 as the most balanced version.

 

[Clanger]

I see LTSC 2019 as the most balanced version.

It needs a lot of work but once its been tweaked its no too bad. Feels like sacriledge putting w10 on w7 capable hardware

when i can get numbers like this i care even less about w7 v w10.

Once LTSC 2021 is 2 to 3(better) years old it will be worth looking at.
This old dog learnt a new trick tonight(morning?) so im in a good mood

 

[nuhi]

Amazing


Yes, that was fixed, but there was another inconvenience.

Some files in boot.wim are older (lower timestamp) and lower version than those in the ISO and are being copied to the ISO as well.

Other files with newer version are also copied but this is ok and is even recommended by Microsoft:
https://support.microsoft.com/en-us...455a6b#bkmk_additional_steps_of_configuration

Thanks for the feedback, yeah the goal was to copy the updated files (if they exist) to the ISO.
But now you're telling me some of them are older, some are newer than the ISO to begin with... oh (wo)man....

OK, will add version check for all the copied files and sync them up, that will probably solve many mysterious issues with booting over the years.

Will send a test version when done.

 

[AeonX]

But now you're telling me some of them are older, some are newer than the ISO to begin with... oh (wo)man....

Yes, sorry for the work

Now the files are synchronized, I saw that you also copied the newest files in the ISO to boot.wim

However the version comparison only works correctly for .dll and .exe files. For other file types it may be better to keep the original ISO files or compare the timestamp.

I say this because 2 files have significant differences between the originals of the ISO and those of boot.wim that were copied to the ISO. The rest have different timestamps but same content.

\sources folder of the updated ISO

Spoiler

product.ini (comparison between the file in Professional VL and Ultimate ISO's and in boot.wim / ISO updated)

Spoiler

segoeui.ttf (comparison between the file in Professional VL ISO and in boot.wim / ISO updated)

Spoiler

I don't know if it makes any difference in practice but I'm reporting.

If you prefer that I continue in a private conversation, let me know.