KB5004752 (August 2021 .Net 4.8 Cumulative Update) on Server 2016 (v1607) CBS Error

bseklecki_ge

bseklecki_ge

Member
Hi all!

I want to ask the collective brain trust about a KB/DISM error causing a roll-back on first boot.

I have some difficulty with KB5004752 ( the August 2021 DotNet4.8 Cumulative Update) on WinServer 2016 (v1607)

It installs/merges fine during NTLite build process.

However, during 1st boot, it causes an extreme delays, and eventually "rolls back" this KB.

(Confirmed that resulting installed OS image does not list it as successfully installed).

CBS.log included show errors below.

Moreover, after 1st/2nd boot (with the rollback delay), KB5004752 manually installs just fine on resulting image fine.

I'm suspect this is the result of process order/sequence problem.

For example, perhaps one of the other KBs I'm integrating at the same time is also
registering 1st boot stage, all at the same time has a dependency, or a post-install-boot
procedure that must clean up first, etc.

An earlier build in 2020, using KB4552926 (instead of KB5004752) worked perfectly fine with the exact same procedure.

I'm going to ask for an exception, and get approval to try/use the November 2021 DotNet CU (KB5007152) instead of August:

[ 2021-11 Cumulative Update for .NET Framework 4.8 for Windows Server 2016 for x64 (KB5007152) ]

--------

Current process:

# Stage 1
- Open Image
- Add DotNet3.5 ( from original ISO )
- Save & Close image

# Stage 2
- Open Image
- Add KBs:
-- SSU (KB5001402)
-- CU (KB5005043)
-- DotNet4.8 Feature Package (KB4486129)
-- DotNet4.8 Cumulative Update (KB5004752)
-- Add Misc KBs (Intel Microcode (KB4589210), Adobe Flash Removal (KB4577586), etc.)
- Other tweaks
- Close & Save image (ISO)

The resulting CBS log message is:
- CBS Failed to process single phase execution 0x800f081f CBS_E_SOURCE_MISSING
- Exec: not able to pre-stage package: Package_5_for_KB5004752*** clrjit.dll, mscordacwks.dll, etc.

-------
Thank for anyone's insights!

KB_Error_Svr2016_2.PNG
KB_Error_Svr2016_1.PNG
~BAS
 
My guess is 4.8 Feature Package requires a reboot to complete staging. The solution is to install KB5004752 using a RunOnce command, and exit SetupComplete with a forced reboot. Copy KB5004752 to a temp folder, since Setup folder will removed on script exit.

The last lines of SetupComplete will be:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /v PostTask /t REG_SZ /d "dism /Online /Add-Package /PackagePath:C:\tempfolder\KB5004752.cab" /f
shutdown -r -t 0 -f
 
Last edited:
garlin said:
My guess is 4.8 Feature Package requires a reboot to complete staging. The solution is to install KB5004752 using a RunOnce command, and exit SetupComplete with a forced reboot. Copy KB5004752 to a temp folder, since Setup folder will removed on script exit.

The last lines of SetupComplete will be:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /v PostTask /t REG_SZ /d "dism /Online /Add-Package /PackagePath:C:\tempfolder\KB5004752.cab" /f
shutdown -r -t 0 -f
Click to expand...
Thanks what I was thinking: That more than one KB was registering a RunOnce activity to complete, but that they were being registered out-of-sequence (out-of-order), and that, if the sequence/order could be correct, the dependencies would be fine.

Is there a way to ask ntlite host to dump the output of Guest's RunOnce registry entries during the build to a TXT on host (Debugging purposes) ?
 
Hi bseklecki_ge,

Tried now with the latest set of 1607 updates, all went fine.

Can you try these exact updates instead, they are directly from NTLite:
Load Image/edition
Updates
Add - Latest Online Updates

Screenshot attached of the result (only the 2021 updates from it).
Maybe I missed a step, potentially something else is triggering the issue.
If you still see the problem with these updates, please attach or send me directly that exact preset.
Also make sure the starting ISO is intact prior, best is to use one direct from Microsoft.
 

Attachments

  • Temp-2021-11-23-12-47-45_cr.png
    Temp-2021-11-23-12-47-45_cr.png
    18.9 KB
> best is to use one direct from Microsoft.

That's a good point; I've been using the Dell OEM image for various reasons (Bare Metal env Predominantly)

But for WinSrv2021, with HyperFlex/VXRail, I'll use the ISO from the VLSC stripped down for VMWare environments.

Thanks for your advice! ~BAS
 
Status note: Replacing KB5004752 (August) with KB5007152 (November) did not resolve the matter.

I think you're correct/right in your suggestions that I should revert to using Windows original ISOs from Microsoft (from MicrosoftOEM.com, etc..)
 
