Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > alt.comp.os.windows-10 > #187478 > unrolled thread

Windows 10 and Windows 11 ISOs

Started byJack <Jack@invalid.invalid>
First post2025-09-16 02:30 +0000
Last post2025-09-22 09:49 +0100
Articles 20 on this page of 63 — 22 participants

Back to article view | Back to alt.comp.os.windows-10


Contents

  Windows 10 and Windows 11 ISOs Jack <Jack@invalid.invalid> - 2025-09-16 02:30 +0000
    Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-16 07:09 -0400
    Re: Windows 10 and Windows 11 ISOs "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-09-16 23:08 +0800
      Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-16 13:17 -0400
        Re: Windows 10 and Windows 11 ISOs T <T@invalid.invalid> - 2025-09-16 23:09 -0700
        Re: Windows 10 and Windows 11 ISOs "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-09-21 14:49 +0800
      Re: Windows 10 and Windows 11 ISOs Jack <Jack@invalid.invalid> - 2025-09-16 20:43 +0000
        Re: Windows 10 and Windows 11 ISOs Roger Blake <rogblake@iname.invalid> - 2025-09-16 21:53 +0000
        Re: Windows 10 and Windows 11 ISOs Stan Brown <someone@example.com> - 2025-09-17 07:52 -0700
        Re: Windows 10 and Windows 11 ISOs "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-09-21 14:49 +0800
          Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-21 07:19 -0400
            Re: Windows 10 and Windows 11 ISOs Shinji Ikari <shinji@gmx.net> - 2025-09-21 19:05 +0200
            Re: Windows 10 and Windows 11 ISOs "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-09-23 18:58 +0800
        Re: Windows 10 and Windows 11 ISOs Daniel70 <daniel47@nomail.afraid.org> - 2025-09-21 20:22 +1000
          Re: Windows 10 and Windows 11 ISOs "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-09-21 19:59 +0100
            Re: Windows 10 and Windows 11 ISOs Daniel70 <daniel47@nomail.afraid.org> - 2025-09-22 20:15 +1000
    Re: Windows 10 and Windows 11 ISOs Mark Lloyd <not.email@all.invalid> - 2025-09-16 20:40 +0000
      Re: Windows 10 and Windows 11 ISOs "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-09-21 14:51 +0800
        Re: Windows 10 and Windows 11 ISOs Daniel70 <daniel47@nomail.afraid.org> - 2025-09-21 20:23 +1000
          Re: Windows 10 and Windows 11 ISOs "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-09-26 14:17 +0800
            Re: Windows 10 and Windows 11 ISOs MikeS <mikes@is.invalid> - 2025-09-26 10:11 +0100
              Re: Windows 10 and Windows 11 ISOs "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-09-29 14:39 +0800
            Re: Windows 10 and Windows 11 ISOs Daniel70 <daniel47@nomail.afraid.org> - 2025-09-26 23:16 +1000
              Re: Windows 10 and Windows 11 ISOs Fraud Detective <fraud.detective@hotmail.com> - 2025-09-26 21:20 +0000
                Re: Windows 10 and Windows 11 ISOs "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-09-29 14:38 +0800
    Re: Windows 10 and Windows 11 ISOs WolfFan <akwolffan@zoho.com> - 2025-09-17 08:18 -0400
    Re: Windows 10 and Windows 11 ISOs "Joel W. Crump" <joelcrump@gmail.com> - 2025-09-17 17:32 -0400
      Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-17 22:12 -0400
        Re: Windows 10 and Windows 11 ISOs "Joel W. Crump" <joelcrump@gmail.com> - 2025-09-17 22:31 -0400
          Re: Windows 10 and Windows 11 ISOs "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-09-18 08:35 +0100
            Re: Windows 10 and Windows 11 ISOs "Joel W. Crump" <joelcrump@gmail.com> - 2025-09-18 09:09 -0400
            Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-18 09:47 -0400
            Re: Windows 10 and Windows 11 ISOs Frank Slootweg <this@ddress.is.invalid> - 2025-09-18 15:06 +0000
        Re: Windows 10 and Windows 11 ISOs Daniel70 <daniel47@nomail.afraid.org> - 2025-09-18 20:26 +1000
          Re: Windows 10 and Windows 11 ISOs Andy Burns <usenet@andyburns.uk> - 2025-09-18 11:38 +0100
            Re: Windows 10 and Windows 11 ISOs Frank Slootweg <this@ddress.is.invalid> - 2025-09-18 14:49 +0000
              Re: Windows 10 and Windows 11 ISOs "...winston" <winstonmvp@gmail.com> - 2025-09-18 12:20 -0400
                Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-18 12:52 -0400
              Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-18 12:32 -0400
                Re: Windows 10 and Windows 11 ISOs Frank Slootweg <this@ddress.is.invalid> - 2025-09-18 18:18 +0000
                Re: Windows 10 and Windows 11 ISOs "...winston" <winstonmvp@gmail.com> - 2025-09-19 03:02 -0400
          Re: Windows 10 and Windows 11 ISOs "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-09-18 16:31 +0100
            Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-18 12:13 -0400
              Re: Windows 10 and Windows 11 ISOs Frank Slootweg <this@ddress.is.invalid> - 2025-09-18 18:18 +0000
                Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-18 18:34 -0400
            Re: Windows 10 and Windows 11 ISOs Char Jackson <none@none.invalid> - 2025-09-18 14:19 -0500
              Re: Windows 10 and Windows 11 ISOs "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-09-19 06:32 +0100
                Re: Windows 10 and Windows 11 ISOs Char Jackson <none@none.invalid> - 2025-09-19 02:12 -0500
                  Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-19 09:37 -0400
                    Re: Windows 10 and Windows 11 ISOs "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-09-19 16:29 +0100
                      Re: Windows 10 and Windows 11 ISOs Frank Slootweg <this@ddress.is.invalid> - 2025-09-19 18:07 +0000
                        Re: Windows 10 and Windows 11 ISOs "J. P. Gilliver" <G6JPG@255soft.uk> - 2025-09-19 21:00 +0100
                    Re: Windows 10 and Windows 11 ISOs "Bill Bradshaw" <bradshaw@gci.net> - 2025-09-19 09:07 -0800
                      Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-19 15:32 -0400
                        Re: Windows 10 and Windows 11 ISOs "Bill Bradshaw" <bradshaw@gci.net> - 2025-09-20 09:05 -0800
                    Re: Windows 10 and Windows 11 ISOs Char Jackson <none@none.invalid> - 2025-09-19 20:20 -0500
                      Re: Windows 10 and Windows 11 ISOs Daniel70 <daniel47@nomail.afraid.org> - 2025-09-20 19:12 +1000
                        Re: Windows 10 and Windows 11 ISOs ant@zimage.comANT (Ant) - 2025-09-20 23:37 +0000
          Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-18 11:32 -0400
    Re: Windows 10 and Windows 11 ISOs Steve Hayes <hayesstw@telkomsa.net> - 2025-09-18 05:01 +0200
      Re: Windows 10 and Windows 11 ISOs Paul <nospam@needed.invalid> - 2025-09-17 23:49 -0400
        Re: Windows 10 and Windows 11 ISOs "...winston" <winstonmvp@gmail.com> - 2025-09-18 12:58 -0400
    Re: Windows 10 and Windows 11 ISOs wasbit <wasbit@REMOVEhotmail.com> - 2025-09-22 09:49 +0100

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →


