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 v3.8.8.3

Recommended Posts

Anyone figure out how to do a feature / build / version update (1703 to 1709) within a VHDX file?
Normal updates (Win+X > Update & security) work fine, but MS will not allow version updates on a USB or VHD / VHDX drive.
Tried obvious of mounting / attaching the VHDX, then cloning it to an internal partition, and then editing BCD to boot to the clone.
Acts likes it going to boot to the VHDX clone (on the internal HDD partition), but just ends up with the eternal gray screen.
Familiar with BOOTICE if that helps...TIA

Share this post


Link to post
Share on other sites

Yes, Microsoft does not allow OS upgrades with VHD(X) boot.
Easiest way would be to boot the VHD in Hyper-V and make the upgrade there.

Share this post


Link to post
Share on other sites
On ‎9‎-‎11‎-‎2017 at 10:31 PM, JFX said:

Yep, DISM command line does not allow more than one /SWMFile parameter.
And *.* is not accepted, so it requires that all files have the same extension.

Did you know that the latest imagex.exe does support multiple "ref" parameters? (I sure didn't). It also supports "*.*":

imagex /apply Education_en-us.esd 3 Z: /ref *.esd /ref *.cab
imagex /apply Education_en-us.esd 3 Z: /ref *.*

Abbodi1406 found out:

https://forums.mydigitallife.net/threads/windows-10-imaging-customization-and-deployment.59187/page-28#post-1388789

Share this post


Link to post
Share on other sites

Interesting, thought they wanted to deprecate imagex, but now it proves to be useful again.

Seems to work nice, just wonder does wimgapi/imagex 16299 works for you?

I'm always getting something like this:

Quote

J:\Download\uupdl\uup\16299.19\en-us\amd64>imagex /apply Education_en-us.esd 3 X: /ref *.esd /ref *.cab

ImageX Tool for Windows
Copyright (C) Microsoft Corp. All rights reserved.
Version: 10.0.10011.16384


[   8% ] Applying progress: 7:34 mins remaining
[ RETRY ] Restoring X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll again (Error = 1784)


[ RETRY ] Restoring WIM J:\Download\uupdl\uup\16299.19\en-us\amd64\Microsoft.ModernApps.Client.All.esd, offset 0000000006f59b8a, length cc4ec2 again (Error = 6)


[ RETRY ] Restoring WIM J:\Download\uupdl\uup\16299.19\en-us\amd64\Microsoft.ModernApps.Client.All.esd, offset 0000000006f59b8a, length cc4ec2 again (Error = 6)


[ RETRY ] Restoring WIM J:\Download\uupdl\uup\16299.19\en-us\amd64\Microsoft.ModernApps.Client.All.esd, offset 0000000006f59b8a, length cc4ec2 again (Error = 6)


[ RETRY ] Restoring X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll again (Error = 6)


[ RETRY ] Restoring X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll again (Error = 6)


[ RETRY ] Restoring X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll again (Error = 6)


[ ERROR ] X:\Windows\InfusedApps\Packages\Microsoft.WindowsSoundRecorder_10.1706.1561.0_x64__8wekyb3d8bbwe\PersonPicture.UAP.dll (Error = 6)

Error restoring image.


Das Handle ist ungültig.

But it is working fine with wimgapi 15063.

Edited by JFX

Share this post


Link to post
Share on other sites

I'm still testing as well, my first test was with imagex.exe from the dism folder (using your GetWAIKTools) in PE. This was version 16299, x86, and gave no errors. But it looked to finish too quickly, so I thought something must have gone wrong. I cleared the partition again (didn't run the install), then ran WinNTSetup, to time how long that took. WinNTSetup did the apply in around 7 minutes. After that I checked the size of C:, around 5.6gb was applied. So I tested imagex.exe again, it finished in 5 minutes, also with 5.6gb applied. Huh? How can it be so much faster?!

The install seems to have gone OK while I'm typing this, so lots of interesting stuff to test and analyze...

 

Share this post


Link to post
Share on other sites

Time difference could be caused by disk caching, here on a ryzen + ssd system
I get simular times for both (around 2 minutes +- 5 seconds).

Share this post


Link to post
Share on other sites

Repeated the test, with a reset inbetween. Still 5 minutes for imagex, 7 minutes for WinNTSetup.

Does it have something to do where you set the temp/ extract folder, or maybe verify on/off? (Just blurting out something, as I said, the first time I tried imagex I thought maybe it skipped files, but it doesn't seem to be that way).

Share this post


Link to post
Share on other sites

No, there is no verify made and temp folder is set to be the installation drive.

Do you measured yourself or are the 7 minutes from the WinNTSetup.log?

Share this post


Link to post
Share on other sites

OK, thanks, I was wondering about verify and temp folder. Yes, I measured by old-fashioned manual timer :-)

But I don't want to go too much off-topic, just wanted to share the remarkable difference.

Share this post


Link to post
Share on other sites

Last message about the difference between WinNTSetup apply and "manual" Imagex,exe 10.0.16299.15 (using unmodified/ unconverted UUP files).

I have repeated all the tests, using PE versions from Windows 7 (3.1) upward. Tests were done on a spare laptop (Pentium dual core TT2370, 3gb, apply from external 2.0 usb hd to internal hd). Reboot between tests (no disk cache effect). For WinNTSetup (3.8.8.2b1), the timer is stopped as soon as the apply stage is done (when it starts applying tweaks).

Pretty much all tests show WinNTSetup takes 7:00 minutes, manual apply with Imagex.exe takes 4:55 to 5:00 minutes.

I'm not coplaining about WinNTSetup at all (will still use it), I just wonder where this time difference is coming from. And of course, I wonder why Microsoft is "hiding" this fast UUP-functionality in Imagex.exe ...

 

Share this post


Link to post
Share on other sites

I'm still curious about the exact time that is written to the log file :rolleyes:

Something like this:

Successfully applied WIM Image. (Operation took: 1:03 min)

 

Edited by JFX

Share this post


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

Sorry, forgot about that. Log file says "Operation took: 7:47 min)".

I.e. much more than what you manually measured? :w00t:

Or do you have 3/4th of a whole minute in reaction time? ;)

jaclaz 

Share this post


Link to post
Share on other sites

Howdy :)

@Atari800XL
imagex time is the one reported as elapsed it after finish applying?
for me i used echo %time% before and after imagexin a script, the difference was ~ 3:40, while imagex reported 3:00

still, manual observation of WinNTSetup applying gives ~ 4:20

BTW, where do i find WinNTSetup log? :D
and it detects 1st index of UUP as 64bit
https://i.imgur.com/yNRfOpq.png

  • Upvote 1

Share this post


Link to post
Share on other sites

Hi abbodi1406,

The log is placed in the Windows folder of the chosen installation drive.

Seems a wim index without <arch> in the xml is interpreted as x64. Will fix this.

  • Upvote 1

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.

×