Also, I did find a way to mount the NTLite output WIM file (DISM) and then mount the Registry within that WIM ("reg mount...") and I can confirm that the KB/Windows Update framework is not registering any related "RunOnce" entries that may be causing the problem.

(NTLite itself puts a few things in there, but not Microsoft/WU)

The KB/WU system does register some tasks to run upon/after reboot, but it doesn't use the RunOnce framework, so I don't know where to look further for troubleshooting on that theory.
 
Integrating .NET 3.5, 4.8 (KB4486129) and 4.8 CU (KB5007152) updates in one pass worked for me. But I didn't bother with Windows CU since it was 1.6 GB (!)

This suggests if there's still a problem, it's not from the .NET features blocking each other.
 
Do you all use Microsoft OEM Media/ISOs from the VLSC or MS DOC?

I was able to get ahold of genuine Server 2016 DVD-DL ISO from Microsoft via the MS DOC (MicrosoftOEM.com).

Package: X21-73483 [ X21-73483 Win Svr Emb Std 2016 1607.2 EMB ENG OPK UpdateFMR SW DVD9 NTRL StdDC F.iso ]

I'll try to see if the problem manifests there as well.

Upon very cursory visual inspection, it doesn't seem to be a substantially different ISO from the one I made from Dell media. It is dated 2018 and contains the same base KBs:

Build/Rev: 10.0.14393
and:
KB4049065
KB4048953
 
I don't have OEM access, it was a matching ISO found by Google search. Since the .NET packages were relatively small, I only tested that instead of a full CU integration.
 
Bah! Same result using the MicrosoftOEM.com ISO.

I'm beginning to think that DotNet4.8 Feature Pack (KB4486129) was never meant/intended to be integrated into the image using ADK/NTLite?
(And that it should always be done post-OS-Install)

And perhaps this is simply my amature mistake in strategy.


The problem with that theory, however simplifying:

- This exact processed previously worked with older KBs in SVR2016/v1607
- That exact process still works just fine on Win10_Ent/IOT_LTSC_2019

----------------------------------------

Current Process:

# Pass 1:
- Open Image
- Remove/Trim unnecessary editions (datacenter, etc.)
- Save & Close image

# Pass 2:
- Open Image
- Add DotNet3.5 ( from NTLite Preset)
- Save & Close image

# Pass 3:
- Open Image
- Add/Integrate Update KBs:
-- SSU (kb5005698)
-- CU (kb5008207)
-- DotNet4.8 Feature Package (KB4486129)
-- DotNet4.8 Cumulative Update (kb5007152)
-- Add Misc KBs (Intel Microcode (KB4589210), Adobe Flash Removal (KB4577586), etc.)
- Other NTLite tweaks && Unattended mode
- Close & Save image (Build ISO)
 
I have finally figured this out.

I have it working again; I can now successfully integrate latest DotNet4.8 CU (either KB5007152 or KB5004752).

I changed my/the sequence-process as-follows in the following way:

*) Add DotNet4.8 Feature Package (KB4486129) during Pass #2 (At the same time I'm adding DotNet3.5)
*) Add DotNet4.8 Feature Package (KB4486129) during Pass #2 .B (a 3rd Phase, separately, with an image load/close operation)

In either case, DotNet4.8 CU (either KB5007152 or KB5004752) will successfully integrate.

I'm not sure why/what this change-of-sequence affects internally ( WRT 1st boot activities and dependencies ) ?

That has to be a bug (Microsoft or NTLite) with the sequence/order of how KBs are processed, either on 1st boot, or during NTLite customization process.

I never understood why DotNet3.5, an "optional feature", was distributed as a .CAB, but DotNet4.8/KB4486129 (which is classified in the Microsoft Update Catalog as a "feature pack") is distributed as a .MSU, but somehow both of them are considered by NTLite as "Updates" ? >:}

(Both processed by DISM I assume)

Thanks,
~BAS
 
MSU is a group of bundled CAB files. Each CAB file exists for one specific feature.

KB4486129 MSU includes the actual CAB, and a copy of WSUSSCAN for version control (in case your system is offline).
Some installed updates are reported as "feature packs" in Windows.

Basically if you do everything .NET in one pass, it works? Which is what I confirmed before. I don't think it's a "bug".

Installing 3.5 & 4.8 doesn't require a reboot, but the CU normally does (because it's expecting to replace installed libraries). When you install 3.5, 4.8 and CU in one pass -- none of the libraries are in-use, so there are no conflicts to resolve.
 
> Basically if you do everything .NET in one pass, it works?

It works If: I add DotNet3.5 CAB and DotNet4.8 MSU in one pass, save, then close; then Add SSU, CU, and DotNet4.8 CU in a second pass,
It fails if: I add all 5 at the same time/pass

Just for the record. And thanks again.
 
You must log in or register to reply here.
Back
Top