#187555

From"...winston" <winstonmvp@gmail.com>
Date2025-09-19 03:02 -0400
Message-ID<10aiv62$bi23$1@dont-email.me>
In reply to#187540
Paul wrote:
> Win10 22H2 ISO has been on offer since, well, 2022, and it is 2025,
> and you've had three years to get one :-)

While those older ISO may work fine for reinstallation.
   The latest ISO is preferred with the May 2023 installation files.
  Likewise, use of this ISO for installation and/or recovery is better, 
though subsequent Windows Updating will update the o/s system files 
including WinRE(SafeOS, Secure Boot changes, yada, yada, etc.)


-- 
...w¡ñ§±¤ñ

[toc] | [prev] | [next] | [standalone]


#187536

From"J. P. Gilliver" <G6JPG@255soft.uk>
Date2025-09-18 16:31 +0100
Message-ID<10ah8k1$3nl4g$1@dont-email.me>
In reply to#187526
On 2025/9/18 11:26:22, Daniel70 wrote:

[]> When I brought this Desktop, it already had Win-11 installed .... so I
> don't have an .iso file.
> 
> It has been updated over the last twelve months or so. And, of course,
> I've added programs that I use, as well.
> 
> Can I create an .iso file from what I've got ... or am I out of luck??

I don't know if you can make a .iso that includes other softwares you've
installed; I think not, but it's not an area I'm familiar with.

I think you'd do better with an image, which would in the event of
disaster (drive failure, ransomware) let you restore to the state you
are (or were when you made the image). (With all the softwares
configured as they are.)

There are several utilities that will make the image - Paul and I like
Macrium, but the latest version has moved to subscriptionware - but you
should still be able to find the free version, which I think so far
works with W11 (Paul can say which version you need). Alternatives are
EaseUS and Acronis, I think - maybe others too.

If you do go the image route, it helps to keep user-created data on a
different partition (or drive) - simply to keep the size of the image
file down. (you should still back up your data too of course, but that
doesn't _need_ an image - any sort of backup will work, even just
copying. I use FreeFileSync, that way I don't need to copy what hasn't
changed [though I should, occasionally].)
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

This was before we knew that a laboratory rat, if experimented upon,
will develop cancer.	[Quoted by] Anne (annezo@aol.com), 1997-1-29

[toc] | [prev] | [next] | [standalone]


#187538

FromPaul <nospam@needed.invalid>
Date2025-09-18 12:13 -0400
Message-ID<10ahb2p$3vl55$1@dont-email.me>
In reply to#187536
On Thu, 9/18/2025 11:31 AM, J. P. Gilliver wrote:
> On 2025/9/18 11:26:22, Daniel70 wrote:
> 
> []> When I brought this Desktop, it already had Win-11 installed .... so I
>> don't have an .iso file.
>>
>> It has been updated over the last twelve months or so. And, of course,
>> I've added programs that I use, as well.
>>
>> Can I create an .iso file from what I've got ... or am I out of luck??
> 
> I don't know if you can make a .iso that includes other softwares you've
> installed; I think not, but it's not an area I'm familiar with.
> 
> I think you'd do better with an image, which would in the event of
> disaster (drive failure, ransomware) let you restore to the state you
> are (or were when you made the image). (With all the softwares
> configured as they are.)
> 
> There are several utilities that will make the image - Paul and I like
> Macrium, but the latest version has moved to subscriptionware - but you
> should still be able to find the free version, which I think so far
> works with W11 (Paul can say which version you need). Alternatives are
> EaseUS and Acronis, I think - maybe others too.
> 
> If you do go the image route, it helps to keep user-created data on a
> different partition (or drive) - simply to keep the size of the image
> file down. (you should still back up your data too of course, but that
> doesn't _need_ an image - any sort of backup will work, even just
> copying. I use FreeFileSync, that way I don't need to copy what hasn't
> changed [though I should, occasionally].)
> 

Daniels storage is just the one device, as far as I can remember.

Version 6.3.1865 or so, I think that had the fix for the Microsoft change
to the handling of $BITMAP. Backups likely work today, with any V7 or V8
version. Should not be a problem.

https://www.majorgeeks.com/files/details/macrium_reflect_free_edition.html    # Version 8.0.7783

The bitness of the download, should match the bitness of the OS.
If you are on Win10 32 bit, you would download the 32-bit version.
If you are on Win11 (which is 64 bit only), use the 64 bit version.

These samples were downloaded at the end of the year 2024.

   Name: reflect_setup_free_x64--807783.exe
   Size: 186,003,336 bytes (177 MiB)
   SHA256: 23B7DC4FEDF86957820A900EF7A521A88FAC563C40820278BA8D998E54D6AACC

   Name: reflect_setup_free_x86--807783.exe
   Size: 167,898,960 bytes (160 MiB)
   SHA256: BFFEEFA4FA5AC8D67386FAE5922CBF25B4380F8B11E2BA5219097F9F409AE9FA

This shows installing the product (a bit of the procedure), followed
by making rescue media.

    [Picture]  "Download original" for best resolution.
               If frame is blank, right-click and select "Reload"

    https://i.postimg.cc/054trNDv/make-rescue-cd-via-win-vm.gif

You can make an ISO, or have Macrium burn a CD.

The output is about 300MB or so, and it will fit on a CD.

Only the inclusion of a large number of custom drivers, would tend to break it for
usage on a CD. The default drivers are quite frequently good enough.

