MSIX libraries/runtimes are not visible in pending tasks

I

intelfx

Member
Messages
47
Reaction score
4
With NTLite 2025.10.10626 (latest update), trying to apply "Latest online updates" (including the MSIX/AppX runtimes NTLite suggests) to a Windows 10 LTSC 2021 image results in the MSIX/AppX runtimes not being visible in the pending tasks list. Additionally, there is a "Missing" (just the word "Missing") reported somewhere around the MSIX/AppX integration stage and the AppInstaller MSIX appears skipped (grey dot, not green).

I'm not sure whether the two problems are functional or visual only, nor whether they are related.
 

Attachments

You can't add MSIX or Appx packages to WinRE. NTLite should be blocking this task.
 
Runtimes are attached to the main MSIX package requiring them, so they are integrated all in one go.
There should be an indication of it on the Preview page, true, thank you for reminding me of this.
So in other words, it's just cosmetic.

As for the word Missing, please check the log next time if it has more info about it.
 
nuhi said:
Runtimes are attached to the main MSIX package requiring them, so they are integrated all in one go.
There should be an indication of it on the Preview page, true, thank you for reminding me of this.
So in other words, it's just cosmetic.
Click to expand...
Understood, thanks!
nuhi said:
As for the word Missing, please check the log next time if it has more info about it.
Click to expand...
Hrm. It appears I cannot reproduce the "Missing" popup. Reapplying the same profile to the same image does not seem to trigger it anymore. I will create a separate report if it happens again.
 
Your posted preset.
Code: 
                <ImageTasks>
                        <Task>imageSaveTrim</Task>
                        <Task>imageFormatWim</Task>
                        <Task>updates_boot.wim_01_9_64</Task>
                        <Task>updates_boot.wim_02_2_64</Task>
                        <Task>updates_Winre.wim_01__64</Task>
                        <Task>msix_Winre.wim_01__64</Task>  <<-----
                        <Task>drivers_boot.wim_01_9_64</Task>
                        <Task>drivers_boot.wim_02_2_64</Task>
                        <Task>drivers_Winre.wim_01__64</Task>
                        <Task>registry_boot.wim_01_9_64</Task>
                        <Task>registry_boot.wim_02_2_64</Task>
                        <Task>registry_Winre.wim_01__64</Task>
                        <Task>imageOptionsCreateIso</Task>
                </ImageTasks>
 
garlin said:
Your posted preset.
Code: 
                <ImageTasks>
                        <Task>imageSaveTrim</Task>
                        <Task>imageFormatWim</Task>
                        <Task>updates_boot.wim_01_9_64</Task>
                        <Task>updates_boot.wim_02_2_64</Task>
                        <Task>updates_Winre.wim_01__64</Task>
                        <Task>msix_Winre.wim_01__64</Task>  <<-----
                        <Task>drivers_boot.wim_01_9_64</Task>
                        <Task>drivers_boot.wim_02_2_64</Task>
                        <Task>drivers_Winre.wim_01__64</Task>
                        <Task>registry_boot.wim_01_9_64</Task>
                        <Task>registry_boot.wim_02_2_64</Task>
                        <Task>registry_Winre.wim_01__64</Task>
                        <Task>imageOptionsCreateIso</Task>
                </ImageTasks>
Click to expand...
This item is inserted automatically by NTLite 2025.10.10626 and cannot be unchecked. I assume it's a bug.
Regardless, I was not talking about adding anything to WinRE, so please stop playing gotcha with me.
 
That's why I said NTLite shouldn't be doing it. I'll refrain from answering your threads.
 
garlin said:
That's why I said NTLite shouldn't be doing it. I'll refrain from answering your threads.
Click to expand...
OK, perhaps I overreacted and I'm sorry for that. However, I hope you understand why I saw this as a completely irrelevant tangent at best (and derailment at worst): I was asking about apparent strange behavior in applying MSIXs to install.wim, my screenshot shows install.wim, and nowhere in my original question I even mentioned WinRE. It's just not what I was doing, and neither it was what I asked about.

From my side, this exchange looks like this:

Q: I'm applying MSIX to install.wim, and NTLite behaves strangely. Here is a screenshot of me applying MSIX to install.wim.
A: You can't apply MSIX to Winre.wim.
Q: That's not what I was doing.
A: See, here in your preset it shows you were doing it!
 
NTLite skips MSIX for WinRE anyway, regardless what the preset states, it's fine.
The thing is MSIX is tied to Updates, so it's treated as one, then it gets filtered out during integration depending on the edition type.
For example WinRE will get SafeOS WinRE update, while that one will not be applied to install.wim, just by enabling Updates for both.

Might add some kind of grouping on the Updates page for clarity, or just filter that WinRE MSIX entry in the preset for clarity to begin with.
Thanks.

edit: it's actually a bug from Safe OS integration forcing MSIX checkbox on the Apply page, will fix, just cosmetic but anyway important.
 
nuhi said:
NTLite skips MSIX for WinRE anyway, regardless what the preset states, it's fine.
The thing is MSIX is tied to Updates, so it's treated as one, then it gets filtered out during integration depending on the edition type.
For example WinRE will get SafeOS WinRE update, while that one will not be applied to install.wim, just by enabling Updates for both.

Might add some kind of grouping on the Updates page for clarity, or just filter that WinRE MSIX entry in the preset for clarity to begin with.
Thanks.

edit: it's actually a bug from Safe OS integration forcing MSIX checkbox on the Apply page, will fix, just cosmetic but anyway important.
Click to expand...
I wasn't planning to bother you once again about WinRE, but if we are talking about it anyway:

I noticed that at some point NTLite gained the ability to extract the SSU (servicing stack update) from a CU, if one is queued, and integrate it separately before any other upgrades (and before the CU), like this:
1759664758190.png
NTLite does this for both install.wim and boot.wim. However, it does not happen for Winre.wim. When we last discussed this, someone posted a link to a Microsoft article which said that SSU needs to be applied everywhere (unlike CU). Could you please also take a look at this, while at it?
 
Last edited:
Thanks, will do.
WinRE has only the SafeOS update, where servicing might not matter that much, but anyway nice to have and a is proper practice to update the servicing stack wherever user enables Updates propagation.
 
You must log in or register to reply here.
Back
Top