• Windows 10 Home Computer Not Updating

    From Bill Bradshaw@21:1/5 to All on Wed Dec 18 12:58:51 2024
    I update my Win 10 computers with a cumulative update file and did not
    notice one of the computers had not successfully updated since April 2024.
    I should of been checking the updates listing and I would have seen this.
    The computer is stuck at 19045.5011. It appears this started with the installation of KB5001716. I have been working on this on and off for the
    10 days. I used MediaCreationTool_22H2 to create a USB Flash drive and ran that and got a message the computer was up to date. I did make a Macrium
    image backup so I can restore the computer to its broken state. I am going
    to use MediaCreation on one of the good computers to create a Flash drive
    and try that with the hope I do not have to use my Macrium backup. Any suggestions?

    <Bill>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From sticks@21:1/5 to Bill Bradshaw on Wed Dec 18 16:06:54 2024
    On 12/18/2024 3:58 PM, Bill Bradshaw wrote:
    I update my Win 10 computers with a cumulative update file and did not
    notice one of the computers had not successfully updated since April 2024.
    I should of been checking the updates listing and I would have seen this.
    The computer is stuck at 19045.5011. It appears this started with the installation of KB5001716. I have been working on this on and off for the
    10 days. I used MediaCreationTool_22H2 to create a USB Flash drive and ran that and got a message the computer was up to date. I did make a Macrium image backup so I can restore the computer to its broken state. I am going to use MediaCreation on one of the good computers to create a Flash drive
    and try that with the hope I do not have to use my Macrium backup. Any suggestions?

    You didn't say if KB5001716 failed or not. Are there other KB updates
    that too have failed.

    Here's the usual stuff you might have tried and that winston generally recommends.

    <https://www.partitionwizard.com/news/kb5001716-fails-to-install.html>


    --
    I Stand With Israel!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hank Rogers@21:1/5 to Bill Bradshaw on Wed Dec 18 16:40:21 2024
    Bill Bradshaw wrote:
    I update my Win 10 computers with a cumulative update file and did not
    notice one of the computers had not successfully updated since April 2024.
    I should of been checking the updates listing and I would have seen this.
    The computer is stuck at 19045.5011. It appears this started with the installation of KB5001716. I have been working on this on and off for the
    10 days. I used MediaCreationTool_22H2 to create a USB Flash drive and ran that and got a message the computer was up to date. I did make a Macrium image backup so I can restore the computer to its broken state. I am going to use MediaCreation on one of the good computers to create a Flash drive
    and try that with the hope I do not have to use my Macrium backup. Any suggestions?

    <Bill>


    Updates may be winding down, as win 10 will be end of life in less than
    a year. But, you can buy a one year extension from micro$oft to get
    another year of updates.

    I know how you feel. You can also keep using win 10 without updates. Try
    to get a decent antivirus installed. I did that with win XP for MANY
    years. I never used win 10 until 2019.

    Since you have multiple computers, I suggest you pick one good machine
    and install win 11. There are many methods to install it on non
    compliant machines using iso files. That's what I'm using right now with
    a computer built in 2012. Try it a while and if it works with your most important applications and data, it may be a godsend for you.

    You are familiar with macrium reflect, so use that often and you can
    roll back if things go bad for you. Good luck.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bill Bradshaw@21:1/5 to Bill Bradshaw on Wed Dec 18 14:54:46 2024
    Bill Bradshaw wrote:
    I update my Win 10 computers with a cumulative update file and did not
    notice one of the computers had not successfully updated since April
    2024. I should of been checking the updates listing and I would have
    seen this. The computer is stuck at 19045.5011. It appears this
    started with the installation of KB5001716. I have been working on
    this on and off for the 10 days. I used MediaCreationTool_22H2 to
    create a USB Flash drive and ran that and got a message the computer
    was up to date. I did make a Macrium image backup so I can restore
    the computer to its broken state. I am going to use MediaCreation on
    one of the good computers to create a Flash drive and try that with
    the hope I do not have to use my Macrium backup. Any suggestions?

    <Bill>

    Ignore this. I bit the bullet and reinstalled so now it is current other
    than I have to rebuild it and try to remember all the things I have done
    over the years.

    <Bill>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to Bill Bradshaw on Wed Dec 18 21:43:07 2024
    Bill Bradshaw <bradshaw@gci.net> wrote:

    Ignore this. I bit the bullet and reinstalled so now it is current
    other than I have to rebuild it and try to remember all the things I
    have done over the years.

    Didn't read your reply until after I sent mine.

    Next time, review the WU logs to see if updates failed. Also, always
    reboot after a WU update even when not prompted to do so. A reboot
    ensures the fileset that got changed is fully replaced in a current
    instance of a running Windows. Without a reboot, and despite Microsoft thinking one wasn't needed, a mismatched fileset can result in some
    functions not working properly.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From VanguardLH@21:1/5 to Bill Bradshaw on Wed Dec 18 21:39:31 2024
    Bill Bradshaw <bradshaw@gci.net> wrote:

    I update my Win 10 computers with a cumulative update file and did not
    notice one of the computers had not successfully updated since April
    2024. I should of been checking the updates listing and I would have
    seen this.

    The computer is stuck at 19045.5011. It appears this started with the installation of KB5001716. I have been working on this on and off
    for the 10 days. I used MediaCreationTool_22H2 to create a USB Flash
    drive and ran that and got a message the computer was up to date.

    I did make a Macrium image backup so I can restore the computer to its
    broken state. I am going to use MediaCreation on one of the good
    computers to create a Flash drive and try that with the hope I do not
    have to use my Macrium backup.

    I have seen where updates won't get retrieved until a dependent update
    is first installed. For example, new updates don't get retrieved until
    the Windows Update tool first gets updated. After WU gets updated then
    the later updates get retrieved.

    Did you look at the WU log to see if there are any failed updates?
    Those could stall later updates. KB5001716 is titled "Update for
    Windows Update Service" which sounds suspicously familiar to the above mentioned scenario. In the WU log, did that update succeed? If it did,
    have you yet rebooted the computer? Not a resume from hibernate, but a
    full (cold) reboot.

    Rather than use the MCT to try to update, did you try running the WU
    tool to have it check for updates within the current instance of
    Windows? The WU log is at Start Menu, search on (enter) "updates",
    select Check For Updates, and select "View update history". When I
    checked my WU log, KB5001716 was "Successfully installed on 10/12/2024".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to sticks on Thu Dec 19 01:00:54 2024
    On Wed, 12/18/2024 5:06 PM, sticks wrote:
    On 12/18/2024 3:58 PM, Bill Bradshaw wrote:
    I update my Win 10 computers with a cumulative update file and did not
    notice one of the computers had not successfully updated since April 2024. >> I should of been checking the updates listing and I would have seen this.
    The computer is stuck at 19045.5011.  It appears this started with the
    installation of KB5001716.  I have been working on this on and off for the >> 10 days.  I used MediaCreationTool_22H2 to create a USB Flash drive and ran >> that and got a message the computer was up to date.  I did make a Macrium >> image backup so I can restore the computer to its broken state.  I am going >> to use MediaCreation on one of the good computers to create a Flash drive
    and try that with the hope I do not have to use my Macrium backup.   Any >> suggestions?

    You didn't say if KB5001716 failed or not.  Are there other KB updates that too have failed.

    Here's the usual stuff you might have tried and that winston generally recommends.

    <https://www.partitionwizard.com/news/kb5001716-fails-to-install.html>



    Yet another SafeOS update perhaps.

    https://answers.microsoft.com/en-us/windows/forum/all/install-error-0x80070643-windows-10-version-21h2/ca8dc95f-bc48-427b-aa6a-3ef468f61ca0

    Here is a picture as an example:

    [Picture]

    https://i.postimg.cc/wjk2v7p0/Win10-Safe-OS-Recovery-Partition-Win-RE-WIM.gif

    I'm not booted into Windows 10 at the moment, but I keep two OSes on
    the disk drive. And both happen to have Emergency OS images (hidden, can't see them).

    First of all, don't panic if yours does not look like that.
    There are at least three possible partition layouts, and I
    generally don't hunt through the room and take pictures of
    all three. I'm not organized enough for that :-)

    On a W10-over-W7 installation, the partition with the WinRE.wim
    could be to the left of the OS partition.

    It's even possible for an OS to not have a "second partition". The
    SafeOS image in that case, lives inside the C: partition.

    Similarly, when the SafeOS image is "retracted and out of harms way",
    it is also stored inside the C: drive. In fact, there is a very
    complex set of possibilities, for what happened to your WinRE.wim
    file. One of the possibilities is not documented, but I caught
    a glimpse of it here.

    You will notice in the picture, the size of the SafeOS partition is
    bigger than normal. The update they keep trying to stuff in there
    (started with '4441 a while back), it actually needs "more than double
    the original space". To cover off all possibilities, you could for
    example make it 2GB in size.

    On your disk, there could be MSDOS partitioning, rather than the
    GPT partitioning on my disk drive. Sometimes, this can make
    resizing the partition easier. I can generally fix that partition,
    using gparted in Linux. If I use Paragon Partition Manager 14 Free,
    which only has Move/Resize capability, sometimes it whines about
    not being able to do things. The GPT partitions, are not really
    file system specifications, and while the MSDOS partition number
    is 0x27 (Hidden NTFS), the GPT one is "Recovery Partition", and
    a number of file systems can be stuffed in there. The file system
    happens to be NTFS, but the "Hidden" nature of the partition
    is influenced by the GPT behaviors. Whereas it is more of a file
    system level thing, in an MSDOS 0x27 case (where you only expect
    NTFS to be in there, and ExFAT is not a possibility).

    *******

    anyway, with the vast color commentary out of the way:

    reagentc /info

    will dump some information about your emergency OS. If you do

    bcdedit

    the emergency OS receives a reference in there, too. Not that it matters.

    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

    My current booted OS, uses partition4. The Windows 10 OS on mine, uses partition6.

    That's an armed and functional SafeOS, for when C: is corrupted or is
    not accessible because C: is encrypted.

    When reagentc is "Enabled", the WinRE.wim file is in its final resting
    place. When reagentc is "Disabled", the WinRE.wim is moved, to one
    of a couple locations.

    When KB5001716 attempts to do yet another update, to WinRE.wim,
    it is manufactured in C:\$WinREAgent . If you see a multitude of folders
    inside there, it means you are "mid-install" and something is likely
    looping and doing occasional retries. When the folder is mostly
    clean (and especially after a SafeOS install finishes), the folder
    is cleaned up. And the total size will be quite small and not a
    gigabyte of crap in there. Yours is stuck right now, and we don't
    interfere with it.

    The algorithm then, is like using a chum bucket. You pour bait
    over the side of the boat, in the hopes of "attracting an update" :-)
    There *IS* a way to force the issue. We *CAN* give it a whack,
    but we then need to fetch a file from a Win10 installer DVD,
    and that is more complexity than most fishermen are willing
    to resort to.

    Originally, the 0x80070643 error that these update(s) throw, is
    some sort of download error. Unfortunately, the staff lack imagination,
    and the actual multiple failure reasons, all produce the same error
    number.

    The SafeOS update nominally runs out of space. If you resize
    the partition, occasionally that works.

    The "suggested" procedure is to *delete* the old partition
    and make a new one. Now, your balls are too the wall. You're
    all in as it were, and are making a significant investment.
    I don't particularly like doing this -- sure, I did the procedure
    the first time, it all worked out and so on, but this is hardly
    a way to run a snack bar. It's too much work. It scares people.

    Of course, it all scares people. It's all relative.

    What happens in some cases, is when the patch does

    reagentc /disable

    so it can work in there, instead of the old WinRE.wim file being
    preserved in a hidey hole on D: , the twits store the old one
    in a folder off to the side, inside the Recovery Partition. Now,
    there cannot possibly be space to store the new WinRE.wim and the
    attempt of course, fails. Making the partition 2GB in size,
    covers for this possibility. Making the partition only 250MB
    bigger than it used to be, covers the "proper" case, where the
    old WinRE.wim is temporarily stored on C: .

    While some articles refer to this Registry key, Microsoft is
    simply incapable of not stepping in pooh. I installed 24H2 Win11
    on the other machine, via Windows Update invitation, and the
    installation procedure did NOT properly document the SafeOS. Most of
    the time, users find this registry key is not defined. There is
    hardly ever a reason for manually creating one of these.

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
    WinREVersion Reg_SZ 10.0.19041.3920 <=== If '4441 had worked

    If you were to do a Repair Install of the OS (one of our favorite
    techniques as a Plan B for users who are fearful of this level
    of modification, which I can fully understand), the Repair Install
    does not have the logic to do anything clever with respect of
    that partition. Similarly, the idiotic Windows Update patches
    are similarly NOT EQUIPPED to fix the partition, which is why
    this procedure KEEPS FAILING. What we learn from this,
    is it is yet another GroundHog Day Patch from Microsoft, it
    jams up your Windows Update state, the nitwits can't fix it
    from their end, that leaves US HOLDING THE BAG of pooh.

    There is one other root cause for the failure. This is not the
    default for Windows, but I run this way. The WinRE.wim compression
    step fails, if you have done this.

    fsutil behavior query disableCompression

    DisableCompression = 1 (Compression is DISABLED) <=== I run with compression turned off

    If I set the DisableCompression back to 0, then a '4441 update succeeds.
    That is the reason, the one of those trying to install on my
    Windows 11 right now, it can't get in :-) Because of my setting.

    Summary: Most of the time, resizing the SafeOS partition (whether
    it is to the left of C: partition or to the right of C: partition),
    is sufficient for the update to run on a Retry. Disk Management
    can resize C: -- it can do a "Shrink", but Disk Management
    lacks the ability to move the Recovery Partition into the
    space created by shrinking some other partition. Using
    a tool like PM14 Free, as described above, may give the
    ability to deal with the thing. Partition Managers (Linux gparted
    included), work best if move/resize partition candidates contain
    a valid file system. The tiny Microsoft Reserved (partition 2 in my
    picture, Disk Management will not show it) adds extra
    abuse for the user, as it prevents some tools from helping you.

    So while the "cure" is (most of the time) to resize the place
    where the WinRE.wim is stored (reagentc /info), depending on your
    tools and the situation, it can be more difficult than you would
    suspect.

    Provide a picture or a description of your Disk Management situation,
    if you need more specific advice.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Bill Bradshaw on Thu Dec 19 02:11:06 2024
    On Wed, 12/18/2024 6:54 PM, Bill Bradshaw wrote:
    Bill Bradshaw wrote:
    I update my Win 10 computers with a cumulative update file and did not
    notice one of the computers had not successfully updated since April
    2024. I should of been checking the updates listing and I would have
    seen this. The computer is stuck at 19045.5011. It appears this
    started with the installation of KB5001716. I have been working on
    this on and off for the 10 days. I used MediaCreationTool_22H2 to
    create a USB Flash drive and ran that and got a message the computer
    was up to date. I did make a Macrium image backup so I can restore
    the computer to its broken state. I am going to use MediaCreation on
    one of the good computers to create a Flash drive and try that with
    the hope I do not have to use my Macrium backup. Any suggestions?

    <Bill>

    Ignore this. I bit the bullet and reinstalled so now it is current other than I have to rebuild it and try to remember all the things I have done
    over the years.

    <Bill>

    <cough>

    There is no escape from the Borg.
    Or so I'm reliably informed.

    The problem is, the install disc doesn't know how to set up
    the Recovery Partition properly. This means any SafeOS update
    is going to get stuck the same way, at some point. If they had
    fixed the install materials, this would not have happened.
    But of course they didn't fix the install materials.

    The SafeOS that was installed by the installer DVD, also
    did not self-document properly. the "WinReVersion" Reg_SZ
    string did not get created, so you cannot tell what the
    revision of WinRE.wim is in the Recovery Partition. The logic
    uses that entry, to decide whether the SafeOS receives
    an update or not. There is now a folder in the WinRE.wim that
    marks the release of the file, but not all softwares
    that do this work, are going to inject that. That might
    be in a very recent SafeOS fix.

    Since Windows 10 is end of life, KB5001716 is a multi-faceted
    patch. Not only will it add a "band" to the screen, advertising
    Windows 11 and indicating Windows 10 is going out of date, but
    it also does a SafeOS update.

    This means, there is a very good chance, even on your shiny
    new OS, the KB5001716 is going to show up... and it is going to
    get stuck (not finish) because of the difficulty with the
    procedure to make a new WinRE.wim file and create the registry
    key that documents the current version of it.

    There *IS* a way to fix this. But you rushed ahead and
    did the Win10 clean install, without instructions, so there
    was no chance to warn you how to fix it up.

    You can create partitions on the disk drive, such that
    the Windows 10 installer cannot make a Recovery Partition.
    If you succeed at this mission, the reagentc will create
    the file in the C: partition. The C: partition *always*
    has space, since the C: partition is huge, compared to the
    inadequate size of the Recovery Partition. While creating
    a SafeOS solution inside the C: partition is the very
    embodiment of stoopid, it DOES solve the problem of the
    updates getting stuck.

    Otherwise, you still have to address the care and feeding
    of your Recovery Partition, if you want a good mixture
    of functionality (emergency boot capability) plus the
    windows Update not getting jammed.

    *******

    Notice that none of this behavior, is anywhere near SaaS.
    It's a joke, that individual users have to Work THIS HARD
    to keep their updates working. On the one hand, I can see
    the argument that "automation is hard for us". They've
    made such a mess, I would not want to be the person
    having to work with a ton of different disk configs
    (Dell, HP, thankyou), and resize stuff. But the Microsoft
    architecture team made this mess, and somebody has to pay
    to clean it up. It would appear to be a "Casual indifference"
    is behind all of this. The indifference that comes of
    throwing away 400,000,000 users.

    We're still here, and we await your next move.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to All on Thu Dec 19 17:23:34 2024
    On Thu, 12/19/2024 4:27 PM, ...w¡ñ§±¤ñ wrote:
    Paul wrote on 12/19/24 12:11 AM:
    On Wed, 12/18/2024 6:54 PM, Bill Bradshaw wrote:
    Bill Bradshaw wrote:
    I update my Win 10 computers with a cumulative update file and did not >>>> notice one of the computers had not successfully updated since April
    2024. I should of been checking the updates listing and I would have
    seen this. The computer is stuck at 19045.5011.  It appears this
    started with the installation of KB5001716.  I have been working on
    this on and off for the 10 days.  I used MediaCreationTool_22H2 to
    create a USB Flash drive and ran that and got a message the computer
    was up to date.  I did make a Macrium image backup so I can restore
    the computer to its broken state.  I am going to use MediaCreation on >>>> one of the good computers to create a Flash drive and try that with
    the hope I do not have to use my Macrium backup.   Any suggestions?

    <Bill>

    Ignore this.  I bit the bullet and reinstalled so now it is current other >>> than I have to rebuild it and try to remember all the things I have done >>> over the years.

    <Bill>

    <cough>

    There is no escape from the Borg.
    Or so I'm reliably informed.

    The problem is, the install disc doesn't know how to set up
    the Recovery Partition properly. This means any SafeOS update
    is going to get stuck the same way, at some point. If they had
    fixed the install materials, this would not have happened.
    But of course they didn't fix the install materials.

    The SafeOS that was installed by the installer DVD, also
    did not self-document properly. the "WinReVersion" Reg_SZ
    string did not get created, so you cannot tell what the
    revision of WinRE.wim is in the Recovery Partition. The logic
    uses that entry, to decide whether the SafeOS receives
    an update or not. There is now a folder in the WinRE.wim that
    marks the release of the file, but not all softwares
    that do this work, are going to inject that. That might
    be in a very recent SafeOS fix.

    Since Windows 10 is end of life, KB5001716 is a multi-faceted
    patch. Not only will it add a "band" to the screen, advertising
    Windows 11 and indicating Windows 10 is going out of date, but
    it also does a SafeOS update.

    This means, there is a very good chance, even on your shiny
    new OS, the KB5001716 is going to show up... and it is going to
    get stuck (not finish) because of the difficulty with the
    procedure to make a new WinRE.wim file and create the registry
    key that documents the current version of it.

    There *IS* a way to fix this. But you rushed ahead and
    did the Win10 clean install, without instructions, so there
    was no chance to warn you how to fix it up.

    You can create partitions on the disk drive, such that
    the Windows 10 installer cannot make a Recovery Partition.
    If you succeed at this mission, the reagentc will create
    the file in the C: partition. The C: partition *always*
    has space, since the C: partition is huge, compared to the
    inadequate size of the Recovery Partition. While creating
    a SafeOS solution inside the C: partition is the very
    embodiment of stoopid, it DOES solve the problem of the
    updates getting stuck.

    Otherwise, you still have to address the care and feeding
    of your Recovery Partition, if you want a good mixture
    of functionality (emergency boot capability) plus the
    windows Update not getting jammed.

    *******

    Notice that none of this behavior, is anywhere near SaaS.
    It's a joke, that individual users have to Work THIS HARD
    to keep their updates working. On the one hand, I can see
    the argument that "automation is hard for us". They've
    made such a mess, I would not want to be the person
    having to work with a ton of different disk configs
    (Dell, HP, thankyou), and resize stuff. But the Microsoft
    architecture team made this mess, and somebody has to pay
    to clean it up. It would appear to be a "Casual indifference"
    is behind all of this. The indifference that comes of
    throwing away 400,000,000 users.

    We're still here, and we await your next move.

        Paul


    Way too much work..
     Just use the available instructions to increase the size of WinRE partition to 1GB or 2 GB at the expense of the C: Windows partition

    or if clean installing from scratch
    Use 22H2 booted media(or mounted ISO) and Windows installed advanced settings to create the 4 required GPT partition(with WinRE 1 GB or 2 GB) then install Windows 22H2.
     - even easier to use a script to create the partitions especially when pre-written scripts for use in Diskpart are readily available.




    The highest level of complexity I want the users to experience
    here, is having to do a Repair Install to set something up right.

    When the SafeOS problem was recognized, there should have
    been a project to make a new installer DVD for Win10 22H2,
    which would lay down the proper sized Recovery Partition,
    as well as set the WinREVersion registry entry too.

    Yet, that has not been done.

    The Repair Install is a relatively low complexity activity, that
    ordinary users can handle.

    Giving them a script-worthy solution, when there are
    a large number of variables in the partition layout,
    is a big ask.

    As an example, I must have run MBR2GPT on one of my Win10 VMs,
    as an experiment. Yes, it did convert an MSDOS partitioned
    copy of Windows 10 into a GPT partitioned version. But, it also
    placed the partitions in the wrong order. This means if an
    ordinary user did a MBR2GPT before a SafeOS Fix Recipe,
    they will need additional instructions.

    It is, in fact, a "variant hell". Which is why I cannot
    countenance copying a simple minded recipe, to a person
    who does not know what they're doing.

    Hardly anyone gives me partition information.
    If I asked for it, I would not get it.

    And that's the way it goes.

    This is why, the max complexity level I want, is a
    Repair Install. If the logic was in the installer DVD
    to do this right, this job would be SO MUCH EASIER.

    It takes me no time at all to fix these myself, however,
    the recipe for doing this, is outside the purview of this
    group. I can't be giving Linux recipes to people who hate
    Linux. It's not within the group charter either, to
    constantly be doing that. Sometimes I am forced to do it,
    there is no other choice.

    We should not have to be doing this. There needs to be
    some thought put into a mechanism that can clean up this
    mess. The bandaid-thinking that has gone into this so
    far, is pathetic. I could excuse the bandaid-thinking in
    the two month timeframe after the incident, but in
    parallel should be a plan to do better. Where I worked,
    YOU MAKE A MESS, YOU CLEAN IT UP. My company did multi-million
    dollar field recalls, to clean up messes and make it right
    for customers.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)