Cannot install January patches in a healthy W10 22H2

Until yesterday I had the Win10 22H2 updates paused since January's patch day, hoping MS does a better version of KB5034441, with auto-resizing of partitions (as of now, the user should shrink the main Windows partition and enlarge the Recovery one manually, for which MS has provided directions with diskpart https://support.microsoft.com/en-us/...9-24c8229763bf ).

Whatever, I re-enabled automatic updates and failed to install all, the KB5034441 that is a "security update" (SecUp), the monthly cummulative update (CumUp) and the .NET update (DnetUp). I did multiple retries and proofs during several hours but this is a good summary (all my attempts were with some label in the recovery partition, although originally it had no label, can this matter?).

I ended up restoring a previous Macrium Reflect image done with updates paused (no issues at all here), so I have the January Win10 patches pending. I've just now run

Dism /Online /Cleanup-Image /ScanHealth
Dism /Online /Cleanup-Image /CheckHealth

that don't have found any problem. I haven't run Dism /RestoreHealth nor SFC /scannow yet (redundant after this?).

==========================================================

I'll be detailed with the partition alignments and sizes as they're one of my suspects. I suspect that Win10 partition alignment and sizes have rules that I might have infringed, and maybe someone knows for sure

This system has an MBR drive (SATA SSD) only for Windows, with System Reserved (hidden), Main Windows (C:) and Recovery (hidden) partitions in this order. This was done by Windows at install time (from a DVD recorded from the ISO file purchased at Microsoft's site, if it matters, I'm a domestic user), and I haven't touched it until now. I also have an MBR SATA HDD for data, with 2 partitions in it, irrelevant for this problem.