Do a test boot of the Rescue media, to verify it boots,
after you prepare some form of it. You can put the Macrium ISO onto a
USB stick with Rufus, because it resembles a Windows installer enough
to use the same wrapper scheme.

Every version will have some differences in options offered, so the
Postimg is just a hint as to what some of the steps look like.
The WinRE option is only going to work, if your "reagentc is in top-shape".
And nobody wants to be messing with that. If the WinRE was in better
shape, using the WinRE option could save on disk space a bit, but
the first time I tried it, Macrium located and used the wrong WinRE
for the job. That has undoubtedly been fixed by now (on 8.0.7783 for sure).

   Paul

[toc] | [prev] | [next] | [standalone]


#187547

FromFrank Slootweg <this@ddress.is.invalid>
Date2025-09-18 18:18 +0000
Message-ID<10ahpcq.3so.1@ID-201911.user.individual.net>
In reply to#187538
Paul <nospam@needed.invalid> wrote:
[...]

[About making Macrium Reflect 'Rescue media':]

> You can make an ISO, or have Macrium burn a CD.
> 
> The output is about 300MB or so, and it will fit on a CD.
> 
> Only the inclusion of a large number of custom drivers, would tend to
> break it for usage on a CD. The default drivers are quite frequently
> good enough.

  Well, I don't think I did anything special, but my (Windows RE 11
Build 22000 (64-bit)) Rescue media for Macrium Reflect Free (64-bit)
v8.0.6867 on my Windows 11 system, was 717.9 MB, so it would probably
*not* fit on a normal CD.  (I used a (8 GB) USB memory-stick, so size
was not an issue.)

[...]

[toc] | [prev] | [next] | [standalone]


#187550

FromPaul <nospam@needed.invalid>
Date2025-09-18 18:34 -0400
Message-ID<10ai1cq$5hmb$1@dont-email.me>
In reply to#187547
On Thu, 9/18/2025 2:18 PM, Frank Slootweg wrote:
> Paul <nospam@needed.invalid> wrote:
> [...]
> 
> [About making Macrium Reflect 'Rescue media':]
> 
>> You can make an ISO, or have Macrium burn a CD.
>>
>> The output is about 300MB or so, and it will fit on a CD.
>>
>> Only the inclusion of a large number of custom drivers, would tend to
>> break it for usage on a CD. The default drivers are quite frequently
>> good enough.
> 
>   Well, I don't think I did anything special, but my (Windows RE 11
> Build 22000 (64-bit)) Rescue media for Macrium Reflect Free (64-bit)
> v8.0.6867 on my Windows 11 system, was 717.9 MB, so it would probably
> *not* fit on a normal CD.  (I used a (8 GB) USB memory-stick, so size
> was not an issue.)
> 
> [...]
> 

You used the default WinRE.wim option and that is a lot larger
than the WADK-prepared WinPE.wim . And that has stuffed in it,
whatever Microsoft put in the WinRE.wim of your ReagentC, rather
than the curated Macrium design of the WinPE. The WinRE.wim has been
growing (a tiny bit) and various tricks have been used to resize
the Recovery Partition, to make room for it.

These are the Recovery Partitions on my current drive. The 532
is the Windows 11 Home. The 512 is the Windows 10 Pro. The letter
K is the assign letter trick done via diskpart.exe .

K:\Recovery\WindowsRE>dir /ah
 Volume in drive K has no label.
 Volume Serial Number is B8AE-FFB3

 Directory of K:\Recovery\WindowsRE

Thu, 09/18/2025  11:05 AM    <DIR>          .
Sun, 08/13/2023  12:41 AM    <DIR>          ..
Sat, 05/07/2022  01:19 AM         3,170,304 boot.sdi
Thu, 09/18/2025  11:05 AM             1,139 ReAgent.xml
Thu, 09/05/2024  11:53 PM       532,748,021 Winre.wim

K:\Recovery\WindowsRE>dir /ah
 Volume in drive K has no label.
 Volume Serial Number is 6C1C-D72A

 Directory of K:\Recovery\WindowsRE

Sat, 07/12/2025  08:20 PM    <DIR>          .
Wed, 05/28/2025  10:07 AM    <DIR>          ..
Sat, 12/07/2019  05:08 AM         3,170,304 boot.sdi
Wed, 05/28/2025  10:11 AM             1,109 ReAgent.xml
Sat, 07/12/2025  08:19 PM       512,443,380 winre.wim

You can also look inside your Macrium ISO using 7ZIP.
And figure out what bloats it the most.

   [Picture]

    https://i.postimg.cc/pL8LcG2s/7-ZIP-showing-Rescue-CD.gif

   Paul

[toc] | [prev] | [next] | [standalone]


#187549

FromChar Jackson <none@none.invalid>
Date2025-09-18 14:19 -0500
Message-ID<prlockpsiao6ep99213tg2ss4ss0rjl18c@4ax.com>
In reply to#187536
On Thu, 18 Sep 2025 16:31:12 +0100, "J. P. Gilliver" <G6JPG@255soft.uk>
wrote:

>If you do go the image route, it helps to keep user-created data on a
>different partition (or drive) - simply to keep the size of the image
>file down. (you should still back up your data too of course, but that
>doesn't _need_ an image - any sort of backup will work, even just
>copying. I use FreeFileSync, that way I don't need to copy what hasn't
>changed [though I should, occasionally].)

Do you do anything to address the possibility of bit rot?

There are usually two aspects to that can of worms: detection and
correction.

Detection can be accomplished in a number of ways, by using checksums on
individual files, by using the natural ability of containers such as 7z
zip rar etc. to check the integrity of their contents, or by using a
tool such as quickpar to check files, folders, or an entire drive, but
remember that all of these methods rely on data being static. If the
underlying data changes, the checksums or whatever you use must also be
updated. You can segment your data into two groups - things that change
and things that should never change.

The second aspect is correction. Detection of bit rot, without a means
for correcting it, can sometimes be worse than simply not knowing you
have a problem. I use quickpar because it's a fast, lightweight, tool
that handles both detection and correction, but I think most people just
prefer not to know. It's less stressful.

[toc] | [prev] | [next] | [standalone]


#187553

