Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Newsgroups: alt.comp.os.windows-10 Subject: Re: "Status: Download error - 0x80070643" with "2024-01 Security Update for Windows 10 Version 22H2 for x64-based Systems (KB5034441)" in 64-bit W10 Pro. Date: Sun, 14 Jan 2024 05:45:15 -0500 Organization: A noiseless patient Spider Lines: 136 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 14 Jan 2024 10:45:16 -0000 (UTC) Injection-Info: dont-email.me; posting-host="242c4de200261b80afca86a9a13ba66f"; logging-data="441988"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+oTI49y/RC5r67bNF5qNYCdWs0dlnHdL8=" User-Agent: Ratcatcher/2.0.0.25 (Windows/20130802) Cancel-Lock: sha1:yB6myMsBnOXvISC6i3QouUJ2ZKc= Content-Language: en-US In-Reply-To: Bytes: 8951 On 1/13/2024 6:25 PM, sticks wrote: > On 1/13/2024 4:17 PM, Big Al wrote: > >> I deleted all of them then went back and ran those manual commands and I was able now to expand the partition by that 250M. >> The rest of the commands succeeded and then I ran Windows Update and it succeeded also. >> >> So I'm happy that my system has a larger Recovery now.  I probably should have shoved it 500M, but... It's at 881M now. > > I have to admit, I'm thoroughly confused now. > I have a bunch of messages in this thread saved, but is there any chance you could post > the message ID of the one that had the instructions you followed to get yours working?  > It would be much appreciated! We have not reduced the answer to this question to a "recipe". You could have Bitlocker encryption on the disk drive. While Bitlocker is not "supported" on Home, and is supported on Pro, the manage-bde utility may be present anyway, to give some information. Some people to this day, are blissfully unaware their disk is encrypted. Surprise! manage-bde -status Early in the thread, we were treated to the support.microsoft.com article. I tried to provide a picture of my disk drive, and show the commands I would use to fix my specific case. I generally do not use crypto, if I can possibly avoid it. (Only my VMWare virtual machine with the Win11 in it, is encrypted, as VMWare did not offer any options in the matter. Users even told VMWare how to do this. Crickets.) A typical user might have a UEFI installation on a modern computer, with a GPT partitioned disk. The worked example assumes these characteristics. I had to "avoid" using my legacy MBR Win10 installation, as it would mislead people a bit. More people could be here on OEM setups, in which case the possible disk layouts, crypto situations, just explodes. Thus, this example is a very narrow and "best-guess" at what you might find. OEM systems will be GPT. A lot of users in the group, might well have selected GPT for the flexibility it offers. A couple posters have already recommended waiting until Microsoft fixes this. If you're a multi-booter with *lots* of experience, I think you can handle this, but then, you'd be finished by now. The standard advice (which I use religiously when standing on a shaky platform), is to do a full disk backup before attempting anything like this. https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf # Administrator Command Prompt, or Admin Powershell then type "cmd.exe" as a command reagentc /info # shows recovery agent is enabled, and is using Partition 4 # The article should show what that looks like. A picture would help. # If your reagentc is blank or messed up, *stop now*. See example further down, # for what one looks like. [Picture] This picture shows my disk setup, and makes a reference to the invisible non-partition known as MSR (reserved/junk area) Partition 2 can be seen from Linux gparted /dev/sda , if you really want to see the disk layout. The disktype.exe utility also shows it, but it's only available via a Cygwin installation. I do not really want to lard up this answer with a lot more utility photos. I guess even List Partition shows it, come to think of it. https://i.postimg.cc/sgXwB389/diskpart-disk-summary.gif reagentc /disable # Disable recovery environment agent before making changes diskpart.exe # Now, we're doing shrink of C: and regeneration (empty) Recovery partition 4 list disk select disk 0 list partition select partition 3 # will shrink C: now. This could fail, if the $USN journal is right at the end of C: . shrink desired=250 minimum=250 # runtime 1 second (*normally* the end of the disk doesn't have a blocker up there) select partition 4 delete partition override # "delete partition" is the command we seek to cowboy at this point # This solves the inability to change the origin of a partition in DiskMgmt. Deleting Partition 4 create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac # The ID is a partition type, it's our Recovery partition. gpt attributes =0x8000000000000001 # <=== Protected status of partition. Partitions # can be "marked" as "being special" [Attribute] # Yes, there are fourteen zeros in that constant. format quick fs=ntfs label="Windows RE tools" # Partition 4 is NTFS, and now it has no content. Empty file system. # Partition is likely hidden by its ID value. The Windows Update will fill it up. exit reagentc /enable # Even though Partition 4 is empty, we can still pretend all is well. reagentc /info # A sample output is provided, after this line. Windows Recovery Environment (Windows RE) and system reset configuration Information: Windows RE status: Enabled Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE <=== partition pointer remains as before Boot Configuration Data (BCD) identifier: 964e2ef1-3a60-11ed-81d3-5cf3707d2fda <=== likely inside ESP Partition 1 Recovery image location: Recovery image index: 0 Custom image location: Custom image index: 0 Anyway, that was enough operations for me to fix mine. YMMV, OK? .... Time passes. Somehow, we encourage '4441 to install. We think a new WinRE.wim was installed. How to prove it ? To prove '4441 has installed my new WinRE, I used TestDisk version 7. Using this is actually too complicated to explain. Which speaks well of the interface. Not a problem. We have an alternative. [Picture] https://i.postimg.cc/HnkmKP8X/4441-installed-OK-dates-filesize.gif The alternative, is more Diskpart. Administrator window of some sort, or otherwise, diskpart will elevate itself. diskpart.exe list disk select disk 0 list partition select partition 4 # We're pointed to the 0x27 style hidden Recovery partition now. assign letter=K # Temporarily assigning a drive letter, to make partition visibie. # Permissions can *still* prevent us from doing stuff. File Manager # pointing to K: , is not very helpful right now. exit In the same administrator window, to prove '4441 is present, now we have access to the partition via the letter K. (The letter K will be removed on a reboot. If you want it per-session, you have to do the procedure per-session.) You should see three files with Jan 2024 datestamps or so. The slash a h is asking to display all files with a Hidden attribute set. dir /ah K:\Recovery\WindowsRE So that's about it... for me. Paul