System Reserved has the usual 1 MB offset and 50 MB size. Main Windows has no offset (it's originally so) and 223 GB total, 57 GB used. Its end isn't aligned to MB as it takes exactly 584 sectors (292 kB) more from its last MB-aligned barrier. The Recovery partition has 732 kB (732+292=1024kB=1MB) or 1464 sectors (1464+584=2048) offset, 522 MB total and 434 MB used. All partitions have MB-aligned starts and ends except Main Windows end as said. There's a whopping chunk of 5296 unallocated sectors at the end (2MB + 600kB, the disk has a whole number of MB plus those 600kB or 1200 sectors).

==========================================================

My first attempt was as if nothing was happening with KB5034441, that failed with error code 0x80070643 ( ERROR_INSTALL_FAILURE ). CumUp and DnetUp did also fail with 0x80070002 (ERROR_FILE_NOT_FOUND), which at first I judged it could be for the former failure. During the failed install the Windows Update blue screen reported about undoing changes, and Windows Update itself in Windows said that an attempt had failed with error code 0x80070002 and showed a Retry button, that launches the whole updating proess again.

So I applied the MS directions for this problem (enlarge the Recovery partition with space taken from the Main Windows one with WinRE disabled/enabled with ReAgentC), although with 1500 MB more instead of the suggested 250 (can this matter?), so Recovery ended up with 1.98GB size (unusually large but intending future-proof and I've plenty of space anyway). Diskpart conserved the previous 732kB (1464 sectors) between Main Windows and Recovery partitions, although it also took 1 of the 2 final unallocated MB for the latter partition and the disk ended up with 1MB + 600kB unallocated at the end (instead of 2MB + 600KB). This attempt failed nearly equal as the first one, except that Windows Update after reboot reported a 0x80070643 error instead of a 0x80070002 one.

In each attempt, KB5034441 was always the first update tried and I could click on a retry item while the other two patches were installing. These weren't failing in this phase before rebooting. I did several attempts more varying the click on this KB5034441 retry, Recovery partition's label and other nuisances that never varied the basic result. I also tried with other Recovery partition offsets and final unallocated spaces (done with Partition Wizard), and with the ReAgent.xml and Winre.wim files extracted from my Win10 installing media instead of my system ones (the Winre.wim one has the same contents and date anyway, except the DVD's one time is 1 minute older, 14:30 vs 14:31).

In my final attempt I used wushowhide.diagcab (a known Windows Updates hider) to hide KB5034441 and attempt to install CumUp and DnetUp only. Fail too, so I restored the Macrium Reflect image backup and I'm now as if these attempts had never been made.

==========================================================

Dism /ScanHealth and Dism /CheckHealth (in this order) don't find any problem in my Windows install. What next?

@JLArranz
here you find all you need to solve the problem.
KB5034441 Security Update for Windows 10 (21H2 and 22H2) - Jan. 9
It is really very easy.

I have now only shrunk the main Windows partition 1500 MB by the right and extended the Recovery partition that size to the left, using MiniTool Partition Wizard Free elevated, although I didn't disable WinRE as I knew PW had to reboot as it effectively did. Now the main Windows partition has its right end aligned to MB (I set it so deleting the ".28" part of the size), and the Recovery partition doesn't have the usual 1MB offset, its offset is "0" (its first sector is disk's following one to previous partition's last sector, you get this result -intended by me- in PW doing "Extend" instead of "Move/Resize partition"; btw my data disk partitions have offset "0" too, and the drive's only unallocated space is 1456 sectors -728kB- at the end). As I haven't worked in other parts of the disk, the first "System Reserved" partition is keeping its typical and previous 1MB offset, the main Windows partition is keeping its previous "0" offset, and there're the same 5296 unallocated sectors (2MB + 600kB) at the Disk's end as before the change. Windows Updates are still paused and Windows RE is okay and enabled:

--------------------------------------------------------------------------------------------------
Microsoft Windows [Versión 10.0.19045.3803]
(c) Microsoft Corporation. Todos los derechos reservados.

C:\Windows\system32>reagentc /info
Información de configuración del Entorno de recuperación de Windows (Windows
RE) y restablecimiento del sistema:

Estado de Windows RE: Enabled
Ubicación de Windows RE: \\?\GLOBALROOT\device\harddisk0\partition3\Recovery\WindowsRE
Identificador de datos de la configuración de arranque (BCD): 4a2c3e6b-c284-11ec-a1a6-c9ebfc612e9b
Ubicación de imagen para recuperación:
Índice de imagen para recuperación: 0
Ubicación de imagen personalizada:
Índice de imagen personalizada: 0

REAGENTC.EXE: operación efectuada correctamente.


C:\Windows\system32>
--------------------------------------------------------------------------------------------------

There's a discrepancy between PW and Windows Disk Management though. The latter does see neither file system nor used space in the new Recovery partition, besides placing it in 1st place instead of 3rd place in the upper list, although it's correcty placed in the lower diagram. What does exactly mean a shadowed partition in this diagram, as my current Recovery partition is? On the contrary PW doesn't see anything abnormal:



Windows Update wouldn't use PW so it might not be able to use what Disk Management sees, a partition without filesystem nor contents. Do I have to do anything here before attempting Windows Updates?

(Idk if I've put the images as they should be, as I've uploaded them as "attachments", that was before "Insert image" in left to right order, and I haven't been able to delete the attachments and upload them as images of this post, that is more adequate; this post might be edited although I don't have clear its exact behaviour and interface yet)

@JLArranz
Just run Win Update

What does exacty mean that a partition (any partition) rectangle is depicted with that "shadowed" background (done with those thin inclined lines if you can see them) that my Recovery partition has, instead of a plain and white background? I'm asking for the meaning that Windows Partition Management gives to this depicting, if anyone knows it.

Unfortunately I don't have an alternative word to "shadowed", that in the context of disks doesn't mean any purely graphical thing, but things like "shadow disk", "shadow partition", "mirror volume",... Google and Bing understand this and not the graphical matter.

I'm asking this because I've seen (not in my computer nor in any physical computer that I own or have access to, I mean screens posted by users in Internet) several Partition Management screens with one or more ancient and not usable Recovery Partitions depicted like this, and the authentic one depicted normal (I've read that Windows automatic extendings do this, instead of extending the ancient partition from say 300MB to 500MB, they create a new 500MB partition, leave the ancient 300MB one in "semi-zombie state", and call it a day; btw the diskpart solution by MS doesn't extend the Recovery partition either, it deletes it -delete partition override-, creates a new one -create partition primary id=27 /*for MBR*/- and formats it -format quick fs=ntfs-; the latter btw changes id from 27 to 07 but it's easily fixed -set id=27-; I've already failed with these directions anyway). So userA has 1 authentic and 3 ancient, userB has 1 authentic and 0 ancient (as myself before this), userC has 1 authentic and 1 ancient,... and I now have 0 authentic and 1 depicted as a shadowed rectangle. I suppose I've a problem, but to diagnose it I must translate "depicted as a shadowed rectangle" to the disk and partitions language.

The screen doesn't say that the Recovery partition is RAW, it just doesn't say any filesystem or that it doesn't understand its filesystem. It shows a mix of things:

Up: ("Estado" = Status)
It says it's Correct in two places. ("Correcto")
It says it's Recovery partition in two places. ("Partición de recuperación")

Down:
It says that it has 1.98GB capacity ("Capacidad") and 1.98GB free space ("Espacio disponible").
It depicts the partition rectangle "shadowed" unlike the other partitions, both in my disk and valid Recovery partitions elsewhere, but Idk what does this depicting mean.

PW doesn't see any problem, it can identify the filesystem as NTFS and explore the files correctly. Diskpart's List vol says "Volume 4 [no letter] [no label] Fs=NTFS Type=Partition Size=2023MB Status=Correct Info=Hidden".

These inconsistent mixes use to mean bugs or failures, maybe the one pointed out by @itsme1 . But please what is the meaning of a shadowed (with thin inclined lines) partition rectangle in Windows Partition Management?

Selection lol! And I was thinking about some deep stuff... Trying now.

- - - Updated - - -

Fail with KB5034441, although I have 90%-succeeded with KB5034275 (.NET) and 95%-succeeded with KB5034122 (normal cumulative). Given the problems I had had before, I had downloaded these from the Catalog before starting this thread, but I hadn't installed them yet because I was also seeking info for them.

The .NET one is divided in KB5033909 (up to 4.8) and KB5033918 (up to 4.8.1 and currently latter afaik). I'm not 100% sure about having installed 4.8.1 before but I downloaded both anyway. I installed the three *.msu's one by one and rebooting in between (3 times total) in this order: KB5033909, KB5033918, KB5034122. After un-pausing my WU to attempt KB5034441, Windows installed KB5034582 (.NET preview) sucessfully, what I wasn't intending, I hope it doesn't send anything to the 17th dimension . The normal cumulative's only side effect has been to be listed with the somewhat dull name "Security update for Windows (KB5034122)" instead of its regular name "2024-01 Cumulative update for Windows 10 Verion 22H2 for 64 systems (KB5034122)" (similarly the two KBs equivalent to KB5034275, although the preview .NET is 100% okay in this list).

I've failed three times with KB5034441, once at first when also installing both KB890830 and KB5034582 (succeeded both), and twice with the Retry ("Reintentar") button provided by WU. "Error de descarga 0x80070643" means "Download error 0x80070643".



The Windows disk is nearly exactly as shown/explained above: same partitions with same sizes, same offsets, same contents of the Recovery partition,... the only difference is that Recovery partition\System Volume Information\klsdkmeta.dat has now a more modern date/time (that has not varied in my last attempt, although it could be the one of my 1st or 2nd ones).

Is there anything next?

- - - Updated - - -

I was trying to do a new post, but anyway...

- - - Updated - - -

I've done another attempt. There was quite a bit of disk activity, processor temperature rising (as it uses to happen here with WU), fans activity,... during several minutes, but fail too. Is there a log of this, keys of Event Viewer, files that I could open with Notepad, registry keys, *.ini files, something I could review or setup? Is 2GB enough for a recovery partition? I could set it to 50 or 100 GB, even more. Would that help? Why or why not?