From"J. P. Gilliver" <G6JPG@255soft.uk>
Date2025-09-19 06:32 +0100
Message-ID<10aipu5$3nh73$5@dont-email.me>
In reply to#187549
On 2025/9/18 20:19:36, Char Jackson wrote:
> On Thu, 18 Sep 2025 16:31:12 +0100, "J. P. Gilliver" <G6JPG@255soft.uk>
> wrote:
> 
>> If you do go the image route, it helps to keep user-created data on a
>> different partition (or drive) - simply to keep the size of the image
>> file down. (you should still back up your data too of course, but that
>> doesn't _need_ an image - any sort of backup will work, even just
>> copying. I use FreeFileSync, that way I don't need to copy what hasn't
>> changed [though I should, occasionally].)
> 
> Do you do anything to address the possibility of bit rot?

Not as much as I should.

For my _images_, yes I do - each image (of C: and hiden partitions) is
newly made.

For my (data) backups, I alternate between two "synced" copies - but of
course by the nature of syncing, files that don't change are not
checked. (My "though I should" above shows I am aware of the problem,
but am not doing anything about it.)

I think rather than getting into complicated monitoring against rot,
just starting a complete new backup occasionally - though it may take
longer - is simpler.--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Farc gorillas who live in the plains of the undies ..." - automatic
subtitling seen on BBC one o'clock news, 2016-8-25, by Cynthia Hollingworth.

[toc] | [prev] | [next] | [standalone]


#187556

FromChar Jackson <none@none.invalid>
Date2025-09-19 02:12 -0500
Message-ID<o70qck13qiupp9a0vskq8k3h6ij4mfsm70@4ax.com>
In reply to#187553
On Fri, 19 Sep 2025 06:32:53 +0100, "J. P. Gilliver" <G6JPG@255soft.uk>
wrote:

>On 2025/9/18 20:19:36, Char Jackson wrote:
>> 
>> Do you do anything to address the possibility of bit rot?
>
>Not as much as I should.
>
<snip>
>
>I think rather than getting into complicated monitoring against rot,
>just starting a complete new backup occasionally - though it may take
>longer - is simpler.

Sounds like the assumption is that the source files are always good and
only the backups are at any risk of damage. To a large degree, I follow
that logic here, but it may not be the perfect approach. I've seen cases
here, where a damaged file is backed up and I'm not aware until much
later. 

[toc] | [prev] | [next] | [standalone]


#187563

FromPaul <nospam@needed.invalid>
Date2025-09-19 09:37 -0400
Message-ID<10ajmao$h4m1$1@dont-email.me>
In reply to#187556
On Fri, 9/19/2025 3:12 AM, Char Jackson wrote:
> On Fri, 19 Sep 2025 06:32:53 +0100, "J. P. Gilliver" <G6JPG@255soft.uk>
> wrote:
> 
>> On 2025/9/18 20:19:36, Char Jackson wrote:
>>>
>>> Do you do anything to address the possibility of bit rot?
>>
>> Not as much as I should.
>>
> <snip>
>>
>> I think rather than getting into complicated monitoring against rot,
>> just starting a complete new backup occasionally - though it may take
>> longer - is simpler.
> 
> Sounds like the assumption is that the source files are always good and
> only the backups are at any risk of damage. To a large degree, I follow
> that logic here, but it may not be the perfect approach. I've seen cases
> here, where a damaged file is backed up and I'm not aware until much
> later. 
> 

I had bad RAM on the WinXP machine, and out of idleness I would
sometimes run the Verify on the .mrimgs I was making on there.
And to my shock and horror, one of them had a bad verify (making
a little project for myself). I had to drop what I was doing,
and Verify in earnest.

It turned out several of them were bad, did not pass Verify, and it
was bad RAM in some filesystem sensitive location doing it. I changed
out all four RAM sticks (as I could not MEMTEST and isolate to any
stick less than the entire set of four installed), and finally I
could make a .mrimg that would pass Verify. The WinXP machine had
DDR2 RAM, and by the time the machine died, I was on my third set
of RAM. The later machines don't do this. DDR4/DDR5, you can get
decent RAM now (and hey, even decent memory controllers).

You could go to the trouble of doing a hashdeep or md5deep of the file
tree, and do a restore on a test disk, and do the hashdeep on there.
It has an option to compare a previously prepared manifest against
a second disk. And that would tell you whether the clusters were
coming back, but it might not catch every security setting for the
files.

But part of the problem with Windows and this sort of verification,
is the OS is always "doing things", so a lot of your work has to be
done offline, and even Macrium may leave a marker after a run,
so you hardly have forensic control of what is going on.

And you'd need a fleet of clean disks to be doing the experiments on :-)
Even for a guy with a fleet of disks, I don't always have a fleet of
clean disks ready for this kind of "trouble".

*******

Yesterdays experiment, was to upgrade a Windows 11 Pro 23H2 to 24H2.
Since 25H2 is incoming, the settings level in WU should be "aggressive"
for 23H2 to 24H2, and it took giving the disk a rest for eight hours,
before WU admitted it was doing 24H2 (without my permission, just...
doing it). No, I'm pretty careful about these things, and I didn't click
anything.

But anyway, I couldn't run cleanmgr.exe afterwards and get it to stop
faffing about. It spent a lot of time calculating, and not a lot of
time cleaning. I tried killing "competing" activities on the machine,
still did not help. It appeared to have the storage railed, while
making no progress at all.

Turns out it was fragmented from here to hell and back. Looks like
the scheduled defrag/optimize had never run. It was bad enough, I
cloned over from HDD to NVMe, tried to fix it there, the NVMe was
running like snot too, cloned it back to HDD again (make partition
size smaller during the clone-over, it defragments for you). Finally
the file system was defragmented enough, the cleanmgr run would
remove the Windows.old for me. That's all I wanted to do.

Now, while this was going on, during the clone, the declared size
of the files on disk, varied between 33GB and 44GB or so. I had mentioned
to Frank, about Macrium not always handling things in System Volume Information
correctly. That didn't seem to be the issue this time. It seemed to be
the "invalid $BITMAP" on the file system at rest doing this. As eventually
after a couple reboots (and re-mounts of the file system), the Properties
dialog for C: finally returned to the original 44GB partition size.
I can tell you, if that was my Daily Driver doing this, I would
have been furious. Fortunately, this is just a part of the fleet, maintained
for test. But these are the sorts of behaviors that make you question
whether this is an OS or not, when this stuff happens. How can you have
a filesystem that doesn't inventory properly at all times ? The Properties
dialog for C: , should always return correct values.

Even if you hashdeeped the tree, depending on when and where you do that,
there could be hundreds of entries in the difference as the OS keeps
making files underneath.

