Updating Winre.wim?

intelfx

New Member
Messages
28
Reaction score
0
How often (or at all) is the WinRE recovery image (Winre.wim) updated over the lifetime of a Windows major version?

And if yes, then how do I query the actual version/build of a Windows environment within a WIM image?
 
Hi,

add monthly cumulative updates to it, same like to Install.wim. You can easily chain that after loading the target install.wim edition, go to the Apply page -
Reapply - Integrate Updates - tick WinRE as well.

You can also see specific WinRE updates here, those starting with "Safe OS Dynamic Update".
Navigate older pages to see how often.
But this is more complex, it can be superseded by a newer Cumulative update, so use only if necessary.

I recommend adding cumulative updates, and in case of urgent fixes before the next cumulative update, add SafeOS update to it.
If anyone knows more on the correct practices regarding the SafeOS updates, feel free to chime in - I might add them to the update list if deemed often necessary.

Regarding the versioning.
After loading an image edition, tool will list found WinRE under it (for deployed Windows e.g. C:\Windows it's always listed if found).
Choose New Session in the Image toolbar (or restart the tool) and load the edition from newly listed WinRE.
After loading look in the status bar lower-right of it for the version info, should be the same as the install.wim one if patched.
 
Hi,

add monthly cumulative updates to it, same like to Install.wim. You can easily chain that after loading the target install.wim edition, go to the Apply page -
Reapply - Integrate Updates - tick WinRE as well.

You can also see specific WinRE updates here, those starting with "Safe OS Dynamic Update".
Navigate older pages to see how often.
But this is more complex, it can be superseded by a newer Cumulative update, so use only if necessary.

I recommend adding cumulative updates, and in case of urgent fixes before the next cumulative update, add SafeOS update to it.
If anyone knows more on the correct practices regarding the SafeOS updates, feel free to chime in - I might add them to the update list if deemed often necessary.

Regarding the versioning.
After loading an image edition, tool will list found WinRE under it (for deployed Windows e.g. C:\Windows it's always listed if found).
Choose New Session in the Image toolbar (or restart the tool) and load the edition from newly listed WinRE.
After loading look in the status bar lower-right of it for the version info, should be the same as the install.wim one if patched.
Oh, thanks, I missed the "N.1" WinRE image in the list (indeed, it only appears after install.wim is mounted, which makes total sense.

So then the question is, how do cumulative updates work? Does a cumulative update only apply on top of "its own" edition (like 22H2), or on top of any edition, or something in between?

In other words, I'm editing a Windows 10 22H2 installation image (10.0.19045.2965), but the non-patched Winre.wim shows as 20H1 (10.0.19041.1). Is it safe to apply the same cumulative update to the Winre.wim as I would to the main image (i.e. tick the "reapply" checkbox), or do I have to edit Winre.wim in its own session such that NTLite would pick the "right" cumulative?
 
So then the question is, how do cumulative updates work? Does a cumulative update only apply on top of "its own" edition (like 22H2), or on top of any edition, or something in between?
CUs have their own editions, or more correctly the base versions. You can find out which by reading it from the cumulative update version.
e.g. 19041, 22621, 26100 etc.
CUs are shared only between the same-basis editions which get converted into the higher one with a Feature Enablement package, like 19041->19045.
To not overcomplicate things, consider each Windows version to have their own CU, not each edition.

In other words, I'm editing a Windows 10 22H2 installation image (10.0.19045.2965), but the non-patched Winre.wim shows as 20H1 (10.0.19041.1). Is it safe to apply the same cumulative update to the Winre.wim as I would to the main image (i.e. tick the "reapply" checkbox), or do I have to edit Winre.wim in its own session such that NTLite would pick the "right" cumulative?
Question still open: is it better to skip CUs for WinRE and use only SafeOS updates.
Logic dictates that MS would not be releasing these SafeOS updates for no reason, it's just puzzling are they valuable only until CU for that month is out, or CUs block the integration of those SafeOS updates and do not contain the necessary fixes.

It is equally confusing why would they skip merging SafeOS fixes into the next CU, why allow Boot.wim updating with a CU, but not WinRE.

My recommendation for now is to integrate SafeOS updates to WinRE only - unknown if CUs have those fixes.
Or keep your machine disconnected while installing, then you don't have to update WinRE.wim/Boot.wim at all.
 
CUs have their own editions, or more correctly the base versions. You can find out which by reading it from the cumulative update version.
e.g. 19041, 22621, 26100 etc.
CUs are shared only between the same-basis editions which get converted into the higher one with a Feature Enablement package, like 19041->19045.
To not overcomplicate things, consider each Windows version to have their own CU, not each edition.


Question still open: is it better to skip CUs for WinRE and use only SafeOS updates.
Logic dictates that MS would not be releasing these SafeOS updates for no reason, it's just puzzling are they valuable only until CU for that month is out, or CUs block the integration of those SafeOS updates and do not contain the necessary fixes.

It is equally confusing why would they skip merging SafeOS fixes into the next CU, why allow Boot.wim updating with a CU, but not WinRE.

My recommendation for now is to integrate SafeOS updates to WinRE only - unknown if CUs have those fixes.
Or keep your machine disconnected while installing, then you don't have to update WinRE.wim/Boot.wim at all.
Sorry, I'm confused now :D
Should I disregard the original advice of applying CUs to Winre.wim via the Reapply menu?

w.r.t. not updating, I'm trying to build a customized Macrium recovery image (+ personal rescue toolkit) on top of that WinRE environment, and it's going to be network-enabled, so I'd like to have it updated if at all possible.
 
You can always use Settings to customize WinRE.wim and/or Boot.wim. If you want it to be strictly offline - get rid of all network drivers, protocols, and disable remaining network services. On top of that get rid of Non-UEFI Boot Manager if possible. I customize Marcium Reflect WinRE.wim that way to keep it fully offline.

I take it LCU and SafeOS update different files. Why would there be any conflict merging both even if MS isn't doing it in their official ISO's? Does SafeOS even update Boot Manager? That's very important for WinRE.wim. To this day, Black Lotus vulnerability has not been fully patched because of a 2011 MS certificate, removal of which is needed, but such removal messes up many machines, including the ones with common TPM 2.0. August 2024 LCU tried to remove that 2011 MS certificate, but ended up reverting changes due to BitLocker breakage.
 
If you want it to be strictly offline - get rid of all network drivers, protocols, and disable remaining network services. On top of that get rid of Non-UEFI Boot Manager if possible. I customize Marcium Reflect WinRE.wim that way to keep it fully offline.
As I just said, I *don't* want it to be strictly offline, on the opposite, I want it to be *strictly online* and that's why I want to follow the best practice in applying all applicable updates to it.
I take it LCU and SafeOS update different files. Why would there be any conflict merging both even if MS isn't doing it in their official ISO's? Does SafeOS even update Boot Manager? That's very important for WinRE.wim. To this day, Black Lotus vulnerability has not been fully patched because of a 2011 MS certificate, removal of which is needed, but such removal messes up many machines, including the ones with common TPM 2.0. August 2024 LCU tried to remove that 2011 MS certificate, but ended up reverting changes due to BitLocker breakage.
No idea.
So for now, I'm trying to process Winre.wim in a separate session, applying "Latest online updates" but unchecking the auto-selected Dynamic Update and replacing it with the latest SafeOS Dynamic Update which I downloaded manually, according to nuhi . This is quite painful to do on a continued basis but I don't see a better way.
 
I think we should just wait for NTLite update, which hopefully can provide options on how we can update WinRE.wim. I hope the option to force LCU onto WinRE.wim isn't going to disappear.
 
nuhi Okay, so I've found this article:


At a first glance, it says that one should not apply the LCU to the WinRE image (the "Add latest cumulative image" row is empty in the first column). However, there is this remark here:
Starting in February 2021, the latest cumulative update and servicing stack update will be combined and distributed in the Microsoft Update Catalog as a new combined cumulative update. For Steps 1, 9, and 18 that require the servicing stack update for updating the installation media, you should use the combined cumulative update.
Which means that the cumulative update has to be applied to the WinRE image, and it should be done *before* the LCU is applied.

So, I'm editing Winre.wim in a separate session, adding the LCU (at the time of speaking, this is KB5044273) and the SafeOS dynamic update (which is KB5044615). However, NTLite orders the dynamic update *before* the LCU, causing the LCU to get skpped:

1728926714661.png

However, if I manually apply the LCU and then, in a separate session, apply the SafeOS Dynamic Update, both updates are applied.

Is this a bug in NTLite, or does this mean that this specific LCU subsumes this specific Dynamic Update?
 

Attachments

  • 1728926517051.png
    1728926517051.png
    180.2 KB
nuhi Additionally, I noticed that when editing Winre.wim in "Save the image" saving mode, both Winre.wim and the containing install.wim are saved and unloaded. This is most likely a bug, or at least unwanted behavior. If I'm editing Winre.wim, then I'm expecting that only Winre.wim is saved and unloaded.
 
Win11 24H2 LCU msu is not applicable (actually metadata-skipped) for winre.wim
only the SSU update will be added

SafeOS DU is designed specifically for winre.wim only (although they could apply to boot.wim or install.wim)
 
Win11 24H2 LCU msu is not applicable (actually metadata-skipped) for winre.wim
only the SSU update will be added
That's simply not true using DISM on a pre-extracted update (update.mum).
I have compared WinRE with and without CU, the difference is huge, files are updated throughout.

Try it - mount WinRE 26100.1 and a copy of the same WinRE after CU (baseline + latest) in another mount dir and compare them.
If your method skips it, let me know how it was tested so that I can confirm on my side and adjust accordingly.

Thanks.
 
Last edited:
nuhi Okay, so I've found this article:


At a first glance, it says that one should not apply the LCU to the WinRE image (the "Add latest cumulative image" row is empty in the first column). However, there is this remark here:

Which means that the cumulative update has to be applied to the WinRE image, and it should be done *before* the LCU is applied.

So, I'm editing Winre.wim in a separate session, adding the LCU (at the time of speaking, this is KB5044273) and the SafeOS dynamic update (which is KB5044615). However, NTLite orders the dynamic update *before* the LCU, causing the LCU to get skpped:

However, if I manually apply the LCU and then, in a separate session, apply the SafeOS Dynamic Update, both updates are applied.

Is this a bug in NTLite, or does this mean that this specific LCU subsumes this specific Dynamic Update?
Thanks for the feedback.

Waiting on abbodi86 to shine the light (as he knows more about update mechanisms than me), to see if I will add SafeOS updates to the update list and skip CUs on WinRE by default.
Could also be that 24H2 has things changed in this regard, that article wasn't updated to it.

Btw when I added CU to WinRE, safe OS updates were skipped, which is the main problem - not to mention this article you found that CUs are not for WinRE.
Totally unexpected, we should not update 99% of the (WinRE) OS and focus only on SafeOS updates - will do some more file comparisons to see if CU includes those fixes.

A cumulative update (DISM) denies to integrate to something it does not belong to, so I thought there is nothing to discuss here as it obviously integrated fully, but it's still a murky topic.
 
OK, could not wait, here are my results of comparing the 24H2 WinRE Safe OS update (KB5044612) to the CU (KB5043080 + KB5044284):

tldr: CU is updating WinRE to the newer file versions than those in the SafeOS update and covers all except 4 files specific to WinPE.
Integrating CU after the SafeOS update gives the best result, file-version wise.


WinSxS SafeOS deployed:
amd64_microsoft-onecore-u..latform-facilitator_31bf3856ad364e35_10.0.26100.1287_none_2e47139510dbbd69
amd64_microsoft-windows-bootmenuux_31bf3856ad364e35_10.0.26100.2003_none_90ce7126c5447d25
amd64_microsoft-windows-filebasedwritefilter_31bf3856ad364e35_10.0.26100.1866_none_59fc6c23a096cc4d
amd64_microsoft-windows-i..dsetup-rejuvenation_31bf3856ad364e35_10.0.26100.2003_none_ee85fc1dc0a235bf
amd64_microsoft-windows-servicingcommon_31bf3856ad364e35_10.0.26100.998_none_dd2ec0a505011f9f
amd64_microsoft-windows-sysreset_31bf3856ad364e35_10.0.26100.1583_none_d7e0e85e2e7ee9ed
amd64_microsoft-windows-winpe_tools_31bf3856ad364e35_10.0.26100.2003_none_96ec7f5fe6c66288
amd64_microsoft-windows-winre-tools_31bf3856ad364e35_10.0.26100.2003_none_65ea7a331ff8c818
wow64_microsoft-windows-servicingcommon_31bf3856ad364e35_10.0.26100.998_none_e7836af73961e19a

CU deployed much more, including those but newer:
amd64_microsoft-onecore-u..latform-facilitator_31bf3856ad364e35_10.0.26100.1882_none_2e06a5f5110be4ea
amd64_microsoft-windows-bootmenuux_31bf3856ad364e35_10.0.26100.2033_none_90d17204c541c92a
amd64_microsoft-windows-filebasedwritefilter_31bf3856ad364e35_10.0.26100.1882_none_59fec7d7a0949877
amd64_microsoft-windows-i..dsetup-rejuvenation_31bf3856ad364e35_10.0.26100.2033_none_ee88fcfbc09f81c4
amd64_microsoft-windows-servicingcommon_31bf3856ad364e35_10.0.26100.1882_none_d6fb9750cbfecc9c
amd64_microsoft-windows-sysreset_31bf3856ad364e35_10.0.26100.1882_none_d7c08f622e97241f
amd64_microsoft-windows-winpe_tools_31bf3856ad364e35_10.0.26100.1882_none_969e1731e6fff600
amd64_microsoft-windows-winre-tools_31bf3856ad364e35_10.0.26100.2033_none_65ed7b111ff6141d
wow64_microsoft-windows-servicingcommon_31bf3856ad364e35_10.0.26100.1882_none_e15041a3005f8e97
(plus all the other updates for the whole OS)

Analysing beyond WinSxS, including the entire OS finally shows some benefit from the SafeOS update.
These were newer in the SafeOS update alone 10.0.26100.2003 vs 10.0.26100.1882/1150 (CU):
\Windows\System32\wpeutil.dll
\Windows\System32\wpeutil.exe
\Windows\System32\winpeshl.exe
\Windows\System32\wpeinit.exe

Integrating CU after the SafeOS update works the best, that covers WinPE and all of the CU updates, but SafeOS update must be integrated first as it denies to integrate after the CU.

Will add SafeOS to the update list and keep allowing for WinRE CU integration as well, properly sorted.
This sorting will require a tool update first, and to skip SafeOS update for the install.wim, as it does not deploy to anything except 26100.1.
 
Integrating CU after the SafeOS update works the best, that covers WinPE and all of the CU updates, but SafeOS update must be integrated first as it denies to integrate after the CU.

Will add SafeOS to the update list and keep allowing for WinRE CU integration as well, properly sorted.
This sorting will require a tool update first, and to skip SafeOS update for the install.wim, as it does not deploy to anything except 26100.1.
I just wanted to note that this topic was about Windows 10 22H2, and on this build right now it's exactly the opposite: current SafeOS update refuses to integrate before the CU. So whatever the solution is, it should take into account that it can go both ways.
 
I just wanted to note that this topic was about Windows 10 22H2, and on this build right now it's exactly the opposite: current SafeOS update refuses to integrate before the CU. So whatever the solution is, it should take into account that it can go both ways.
Must be the Servicing Stack update from the CU package that makes that difference. Thanks for the heads up, will include that in the tests.
SafeOS update should not depend on the cumulative update itself since Microsoft advertises it as independent in the Dynamic Update guidance.

To confirm this, try extracting the SSU CAB update from the CU MSU and add it together with the SafeOS, without the full CU.
 
Must be the Servicing Stack update from the CU package that makes that difference. Thanks for the heads up, will include that in the tests.
SafeOS update should not depend on the cumulative update itself since Microsoft advertises it as independent in the Dynamic Update guidance.

To confirm this, try extracting the SSU CAB update from the CU MSU and add it together with the SafeOS, without the full CU.
Yes, I can confirm, it's exactly the way you described. If I extract the SSU cab and queue all of 1) the SSU cab, 2) the SafeOS dynamic update, and 3) the remaining cab from the CU (or even the entire CU *.msu again), integration finishes correctly in this exact order.

(I did not try to diff the images between this order and the opposite order, though, to see if there were any material differences. Could you give me a hint, how do you diff the images effectively?)
 
Yes, I can confirm, it's exactly the way you described. If I extract the SSU cab and queue all of 1) the SSU cab, 2) the SafeOS dynamic update, and 3) the remaining cab from the CU (or even the entire CU *.msu again), integration finishes correctly in this exact order.

(I did not try to diff the images between this order and the opposite order, though, to see if there were any material differences. Could you give me a hint, how do you diff the images effectively?)
Great, will then automate that as well. Adding CU after it will update the rest of the files.

I use Beyond Compare, has multiple Diff options in the toolbar. Additional tip is to select all files and do right-click Compare for it to remove the identical ones on both sides, since it's a computationally intensive operation, it does not do it automatically.
 
That's simply not true using DISM on a pre-extracted update (update.mum).
I have compared WinRE with and without CU, the difference is huge, files are updated throughout.

Try it - mount WinRE 26100.1 and a copy of the same WinRE after CU (baseline + latest) in another mount dir and compare them.
If your method skips it, let me know how it was tested so that I can confirm on my side and adjust accordingly.

Thanks.

Yes, using pre-extracted LCU (update.mum) is not blocked for winre.wim
it's only LCU msu specific metadata block
XML:
<MSConditionalFeatures>
  <ConditionalFeature UpdateAction="Add" FeatureID="CumulativeUpdate_KB5039417" FMID="MSDN">
    <Condition Type="PackageAnyVersion" Status="NotInstalled" Name="WinPE-Rejuv-Package~31bf3856ad364e35~amd64~~" />
  </ConditionalFeature>
</MSConditionalFeatures>

you would think they added that condition for a reason :)
they also unified SafeOS DU package name Package_for_SafeOSDU
2024-10 SafeOS updates for Win10 v1809 and later are also changed to that name (24H2 already had it)
 
Yes, using pre-extracted LCU (update.mum) is not blocked for winre.wim
it's only LCU msu specific metadata block
XML:
<MSConditionalFeatures>
  <ConditionalFeature UpdateAction="Add" FeatureID="CumulativeUpdate_KB5039417" FMID="MSDN">
    <Condition Type="PackageAnyVersion" Status="NotInstalled" Name="WinPE-Rejuv-Package~31bf3856ad364e35~amd64~~" />
  </ConditionalFeature>
</MSConditionalFeatures>

you would think they added that condition for a reason :)
they also unified SafeOS DU package name Package_for_SafeOSDU
2024-10 SafeOS updates for Win10 v1809 and later are also changed to that name (24H2 already had it)
Someone should ask them why, it looks like an unnecessary limit, not to mention dangerous one not to update with CU after applying a Safe OS update.
CU adds to it, did not subtract that I could see.
Maybe the point is that CU blocks SafeOS integration, but we'll take care of that with the integration sorting and a user will need to start from a fresh WinRE, as original ISO will provide.

Not to mention if an individual CAB can be integrated, it's even more confusing.

Anyway, let me know if you find the reason regarding the MSU lock, until then this looks like:
SSU + Safe OS is mandatory, CU on top of it is optional - in my case recommended.
 
Back
Top