This was the laptop that was taking so long to boot up (~20 minutes).
I'll do another thread on why it was taking so long to boot up.
<https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>
<https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>
Laptop came with Windows 8 from Asus, which is what I believe created
the 20.01 GB "Restore" partition.
It has been a while, but I believe I created partition 6 (D:) because
they were not paying attention to where they were placing their working files, and for some stupid reason I thought this would get them in the
habit of knowing where their files were located. As it only had 150 MB
in it, obviously that didn't work.
About 1.5 years back, I updated this laptop to Windows 10. The Drive2
link above shows partition 5 also as a "Recovery" partition. Both
partitions 2 and 5 seem to have enough space to be able to do the
ReAgent KB5034441 update, though one is before the C drive and one is
between the C and D drives. But it would not install the update and fails.
My question is how did partition 5 get in there in-between the two
drives? I'm wondering why diskpart claims it is a recovery partition,
though it also calls partition 7 a recovery partition when disk
management calls it a "Restore" partition. What the heck is partition 5?
This was the laptop that was taking so long to boot up (~20 minutes). I'll do another thread on why it was taking so long to boot up.located. As it only had 150 MB in it, obviously that didn't work.
<https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>
<https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>
Laptop came with Windows 8 from Asus, which is what I believe created the 20.01 GB "Restore" partition.
It has been a while, but I believe I created partition 6 (D:) because they were not paying attention to where they were placing their working files, and for some stupid reason I thought this would get them in the habit of knowing where their files were
About 1.5 years back, I updated this laptop to Windows 10. The Drive2 link above shows partition 5 also as a "Recovery" partition. Both partitions 2 and 5 seem to have enough space to be able to do the ReAgent KB5034441 update, though one is beforethe C drive and one is between the C and D drives. But it would not install the update and fails.
My question is how did partition 5 get in there in-between the two drives? I'm wondering why diskpart claims it is a recovery partition, though it also calls partition 7 a recovery partition when disk management calls it a "Restore" partition. Whatthe heck is partition 5?
On 2/6/2024 11:41 AM, sticks wrote:were located. As it only had 150 MB in it, obviously that didn't work.
This was the laptop that was taking so long to boot up (~20 minutes). I'll do another thread on why it was taking so long to boot up.
<https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>
<https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>
Laptop came with Windows 8 from Asus, which is what I believe created the 20.01 GB "Restore" partition.
It has been a while, but I believe I created partition 6 (D:) because they were not paying attention to where they were placing their working files, and for some stupid reason I thought this would get them in the habit of knowing where their files
before the C drive and one is between the C and D drives. But it would not install the update and fails.
About 1.5 years back, I updated this laptop to Windows 10. The Drive2 link above shows partition 5 also as a "Recovery" partition. Both partitions 2 and 5 seem to have enough space to be able to do the ReAgent KB5034441 update, though one is
What the heck is partition 5?
My question is how did partition 5 get in there in-between the two drives? I'm wondering why diskpart claims it is a recovery partition, though it also calls partition 7 a recovery partition when disk management calls it a "Restore" partition.
1 2 3 4 5 6 7 -------------------------+---------+-----+---------+---------+-----+---------------------------+
ESP System Partition |System |MSR |C: |System |D: |Restore (Could be W7) |
(Microsoft folder, BCD) |Reserved |NoFS |Partition|Reserved |Data |12GB |
|WinRE.wim|128MB| |WinRE.wim| |Traditional OS restoration |
-------------------------+---------+-----+---------+---------+-----+---------------------------+
reagentc /info # in an Administrator window
The partition number in reagentc /info, should point to the one
on the right of the C: partition. "Partition 5" is the real one.
"Partition 2" is no longer in usage. Partition 5 was caused by
an OS Upgrade. Partition 2 was invented, before they knew what
they were doing.
Any time that metadata uses partition numbers, it is not a
good idea to be deleting partitions "to the left" of the
affected partition. At least, unless you know how
to repair the damage. 5 is using partition number for reference,
so do not delete 2 (unless you are ready to do reagentc repair procedure).
If you, in diskpart.exe, "assign letter=K" to a partition,
that allows hidden partitions to be listed. The alternative,
is to use TestDisk, but that is an acquired taste as a tool.
Note that assigning a letter in this way, is not honored by
all the software. It has limited scope.
diskpart
list disks
select disk 0
list partitions
select partition 5
assign letter=K
exit
K:
dir
cd directoryname
dir
... # Descend and look around.
[Reboot, to clear the K: assignment and be shed of it.]
sticks wrote on 2/6/24 9:41 AM:
This was the laptop that was taking so long to boot up (~20 minutes).
I'll do another thread on why it was taking so long to boot up.
<https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>
<https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>
Laptop came with Windows 8 from Asus, which is what I believe created
the 20.01 GB "Restore" partition.
It has been a while, but I believe I created partition 6 (D:) because
they were not paying attention to where they were placing their
working files, and for some stupid reason I thought this would get
them in the habit of knowing where their files were located. As it
only had 150 MB in it, obviously that didn't work.
About 1.5 years back, I updated this laptop to Windows 10. The Drive2
link above shows partition 5 also as a "Recovery" partition. Both
partitions 2 and 5 seem to have enough space to be able to do the
ReAgent KB5034441 update, though one is before the C drive and one is
between the C and D drives. But it would not install the update and
fails.
My question is how did partition 5 get in there in-between the two
drives? I'm wondering why diskpart claims it is a recovery partition,
though it also calls partition 7 a recovery partition when disk
management calls it a "Restore" partition. What the heck is partition 5? >>
If this is the same laptop mentioned in the 'Revert to Windows 8' post/thread...please try to avoiding creating another thread for the
same device and most likely the future direction(your intent) for the
same device. i.e. don't start another thread about this device, use
**this exact same thread'.
Partition 5
- Windows 10 created Recovery partition(i.e. created when it was
upgraded to Win10 or later in the correct location(after the Windows partition and by shrinking the Windows partition to make space and place
the partition after the Windows partition)
Partition 7
I'm going to try and see if I am missing something like this in my
thinking since it still won't update 4441 even though it is enabled
and is positioned after C now like this
<https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>
Fyi...WinRE partition being enabled doesn't necessarily guarantee KB 5034441(and its SafeOS update KB5034232) will be installed.
The status of the o/s version, build and the version/build of the SSU(Servicing Stack Update) is also a controlling factor.
What is the current installed version and build of Windows 10?
The partition order shown in your pic is the correct order.
- post re-partitioning, did you re-run reagentc /info to determine the recovery partition status(partition number and enabled)?
On 2/6/2024 5:04 PM, Paul wrote:were located. As it only had 150 MB in it, obviously that didn't work.
On 2/6/2024 11:41 AM, sticks wrote:
This was the laptop that was taking so long to boot up (~20 minutes). I'll do another thread on why it was taking so long to boot up.
<https://www.dropbox.com/scl/fi/uiiez3086ili1myaucp55/Drive.jpg?rlkey=ji0soyglau9x9ija9xrwv00m3&dl=0>
<https://www.dropbox.com/scl/fi/bxs3kc56chc4ixc1hhsn6/Drive2.jpg?rlkey=w5nd00f4d7olya6y6v0cqeviv&dl=0>
Laptop came with Windows 8 from Asus, which is what I believe created the 20.01 GB "Restore" partition.
It has been a while, but I believe I created partition 6 (D:) because they were not paying attention to where they were placing their working files, and for some stupid reason I thought this would get them in the habit of knowing where their files
before the C drive and one is between the C and D drives. But it would not install the update and fails.
About 1.5 years back, I updated this laptop to Windows 10. The Drive2 link above shows partition 5 also as a "Recovery" partition. Both partitions 2 and 5 seem to have enough space to be able to do the ReAgent KB5034441 update, though one is
What the heck is partition 5?
My question is how did partition 5 get in there in-between the two drives? I'm wondering why diskpart claims it is a recovery partition, though it also calls partition 7 a recovery partition when disk management calls it a "Restore" partition.
all there and enabled. Looked like this when done.
1 2 3 4 5 6 7
-------------------------+---------+-----+---------+---------+-----+---------------------------+
ESP System Partition |System |MSR |C: |System |D: |Restore (Could be W7) |
(Microsoft folder, BCD) |Reserved |NoFS |Partition|Reserved |Data |12GB |
|WinRE.wim|128MB| |WinRE.wim| |Traditional OS restoration |
-------------------------+---------+-----+---------+---------+-----+---------------------------+
reagentc /info # in an Administrator window
The partition number in reagentc /info, should point to the one
on the right of the C: partition. "Partition 5" is the real one.
"Partition 2" is no longer in usage. Partition 5 was caused by
an OS Upgrade. Partition 2 was invented, before they knew what
they were doing.
Yes, partition 5 was where reagentc /info pointed.
Any time that metadata uses partition numbers, it is not a
good idea to be deleting partitions "to the left" of the
affected partition. At least, unless you know how
to repair the damage. 5 is using partition number for reference,
so do not delete 2 (unless you are ready to do reagentc repair procedure).
I have done this repair procedure many times now, so I ultimately decided to delete the partitions 2, 5 and 7. I then made partition 4 big, and shrunk it by 1500 MB and created the WinRE partition in the right spot and reagentc /info showed it was
<https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>care if it gets updated if the recovery environment still works. I also know I can just reimage if it gets screwed up. It will just try and fail every time it does updates.
I haven't actually tried yet to see on this system if the recovery agent actually works. I probably should do that since I still cannot get this to do the 4441 update for some reason. There is no BitLocker in use on this machine, so I really don't
Is there a way to tell MS Update not to try this one again?
---snip---
If you, in diskpart.exe, "assign letter=K" to a partition,
that allows hidden partitions to be listed. The alternative,
is to use TestDisk, but that is an acquired taste as a tool.
Note that assigning a letter in this way, is not honored by
all the software. It has limited scope.
diskpart
list disks
select disk 0
list partitions
select partition 5
assign letter=K
exit
K:
dir
cd directoryname
dir
... # Descend and look around.
[Reboot, to clear the K: assignment and be shed of it.]
I think you're saying that if I do above and assign partition 2 a letter it will show up here too?
<https://www.dropbox.com/scl/fi/yb44qp98u0keqooocu36q/Drive4.jpg?rlkey=olvo7fzvxwvbyjf5l4arakvc0&dl=0>
---snip---
As usual, very interesting stuff for me. Thanks!
On 2/7/2024 11:06 AM, sticks wrote:
If you assign drive letter K to a partition,
it does not show in Disk Management. It might not
be accounted for in MountVol. It would only show in
Disk Management if the partition was a regular NTFS one.
But at least in a terminal, you should be able
to do
K:
dir
cd directoryname
dir
and look around a bit if you want.
If the hidden partition is unformatted, then it's not going
to mount this way. Only if there is a file system inside the
hidden item, does this work. And there could still be
permission issues.
Since FAT32 doesn't have that sort of permission issue,
you should be able to skate around in an ESP for a look.
Paul
sticks wrote on 2/7/24 1:58 PM:
On 2/7/2024 11:57 AM, ...w¡ñ§±¤ñ wrote:
I'm going to try and see if I am missing something like this in my
thinking since it still won't update 4441 even though it is enabled
and is positioned after C now like this
<https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>
Fyi...WinRE partition being enabled doesn't necessarily guarantee KB
5034441(and its SafeOS update KB5034232) will be installed.
Meaning it won't try, or it can still fail? Because it definitely
keeps trying to install it.
An update can't fail, if not attempted.
When an update is attempted, two possible outcomes - success of failure.
- the latter does not exempt future attempts.
i.e. an indication that if offered(and based on the device's condition),
it should be installed)
The status of the o/s version, build and the version/build of the
SSU(Servicing Stack Update) is also a controlling factor.
What is the current installed version and build of Windows 10?
Windows 10 Home Edition
Version 22H2
Build 19045.3996
I tried finding the installed servicing stack build, but that doesn't
seem so simple. Is there a specific KB for this build I should check
to see if it is installed?
Version/Build(22H2 19045.3996) indicates the Jan. 23, 2024 KB5034203
Preview update was installed which also installs its included SSU
19045.3989
For what purpose ?...'getting in there' won't provide any information
The partition order shown in your pic is the correct order.
- post re-partitioning, did you re-run reagentc /info to determine
the recovery partition status(partition number and enabled)?
Yes, it is enabled. I am going to try /boottore and see if I can get
in there.
on success or failure of 5034441(and its included SafeOS update KB5034232)
On 2/7/2024 5:16 PM, ...w¡ñ§±¤ñ wrote:not have BitLocker, is it still being offered because though it doesn't have BitLocker, there is another option to encrypt data?
sticks wrote on 2/7/24 1:58 PM:
On 2/7/2024 11:57 AM, ...w¡ñ§±¤ñ wrote:
I'm going to try and see if I am missing something like this in my thinking since it still won't update 4441 even though it is enabled and is positioned after C now like this
<https://www.dropbox.com/scl/fi/5njsciy0k0w7cyxml1x9m/Drive3.jpg?rlkey=xy5ph92r59cdezpn628jwoc7z&dl=0>
Fyi...WinRE partition being enabled doesn't necessarily guarantee KB 5034441(and its SafeOS update KB5034232) will be installed.
Meaning it won't try, or it can still fail? Because it definitely keeps trying to install it.
An update can't fail, if not attempted.
When an update is attempted, two possible outcomes - success of failure.
- the latter does not exempt future attempts.
i.e. an indication that if offered(and based on the device's condition), it should be installed)
I thought you perhaps meant it might not be offered and install attempted. For example, from what I've read 4441 is supposed to add something associated with it's ability to navigate BitLocker encrypted systems. Since Windows 10 Home edition does
reagentc /boottore and yes it did allow me to go in and look around. It all seems to be there. Only problem I had was on a couple of the actual recovery option tiles, once clicked I was told I needed an administrator account to sign in to do anything.The status of the o/s version, build and the version/build of the SSU(Servicing Stack Update) is also a controlling factor.
What is the current installed version and build of Windows 10?
Windows 10 Home Edition
Version 22H2
Build 19045.3996
I tried finding the installed servicing stack build, but that doesn't seem so simple. Is there a specific KB for this build I should check to see if it is installed?
Version/Build(22H2 19045.3996) indicates the Jan. 23, 2024 KB5034203 Preview update was installed which also installs its included SSU 19045.3989
For what purpose ?...'getting in there' won't provide any information on success or failure of 5034441(and its included SafeOS update KB5034232)
The partition order shown in your pic is the correct order.
- post re-partitioning, did you re-run reagentc /info to determine the recovery partition status(partition number and enabled)?
Yes, it is enabled. I am going to try /boottore and see if I can get in there.
I wanted to check for two reasons.
First, simply because I enjoy the learning chances people like you, Paul, Vanguard, Andy, Charles and so many others are gracious enough in providing. I always find it fascinating.
Second, because since this 4441 update provides Bitlocker functionality in some way, and this computer doesn't use either encryption or Bitlocker, I wanted to know if it still could be accessed to use the recovery tools if needed. I checked using
sticks wrote on 2/7/24 6:42 PM:
If you are using Macrium Reflect or similar for making an image of the Windows 10 GPT partitions, one could just explore the Recovery partition
and look at the date of the Winre.wim file...the rest of the files(version/build) found in that partition won't provide more or
additional significant information relative to reasons for '4441/4232' failing to install.
..but one can look at a few(two) files in Windows\System32 that get
changed when the Recovery partition is updated.
winload.exe version/build and date
winload.efi version/build and date
Then compare those with what you found for Service Pack Build in the
earlier noted DISM /Get-ImageInfo command
Normally the build number of these 2 files will be identical to the
installed Windows version(seen in winver) and will be greater than or
equal to the Service Pack build reported in /Get-ImageInfo
Note: My Surface 3 running Win10 Pro(Home in this case would not be different, its all Win10)after updating with 4441 shows
- the two winload files as 10.0.19041.3996
- Get-ImageInfo shows the Service Pack Build as 3920
Sidenote:
To get that Surface 3 to update(failed 4 times on '4441'). I took a different route(b/c I knew that System Restore points located at the end
of the C:\Windows partition can prevent resizing(shrinking) the Windows partition inevitably causine '4441' failing.
So..
- I deleted all System Restore Points
- Disabled System Restore for the C: drive(it was not enabled for other drives either)
- Used Windows Disk Cleanup in admin mode to remove everything it showed
as removable(i.e. - all boxes were checked before running) - took about
15 min on that 8 yr old device(Intel Atom chip and 4 GB RAM, 128 GB disk storage), and WinRE partition had sufficient free space to handle the Recovery partition updating).
- Turned off Windows Update option 'Receive updates from other Microsoft products
- Installed the Jan 9 2024 KB5034275(.NET Cumulative) and KB 5034122 update
- Installed the Jan 23 KB5034203 Cumulative Preview successfully - 19045.3996,
...then successfully installed KB 5034441 (WinRE update which also
applies SafeOS Security update KB5034232), which also updated the
Recovery Partition. Verified by the earlier info(the two winload files version/build and Get-ImageInfo Service Pack Build.
Other Win10 devices with succesful Recovery Partition update and 4441
update may show different version/buile numbers and/or Service Pack
Build of the Winre.wim file..but still representative or a successful
install of the KB and updating the Recovery partition(resized or not
with a larger usage of total Recovery partition size.
Automatically booting on startup to the Recovery Environment would function(as long as the partition and files are not damaged) with or
without installation of KB 034441(and its SafeOS update KB5034232)
There is a Powershell command that can be used to determine the Service
Pack Build #, and last modified date of the Recovery partition's
winre.wim file
DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\winre.wim /index:1
Note: the above is an example...variables that may need to be changed if different for your system are
harddisk1
parition4
/index:1
When you run reagentc /info the first two terms are shown in the Windows
RE Location field result
- thus based on what you see, if necessary modify the above DISM
command for harddisk# and partition#
/index:1 is the usual location for all devices.
- don't change it
Bitlocker not present on Home is not a variable in whether or not the Recovery partition is functional
Second, because since this 4441 update provides Bitlocker
functionality in some way, and this computer doesn't use either
encryption or Bitlocker, I wanted to know if it still could be
accessed to use the recovery tools if needed. I checked using
reagentc /boottore and yes it did allow me to go in and look around.
It all seems to be there. Only problem I had was on a couple of the
actual recovery option tiles, once clicked I was told I needed an
administrator account to sign in to do anything. There is only one
account on this laptop, and it is an administrator account, though it
is set up as without a MS account. If I recall they call that an off
line account. So I guess in a way it is not functional until I can
figure out what that means.
- which you proved.
The 4441/4232 combined update is meant to be applied with or without Bitlocker and for both Home, Pro, etc. editions.
- The SafeOS update(4232) is should be seen/interpreted as a necessary compatibility update(alleviate a potential problem) that installs prior
to '4441' which installs and updates the Recovery partition.
One could attempt to install the correct bit version of the very small
size stand-alone SafeOS '4232' update, restart, then let Windows Update attempt to install '4441' <https://www.catalog.update.microsoft.com/Search.aspx?q=KB5034232>
sticks wrote on 2/8/24 6:56 PM:version for Windows 7, 8.0 and 8.1 users.
On 2/7/2024 9:55 PM, ...w¡ñ§±¤ñ wrote:Interesting.
DISM /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\winre.wim /index:1
Note: the above is an example...variables that may need to be changed if different for your system are
harddisk1
parition4
/index:1
When you run reagentc /info the first two terms are shown in the Windows RE Location field result
- thus based on what you see, if necessary modify the above DISM command for harddisk# and partition#
/index:1 is the usual location for all devices.
- don't change it
I ran this and it looks old (2014), maybe it can tell you something that is wrong?
<https://www.dropbox.com/scl/fi/4o12tuqttpcvdgm5nv3a3/Get-ImageInfo.jpg?rlkey=j6grshwae1s7sp5f8xuf47mty&dl=0>
Your pic indicates Service Pack Build 16384.
10240.16384 is the official RTM build of the original release of Windows 10 original released to Insider Ring on July 15 2015 and the general public on July 29th 2015. Exactly one year later ithe same build was released/used as the free upgrade
16384 was also the initial Win RE build with those 2012 era 'create and modify' dates.updates to WinRE partition were included(when required to be updated) in the monthly Cumulative Updates(for Win10 22H2 and also Win11 22H2
We can postulate about all the possible reasons on how WinRE partition was modified since 2015....originally as part of feature build updates(semi-annually up up to 21H2, then annually starting with 22H2(fall of 2022). The following year in June 2023
- In Nov. 2023, Win11 23H2 released and included in the WinRE partition inclusion in monthly updates.
Why your WinRE service pack build number over 8 yrs old could be a variety of causes.
- never updated with feature updates
- that earlier partition #2 Recovery partition(which iirc you removed was created at one time in the #5 partition(by Windows, and after the Windows partition) maybe with the #2 partition bits and never ever updated
=> Updating WinRE partition should have at least happened on #5 multiple times and especially with 21H1, 21H2, and 22H2 and again via cumulative updates in July 2023, Sept 2023, Dec 2023....and again in Jan 2024.
=> Once your redid the disk(removing #2 the inactive WinRE, and resized #4(which was #5)...if done properly it would have at least 22H2 bits with a Service Pack build # of 3000 or greater.
Which raises a few reasonable questions.
What did you use to resize Windows and the Recovery Partion?
Did you follow the KB article for resizing WinRE partition? <https://support.microsoft.com/help/5028997>
Anything else, about this device or past history that's not been provided in earlier posts?
sticks wrote on 2/8/24 6:56 PM:
On 2/7/2024 9:55 PM, ...w¡ñ§±¤ñ wrote:Interesting.
DISM /Get-ImageInfo
/ImageFile:\\?\GLOBALROOT\device\harddisk1\partition4\Recovery\WindowsRE\winre.wim /index:1
Note: the above is an example...variables that may need to be changed
if different for your system are
harddisk1
parition4
/index:1
When you run reagentc /info the first two terms are shown in the
Windows RE Location field result
- thus based on what you see, if necessary modify the above DISM
command for harddisk# and partition#
/index:1 is the usual location for all devices.
- don't change it
I ran this and it looks old (2014), maybe it can tell you something
that is wrong?
<https://www.dropbox.com/scl/fi/4o12tuqttpcvdgm5nv3a3/Get-ImageInfo.jpg?rlkey=j6grshwae1s7sp5f8xuf47mty&dl=0>
Your pic indicates Service Pack Build 16384.
10240.16384 is the official RTM build of the original release of
Windows 10 original released to Insider Ring on July 15 2015 and the
general public on July 29th 2015. Exactly one year later ithe same build
was released/used as the free upgrade version for Windows 7, 8.0 and 8.1 users.
16384 was also the initial Win RE build with those 2012 era 'create and modify' dates.
We can postulate about all the possible reasons on how WinRE partition
was modified since 2015....originally as part of feature build updates(semi-annually up up to 21H2, then annually starting with
22H2(fall of 2022). The following year in June 2023 updates to WinRE partition were included(when required to be updated) in the monthly Cumulative Updates(for Win10 22H2 and also Win11 22H2
- In Nov. 2023, Win11 23H2 released and included in the WinRE
partition inclusion in monthly updates.
Why your WinRE service pack build number over 8 yrs old could be a
variety of causes.
- never updated with feature updates
- that earlier partition #2 Recovery partition(which iirc you removed
was created at one time in the #5 partition(by Windows, and after the
Windows partition) maybe with the #2 partition bits and never ever updated
=> Updating WinRE partition should have at least happened on #5 multiple times and especially with 21H1, 21H2, and 22H2 and again via cumulative updates in July 2023, Sept 2023, Dec 2023....and again in Jan 2024.
=> Once your redid the disk(removing #2 the inactive WinRE, and
resized #4(which was #5)...if done properly it would have at least 22H2
bits with a Service Pack build # of 3000 or greater.
Which raises a few reasonable questions.
What did you use to resize Windows and the Recovery Partion?
Did you follow the KB article for resizing WinRE partition?
<https://support.microsoft.com/help/5028997>
Anything else, about this device or past history that's not been
provided in earlier posts?
sticks wrote on 2/10/24 8:29 AM:
On 2/10/2024 4:32 AM, ...w¡ñ§±¤ñ wrote:
This came as a Windows 8.0 which immediately got upgraded to 8.1
That adds some creditibilty to the old 16384 Service Pack #.
- Note: Paul caught the 6.2.9200 Windows 8.0 version
It also may indicate a resistance to past feature and cumulative updates which had code to update the WinRE partition(i.e. those updates expect
to see Win10 content not 8.0/8.1)
Which raises a few reasonable questions.
What did you use to resize Windows and the Recovery Partion?
Did you follow the KB article for resizing WinRE partition?
<https://support.microsoft.com/help/5028997>
Yes, except I did not use 250MB. I have done this several times now
and made them all a little bigger than that.
Anything else, about this device or past history that's not been
provided in earlier posts?
I.e. you used the diskpart routine to resize and not 3rd party software
- Did you also use Diskpart commands to delete the old partition
:) If this were my device I would have wiped that device after upgrading
to Win10(digital license now link to the device) and used Win10 22H2 usb created media for booting, its includes tools to wipe the device, and a diskpart script to create the 4 required GPT partitions(System 100MB,
MSR 16 MB, Windows, and a 2.0 GB Win RE partition, then continue and
install Windows 10 22H2
- Also, that first account created after W10 22H2 installation and
final setup would be a MSFT account, not a Local account.
I have the original win 8 key, but would like to just reinstall the
Win 10 on it's own.
With Win10 on the current device and digitally licensed the Win8 key is
not needed, at at this stage useless.
Does raise a question
Was this device upgraded from Win8x Home to Win8x Pro or Win10 Home to Win10 Pro?
sticks wrote on 2/15/24 7:19 AM:
Wtg! Well done.
You're welcome.
You can rerun that earlier mentioned commane to see your current WinRE Service Pack build and dates etc.
Sometimes the wipe path is the easier route, especially in this case
when the WinRE partition build was showing and old o/s(unsupported long
ago) build number.
There were other ways to replace that Win8 era WinRE...as I said messy
- one of which pulls/extracts the WinRE.wim file(using the DISM
command) from an external(or mounted ISO) same o/s(as installed) media's install.wim file(not install.esd used in Media Creation tool media),
copy the winre.wim to the C:\..\Recovery folder allowing it be used
when reaagentc is later enabled and moved to the newly created WinRE partition.
sticks wrote on 2/17/24 9:34 AM:
On 2/16/2024 11:36 AM, ...w¡ñ§±¤ñ wrote:
sticks wrote on 2/15/24 7:19 AM:
Wtg! Well done.
You're welcome.
You can rerun that earlier mentioned commane to see your current
WinRE Service Pack build and dates etc.
I had intended to do this and forgot before claiming it was all fixed.
Nice catch. When I checked, it was all the same build (2014) as
before. I had to go back and do the recreating of the partition, and
renamed the .wim file in the recovery directory, re-enabling it, and I
think it finally shows a current ReAgent!
<https://www.dropbox.com/scl/fi/qb1aa61bhgdo5099bvpws/ReAgentNew.jpg?rlkey=jnhiz15sutdqm2cwsnv61k1qr&dl=0>
That looks right for Win10. Other Win10 devices Service Pack Build,
date created can look different, some of which being dependent upon the version of or the point in time the Win10 media was created or downloaded.
- e.g. Win10 22H2 was released in fall or 2022 but the Media Creation
Tool and ISO have been updated with some new system files. Win11 WinRE
System Build likewise can show variation in the Service Pack Build(e.g.
3000 vs 3007 or higher)
Sometimes the wipe path is the easier route, especially in this case
when the WinRE partition build was showing and old o/s(unsupported
long ago) build number.
There were other ways to replace that Win8 era WinRE...as I said messy >>> - one of which pulls/extracts the WinRE.wim file(using the DISM
command) from an external(or mounted ISO) same o/s(as installed)
media's install.wim file(not install.esd used in Media Creation tool
media), copy the winre.wim to the C:\..\Recovery folder allowing it
be used when reaagentc is later enabled and moved to the newly
created WinRE partition.
I think what I did wrong during the reinstall was that I just
refreshed the recovery partition instead of formatting it?
Yes, wiping the disk, then following all the steps to create all 4 GPT partitions is the preferred approach.
When clean installing Windows by booting the media I use the Advanced
options mode allowing me command line control and access to Diskpart for running a Diskpart script(*.txt file). The script(while in Diskpart)
isn't necessary since all commands can be entered/typed manually, but
using the script ensures no errors(typing), streamlines the process and
it's faster.
- Here's an example script of all the steps for a device with a single
256 GB SSD as Disk 0.
**************
rem DISKPART script
rem Disk 0 with a single 256 GB SSD
rem Creates GPT(EFI MSR Windows with 2 GB Recovery)
rem Disk 0 OpSy Windows10 Pro 22H2
rem Select Disk, wipe it empty, convert to GPT
select disk 0
clean
convert gpt
create partition efi size=100
format quick fs=fat32 label="System"
create partition msr size=16
create partition primary
shrink minimum=2048
format quick fs=ntfs label="Windows10Pro"
assign letter="W"
create partition primary size=2048
format quick fs=ntfs label="WinRE"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
rem Exit Diskpart
rem written by winston
exit
******************
Once done(diskpart exited), all that remains is to continue clean
installing Win10 22H2 to the Windows partition.
Thanks!You're welcome
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 09:20:28 |
| Calls: | 6,666 |
| Files: | 12,213 |
| Messages: | 5,336,264 |