******* Some info on hashdeep/md5deep checksumming, just the basics *******

https://en.wikipedia.org/wiki/Md5deep

   https://github.com/jessek/hashdeep/     # source only

   2014: V4.4

   https://github.com/jessek/hashdeep/releases

        md5deep-4.4.zip   3.62 MB   <=== link is inconvenient to copy, use the link on page
                                         Need your "good" browser to get the file.
        Name: md5deep-4.4.zip
        Size: 3,792,436 bytes (3703 KiB)
        SHA256: D5E85933E74E5BA6A73F67346BC2E765075D26949C831A428166C92772F67DBC

        You can unpack one of the EXE from the ZIP for usage. hashdeep64.exe on a 64 bit machine perhaps.

  L:\hashdeep64.exe -h                                   # reference to instructions

  cd /d c:\                                              # Set the working dir. Original test tree C:\Downloads

  L:\hashdeep64.exe -j 1 -c md5 -r Downloads > L:\audit.txt   # Generate a filelist with hashes, single threaded
                                                              # MD5 is good enough for checking storage corruption.

The output looks like this. All the zero-sized files should have the same MD5 value.
(This text was extracted from a previous audit file, and does not "match" the above example.
 It shows that you get size, md5 hash value, filename per entry.)

%%%% size,md5,filename
1908,d1e75542ec8d1b4851765a57ac63618e,C:\$WINDOWS.~BT\Sources\Panther\diagerr.xml
5375,b8b50a45c5d1a80862be54cc7e8765a9,C:\$WINDOWS.~BT\Sources\Panther\diagwrn.xml
7534,46b37bdb08213e86a466942707cdfcb4,C:\$WINDOWS.~BT\Sources\Panther\setupact.log
0,d41d8cd98f00b204e9800998ecf8427e,C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
5411,3bb75bebcf1ba4ca264e07be4f065b75,C:\$Windows.~WS\Sources\Panther\diagerr.xml

   cd /d L:\                                              # Set the working dir, to the second tree needing comparison
                                                          # L is SSD-like, so the thread count is 8 (thrashing not an issue)

   hashdeep64.exe -j 8 -c md5 -k audit.txt -a -v -v -r L:\Downloads > audit-out.txt

And the audit.txt is then compared to the calculation coming from the second tree.

I recommend starting with small, artificially prepared test trees, just so
you are comfortable with "naming issues" in the audit file. With an edit and
bulk replace of the audit.txt, you can make the audit file "look like" it
was the same as the destination tree for example. With relative tree-naming,
the thing might work "easier".

If you are attempting to verify a "hacker-attacked" tree, don't use MD5 for that.
MD5 is cracked, and someone who knows you will use MD5, can modify a file so
it has the same MD5. MD5 used in the way above, is looking for mechanical
damage from file systems or OSes or program malfunctions. If dealing with
a security issue, you would use one of the slower/stronger hashes.

   Paul

[toc] | [prev] | [next] | [standalone]


#187567

From"J. P. Gilliver" <G6JPG@255soft.uk>
Date2025-09-19 16:29 +0100
Message-ID<10ajst9$id8m$4@dont-email.me>
In reply to#187563
On 2025/9/19 14:37:22, Paul wrote:
> On Fri, 9/19/2025 3:12 AM, Char Jackson wrote:
>> On Fri, 19 Sep 2025 06:32:53 +0100, "J. P. Gilliver" <G6JPG@255soft.uk>
>> wrote:
>>
>>> On 2025/9/18 20:19:36, Char Jackson wrote:
>>>> Do you do anything to address the possibility of bit rot?
>>> Not as much as I should.
>>>
>> <snip>
>>> I think rather than getting into complicated monitoring against rot,
>>> just starting a complete new backup occasionally - though it may take
>>> longer - is simpler.
>> Sounds like the assumption is that the source files are always good and
>> only the backups are at any risk of damage. To a large degree, I follow

I realised as I was writing (or shortly after) that that was indeed the
case.

>> that logic here, but it may not be the perfect approach. I've seen cases
>> here, where a damaged file is backed up and I'm not aware until much
>> later. 

I've had that with my genealogy stuff: the software (Brother's Keeper)
had removed the links from my mother (and possibly other people) to
several of the picture files; since I don't look at the picture tab
every time I go to a person's record, I was not aware of that until it
was well and truly baked into many backups. (Fortunately the picture
files themselves weren't lost, only the links to them, which weren't
hard to regenerate.)>>
> I had bad RAM on the WinXP machine, and out of idleness I would
> sometimes run the Verify on the .mrimgs I was making on there.
> And to my shock and horror, one of them had a bad verify (making
> a little project for myself). I had to drop what I was doing,
> and Verify in earnest.

Ah, I usually _do_ set the verify flag for my images, since they're
small so it doesn't take that long. But - other than that I alternate
between two sets - I don't have anything similar for my data backups,
which are arguably _more_ important. (Though I do backup the Thunderbird
and Genealogy sections more often and differently.)>
> It turned out several of them were bad, did not pass Verify, and it
> was bad RAM in some filesystem sensitive location doing it. I changed
> out all four RAM sticks (as I could not MEMTEST and isolate to any
> stick less than the entire set of four installed), and finally I
> could make a .mrimg that would pass Verify. The WinXP machine had
> DDR2 RAM, and by the time the machine died, I was on my third set
> of RAM. The later machines don't do this. DDR4/DDR5, you can get
> decent RAM now (and hey, even decent memory controllers).
> 
> You could go to the trouble of doing a hashdeep or md5deep of the file
> tree, and do a restore on a test disk, and do the hashdeep on there.
> It has an option to compare a previously prepared manifest against
> a second disk. And that would tell you whether the clusters were
> coming back, but it might not catch every security setting for the
> files.
> 
> But part of the problem with Windows and this sort of verification,
> is the OS is always "doing things", so a lot of your work has to be
> done offline, and even Macrium may leave a marker after a run,
> so you hardly have forensic control of what is going on.

I always both make, and restore from, my images having cold booted from
the Macrium disc. (Actually I can't remember when I last had to do a
restore.) I know Macrium _can_ make an image from a running system, I
just feel more secure not doing so.>
> And you'd need a fleet of clean disks to be doing the experiments on 🙂
> Even for a guy with a fleet of disks, I don't always have a fleet of
> clean disks ready for this kind of "trouble".
> 
> *******
> 
> Yesterdays experiment, was to upgrade a Windows 11 Pro 23H2 to 24H2.
> Since 25H2 is incoming, the settings level in WU should be "aggressive"
> for 23H2 to 24H2, and it took giving the disk a rest for eight hours,
> before WU admitted it was doing 24H2 (without my permission, just...
> doing it). No, I'm pretty careful about these things, and I didn't click
> anything.
> 
> But anyway, I couldn't run cleanmgr.exe afterwards and get it to stop
> faffing about. It spent a lot of time calculating, and not a lot of
> time cleaning. I tried killing "competing" activities on the machine,
> still did not help. It appeared to have the storage railed, while
> making no progress at all.
> 
> Turns out it was fragmented from here to hell and back. Looks like
> the scheduled defrag/optimize had never run. It was bad enough, I
> cloned over from HDD to NVMe, tried to fix it there, the NVMe was

Does defrag run on a non-spinning drive? I thought it served little
purpose, and shortened the life of the "drive".

> running like snot too, cloned it back to HDD again (make partition
> size smaller during the clone-over, it defragments for you). Finally
> the file system was defragmented enough, the cleanmgr run would
> remove the Windows.old for me. That's all I wanted to do.
> 
> Now, while this was going on, during the clone, the declared size
> of the files on disk, varied between 33GB and 44GB or so. I had mentioned
> to Frank, about Macrium not always handling things in System Volume Information
> correctly. That didn't seem to be the issue this time. It seemed to be
> the "invalid $BITMAP" on the file system at rest doing this. As eventually
> after a couple reboots (and re-mounts of the file system), the Properties
> dialog for C: finally returned to the original 44GB partition size.
> I can tell you, if that was my Daily Driver doing this, I would
> have been furious. Fortunately, this is just a part of the fleet, maintained
> for test. But these are the sorts of behaviors that make you question
> whether this is an OS or not, when this stuff happens. How can you have

Indeed!

> a filesystem that doesn't inventory properly at all times ? The Properties
> dialog for C: , should always return correct values.

[rest snipped as it's way over my head!]
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

(Incidentally, it was made in Spain so shouldn't it be a "paella
western"?) - Barry Norman [on "A Fistful of Dollars"], RT 2014/10/4-10

[toc] | [prev] | [next] | [standalone]


#187571

FromFrank Slootweg <this@ddress.is.invalid>
Date2025-09-19 18:07 +0000
Message-ID<10akd60.oe0.1@ID-201911.user.individual.net>
In reply to#187567
J. P. Gilliver <G6JPG@255soft.uk> wrote:
> On 2025/9/19 14:37:22, Paul wrote:
[...]
> > I had bad RAM on the WinXP machine, and out of idleness I would
> > sometimes run the Verify on the .mrimgs I was making on there.
> > And to my shock and horror, one of them had a bad verify (making
> > a little project for myself). I had to drop what I was doing,
> > and Verify in earnest.
> 
> Ah, I usually _do_ set the verify flag for my images, since they're
> small so it doesn't take that long.

  I always do a Auto Verify of my Macrium Reflect backups. It's just an
(Advanced) Option in the Backup Definition File. As I make my images
online (VSS takes care of 'freezing' the file system), time isn't really
an issue.

  Perhaps offline backup also has such a verify setting. If so, I
strongly recommend to use that, especially since your images are small.

>				      But - other than that I alternate
> between two sets - I don't have anything similar for my data backups,
> which are arguably _more_ important. (Though I do backup the Thunderbird
> and Genealogy sections more often and differently.)>

  My file backups are also done to several sets of disks in a rotating
fashion.

[...]

> > But part of the problem with Windows and this sort of verification,
> > is the OS is always "doing things", so a lot of your work has to be
> > done offline, and even Macrium may leave a marker after a run,
> > so you hardly have forensic control of what is going on.
> 
> I always both make, and restore from, my images having cold booted from
> the Macrium disc. (Actually I can't remember when I last had to do a
> restore.) I know Macrium _can_ make an image from a running system, I
> just feel more secure not doing so.>

  After an image backup, I always do a file restore of a recently
modified file and compare (UNIX cmp(1)) the contents with that of the
original. If the Auto Verify during backup and the file restore/compare
do not give any errors (which they have never done), I consider the
image to be OK. As the images are also copied to others disks, I think I
have some protection against bit-rot.

[...]

[toc] | [prev] | [next] | [standalone]


#187575

From"J. P. Gilliver" <G6JPG@255soft.uk>
Date2025-09-19 21:00 +0100
Message-ID<10akcop$id8m$8@dont-email.me>
In reply to#187571
On 2025/9/19 19:7:34, Frank Slootweg wrote:
> J. P. Gilliver <G6JPG@255soft.uk> wrote:

[]

>> Ah, I usually _do_ set the verify flag for my images, since they're
>> small so it doesn't take that long.
> 
>   I always do a Auto Verify of my Macrium Reflect backups. It's just an
> (Advanced) Option in the Backup Definition File. As I make my images
> online (VSS takes care of 'freezing' the file system), time isn't really
> an issue.
> 
>   Perhaps offline backup also has such a verify setting. If so, I
> strongly recommend to use that, especially since your images are small.

It's virtually identical with the boot-from-disc version (I'm guessing
that's what you mean by offline) - just a tickbox in the Advanced
options section.
[]>   After an image backup, I always do a file restore of a recently
> modified file and compare (UNIX cmp(1)) the contents with that of the
> original. If the Auto Verify during backup and the file restore/compare
> do not give any errors (which they have never done), I consider the
> image to be OK. As the images are also copied to others disks, I think I
> have some protection against bit-rot.
> 
> [...]
I reckon the fact that my images are made anew (not incremental - not
sure if the Free version does incremental; anyway, I don't), plus the
verify option, protects me adequately - for the C: (OS plus software)
image. It's my _data_ backups that are more likely to be susceptible to
that.

-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Less rules means fewer grammar? - Marjorie in UMRA, 2014-1-28 13:14

[toc] | [prev] | [next] | [standalone]


#187570

From"Bill Bradshaw" <bradshaw@gci.net>
Date2025-09-19 09:07 -0800
Message-ID<mj5gv0Fi2clU1@mid.individual.net>
In reply to#187563
Paul wrote:
> On Fri, 9/19/2025 3:12 AM, Char Jackson wrote:
>> On Fri, 19 Sep 2025 06:32:53 +0100, "J. P. Gilliver"
>> <G6JPG@255soft.uk> wrote:
>
> Yesterdays experiment, was to upgrade a Windows 11 Pro 23H2 to 24H2.
> Since 25H2 is incoming, the settings level in WU should be
> "aggressive"
> for 23H2 to 24H2, and it took giving the disk a rest for eight hours,
> before WU admitted it was doing 24H2 (without my permission, just...
> doing it). No, I'm pretty careful about these things, and I didn't
> click
> anything.
>
>   Paul

Did you have the computer paused?  I brought up one other time that 
Microsoft was going to ignore us.
-- 
<Bill>

Brought to you from Anchorage, Alaska 

[toc] | [prev] | [next] | [standalone]


#187572

FromPaul <nospam@needed.invalid>
Date2025-09-19 15:32 -0400
Message-ID<10akb4n$molj$2@dont-email.me>
In reply to#187570
On Fri, 9/19/2025 1:07 PM, Bill Bradshaw wrote:
> Paul wrote:
>> On Fri, 9/19/2025 3:12 AM, Char Jackson wrote:
>>> On Fri, 19 Sep 2025 06:32:53 +0100, "J. P. Gilliver"
>>> <G6JPG@255soft.uk> wrote:
>>
>> Yesterdays experiment, was to upgrade a Windows 11 Pro 23H2 to 24H2.
>> Since 25H2 is incoming, the settings level in WU should be
>> "aggressive"
>> for 23H2 to 24H2, and it took giving the disk a rest for eight hours,
>> before WU admitted it was doing 24H2 (without my permission, just...
>> doing it). No, I'm pretty careful about these things, and I didn't
>> click
>> anything.
>>
>>   Paul
> 
> Did you have the computer paused?  I brought up one other time that 
> Microsoft was going to ignore us.
> 

I used InControl to prevent 24H2 from coming in.
InControl was set to 23H2 before that, then I changed
the release value to 24H2. And the Upgrade came in without
any further prompting.

   Paul

[toc] | [prev] | [next] | [standalone]


#187587

From"Bill Bradshaw" <bradshaw@gci.net>
Date2025-09-20 09:05 -0800
Message-ID<mj8570F11rsU1@mid.individual.net>
In reply to#187572
Paul wrote:
> On Fri, 9/19/2025 1:07 PM, Bill Bradshaw wrote:
>> Paul wrote:
>>> On Fri, 9/19/2025 3:12 AM, Char Jackson wrote:
>>>> On Fri, 19 Sep 2025 06:32:53 +0100, "J. P. Gilliver"
>>>> <G6JPG@255soft.uk> wrote:
>>>
>>> Yesterdays experiment, was to upgrade a Windows 11 Pro 23H2 to 24H2.
>>> Since 25H2 is incoming, the settings level in WU should be
>>> "aggressive"
>>> for 23H2 to 24H2, and it took giving the disk a rest for eight
>>> hours, before WU admitted it was doing 24H2 (without my permission,
>>> just... doing it). No, I'm pretty careful about these things, and I
>>> didn't click
>>> anything.
>>>
>>>   Paul
>>
>> Did you have the computer paused?  I brought up one other time that
>> Microsoft was going to ignore us.
>>
>
> I used InControl to prevent 24H2 from coming in.
> InControl was set to 23H2 before that, then I changed
> the release value to 24H2. And the Upgrade came in without
> any further prompting.
>
>   Paul

I use Edge Blocker, InControl, and Windows Update Blocker in an attempt to 
control the Host Process For Windows Services :-).  I had not noticed you 
could change the version in InControl so that was good info me.
-- 
<Bill>

Brought to you from Anchorage, Alaska 

[toc] | [prev] | [next] | [standalone]


#187576

FromChar Jackson <none@none.invalid>
Date2025-09-19 20:20 -0500
Message-ID<pktrckdhs99j9v1uo56vigkhqs60er7rol@4ax.com>
In reply to#187563
On Fri, 19 Sep 2025 09:37:22 -0400, Paul <nospam@needed.invalid> wrote:

>On Fri, 9/19/2025 3:12 AM, Char Jackson wrote:
>> On Fri, 19 Sep 2025 06:32:53 +0100, "J. P. Gilliver" <G6JPG@255soft.uk>
>> wrote:
>> 
>>> On 2025/9/18 20:19:36, Char Jackson wrote:
>>>>
>>>> Do you do anything to address the possibility of bit rot?
>>>
>>> Not as much as I should.
>>>
>> <snip>
>>>
>>> I think rather than getting into complicated monitoring against rot,
>>> just starting a complete new backup occasionally - though it may take
>>> longer - is simpler.
>> 
>> Sounds like the assumption is that the source files are always good and
>> only the backups are at any risk of damage. To a large degree, I follow
>> that logic here, but it may not be the perfect approach. I've seen cases
>> here, where a damaged file is backed up and I'm not aware until much
>> later. 
>> 
>
>I had bad RAM on the WinXP machine, and out of idleness I would
>sometimes run the Verify on the .mrimgs I was making on there.
>And to my shock and horror, one of them had a bad verify (making
>a little project for myself). I had to drop what I was doing,
>and Verify in earnest.
>
>It turned out several of them were bad, did not pass Verify, and it
>was bad RAM in some filesystem sensitive location doing it. I changed
>out all four RAM sticks (as I could not MEMTEST and isolate to any
>stick less than the entire set of four installed), and finally I
>could make a .mrimg that would pass Verify. The WinXP machine had
>DDR2 RAM, and by the time the machine died, I was on my third set
>of RAM. The later machines don't do this. DDR4/DDR5, you can get
>decent RAM now (and hey, even decent memory controllers).

I've never had bad RAM, but many years ago when 20GB hard drives were
considered huge, I bought one that quietly corrupted every single file
that I moved over to it. It didn't happen right away. Like every clever
corruption issue, it waited a month or two until I was comfortable with
the new drive and satisfied that it was working properly. 

>You could go to the trouble of doing a hashdeep or md5deep of the file
>tree, and do a restore on a test disk, and do the hashdeep on there.
>It has an option to compare a previously prepared manifest against
>a second disk. And that would tell you whether the clusters were
>coming back, but it might not catch every security setting for the
>files.

I'm comfortable with quickpar after using it for more than 20 years, but
you're right that there are other ways to try to detect corruption.
Quickpar does its error detection in place, so there's no need to create
a temporary copy elsewhere. As I mentioned in a previous post, quickpar
not only detects file corruption, it can also correct the error(s), if
any, assuming you've planned ahead a bit and have created sufficient
parity files.

>But part of the problem with Windows and this sort of verification,
>is the OS is always "doing things", so a lot of your work has to be
>done offline, and even Macrium may leave a marker after a run,
>so you hardly have forensic control of what is going on.

I only pay attention to non-Windows data files that rarely or ever
change, so Windows meddling hasn't ever been an issue.

<snipped good stuff about hashdeep>

[toc] | [prev] | [next] | [standalone]


#187581

FromDaniel70 <daniel47@nomail.afraid.org>
Date2025-09-20 19:12 +1000
Message-ID<10alr6c$113on$1@dont-email.me>
In reply to#187576
On 20/09/2025 11:20 am, Char Jackson wrote:

<Snip>

> I've never had bad RAM, but many years ago when 20GB hard drives were
> considered huge, I bought one that quietly corrupted every single file
> that I moved over to it. It didn't happen right away. Like every clever
> corruption issue, it waited a month or two until I was comfortable with
> the new drive and satisfied that it was working properly.

"but many years ago when 20GB hard drives were considered huge".

I can remember, back in the day, I had a 10MB HD ... to which I applied 
'MS Double Space' (was that about MS-DOS 5 or 6 or something??) which 
then gave me about 18MB - 20MB.

Woo Hoo!! ;-P
-- 
Daniel70

[toc] | [prev] | [next] | [standalone]


#187591

Fromant@zimage.comANT (Ant)
Date2025-09-20 23:37 +0000
Message-ID<10ands0$1dn3h$2@dont-email.me>
In reply to#187581
In alt.comp.os.windows-10 Daniel70 <daniel47@nomail.afraid.org> wrote:
> On 20/09/2025 11:20 am, Char Jackson wrote:

> <Snip>

> > I've never had bad RAM, but many years ago when 20GB hard drives were
> > considered huge, I bought one that quietly corrupted every single file
> > that I moved over to it. It didn't happen right away. Like every clever
> > corruption issue, it waited a month or two until I was comfortable with
> > the new drive and satisfied that it was working properly.

> "but many years ago when 20GB hard drives were considered huge".

> I can remember, back in the day, I had a 10MB HD ... to which I applied 
> 'MS Double Space' (was that about MS-DOS 5 or 6 or something??) which 
> then gave me about 18MB - 20MB.

> Woo Hoo!! ;-P

I used Stacker software, without its hardware, for my IBM PS/2 model 30 286 10 Mhz PC's 30 MB HDD! Woohoo. :-p
-- 
"Make allowance for each other's faults, and forgive anyone who offends you. Remember, the Lord forgave you, so you must forgive others." --Colossians 3:13. Dang leaks, sneezes, aches, itches, etc.
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
  /\___/\   Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
 / /\ /\ \                      Please nuke ANT if replying by e-mail.
| |o   o| |
   \ _ /
    ( )

[toc] | [prev] | [next] | [standalone]


#187537

FromPaul <nospam@needed.invalid>
Date2025-09-18 11:32 -0400
Message-ID<10ah8n5$3v1sd$1@dont-email.me>
In reply to#187526
On Thu, 9/18/2025 6:26 AM, Daniel70 wrote:

> 
> When I brought this Desktop, it already had Win-11 installed .... so I
> don't have an .iso file.
> 
> It has been updated over the last twelve months or so. And, of course,
> I've added programs that I use, as well.
> 
> Can I create an .iso file from what I've got ... or am I out of luck??

While you can make a Recovery stick or so, it has the added programs removed.
This makes the effort a giant waste of time, as it isn't really a "Recovery" stick :-/

Just download the ISO and be happy. It doesn't have your programs either.

For the Recovery stick option to work, the reagentc has to be in "top shape".

*******
reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

    Windows RE status:         Disabled   <=== Busted, Again... Grrr.
    Windows RE location:
    Boot Configuration Data (BCD) identifier: 2329e315-3b91-11f0-99b1-df5f4917c70d
    Recovery image location:
    Recovery image index:      0
    Custom image location:
    Custom image index:        0

REAGENTC.EXE: Operation Successful.

reagentc /enable                           <=== My assumption is, setting OK, just needs enable
REAGENTC.EXE: Operation Successful.

reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

    Windows RE status:         Enabled
    Windows RE location:       \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
    Boot Configuration Data (BCD) identifier: 60ab5743-710c-11f0-9717-2cf05dd9f734
    Recovery image location:
    Recovery image index:      0
    Custom image location:
    Custom image index:        0

REAGENTC.EXE: Operation Successful.
*******

So now if I wanted, I could make a Recovery stick.
Which should be sufficient to Clean reinstall the OS (after HDD dies).
But not the programs.

If you made the OS installation using "Rufus and tick boxes",
then all bets are off as to what happens when making a
Recovery Stick.

Making a Recovery Stick takes a lot of time, and this is
especially hurtful, if it blows an error after wasting your time.
It is much better to just download an ISO. Such as a Win11 24H2 today.

But if you (somehow) waited too long to gather an ISO, making
the Recovery stick is a (remote) option.

The OS also has "Refresh" and "Reset" options.

In Settings, try searching on "Refresh", to see some options listed.

   Paul

[toc] | [prev] | [next] | [standalone]


#187516

FromSteve Hayes <hayesstw@telkomsa.net>
Date2025-09-18 05:01 +0200
Message-ID<vetmck5acbrkv2k4tej08o9uceebdahe1v@4ax.com>
In reply to#187478
On Tue, 16 Sep 2025 02:30:00 +0000, Jack <Jack@invalid.invalid> wrote:

>Microsoft will remove the ISOs for Windows 10 and Windows 11 24H2 by 14 
>October 2025. Therefore, it is advisable to download the ISOs for your 
>current language and store them safely in an easily accessible location.
>
>Ideally, zip and password-protect them in case you decide to store them 
>in Google Drive and/or OneDrive (like me), to prevent Microsoft and 
>Google from mistakenly identifying them as pirated files and removing them.

Where and how does one get them?


-- 
Steve Hayes from Tshwane, South Africa
Web:  http://www.khanya.org.za/stevesig.htm
Blog: http://khanya.wordpress.com
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

[toc] | [prev] | [next] | [standalone]


Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | alt.comp.os.windows-10


csiph-web