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

Groups > comp.os.linux.advocacy > #687635

Re: Dimdows Decay Syndrome Continues

Cross-posted to 2 groups.

Show all headers | View raw

On Tue, 3/18/2025 11:04 AM, CrudeSausage wrote:
> On 2025-03-17 17:37, Lawrence D'Oliveiro wrote:
>> On Sat, 1 Feb 2025 21:55:15 -0000 (UTC), I wrote:
>>
>>> Many years ago, a software engineer named Fred Brooks predicted that
>>> some systems could get so complex that they would exceed a
>>> manageable threshold of complexity, where every attempt to fix a bug
>>> would just create new ones.
>>>
>>> Microsoft passed this point a long time ago.
>>
>> Further evidence
>> <https://arstechnica.com/gadgets/2025/03/this-months-windows-updates-are-removing-the-copilot-app-accidentally/>:
>> now a Dimdows update deletes your Copilot app and taskbar icon, and
>> the only workaround is to put it all back again yourself:
>>
>>      Microsoft says it is "working on a resolution to address the
>>      issue" but that users who want to get Copilot back can reinstall
>>      the app from the Microsoft Store and repin it to the taskbar, the
>>      same process you use to install Copilot on PCs where it has been
>>      removed.
>>
>> This is why they say, Windows is a great OS -- if your time is worth
>> nothing.
> 
> I can't disagree with the last part. Unsurprisingly, even yesterday, I ran an sfc /scannow & dism /online /cleanup-image /scanhealth combination, and I wasn't surprised to discover that the system once again had components needing to be repaired. The machine is always put to suspend as it should be and shut down properly, yet Windows breaks even when you use it properly. I can only imagine how "slow" the machine gets for users who don't know about these repair options and the constant need to execute them.
> 

PS> dism /Online /Cleanup-image /ScanHealth

Deployment Image Servicing and Management tool
Version: 10.0.22621.2792

Image Version: 10.0.22631.5039

[==========================100.0%==========================] No component store corruption detected.
The operation completed successfully.

PS>

I don't sleep or hibernate or fast start.
Notice how clean my stuff is. If there is a
change of state from S0, it's a shutdown, where the
OS dismounts the file system before termination. It
flushes any caches (the OS has a write cache in RAM,
the cache normally being flushed).

*******

Deployment Image Servicing and Management

dism /Online /Cleanup-image /ScanHealth
dism /Online /Cleanup-image /CheckHealth
dism /Online /Cleanup-image /RestoreHealth
dism /Online /Cleanup-image /StartComponentCleanup
Sfc /ScanNow                                           # You do the SFC, after the DISM ones if any

Windows Command Prompt

Dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase

Warning: All existing update packages can't be uninstalled after this
         command is completed, but this won't block the un-installation
         of future update packages.

*******

W11Home

DISM runs on this OS:  1      # Run for amusement, on lowest level which is a "check" only.
SFC runs on this OS:   0

Disk seems to be working OK.

399,000 files on C:
There is no C:\Windows\servicing\LCU on Windows 11, so no LCU to count.

W10Pro

572,000 files
C:\Windows\servicing\LCU on Windows 10  178,000 files (can be deleted)

It's also sunny outside today, but still a bit cold.

*******

You can do a Repair Install, to tart up the WinSxS files.

While you could do a backup and restore, in an attempt to "clean"
the C: file system, that's not going to be entirely successful.
If you had any $BADCLUS entries, those would likely be preserved in
the backup, which is not a desirable property. It's normally pretty
difficult to regress to the point that the OS registers those -- the
auto-sparing of the storage devices, normally "hides the health" of
the storage so $BADCLUS (a concept from long ago), does not trigger.

I did have one of those here, and it was a bitch to get rid of.

   Paul

Back to comp.os.linux.advocacy | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-17 21:37 +0000
  Re: Dimdows Decay Syndrome Continues Frank Slootweg <this@ddress.is.invalid> - 2025-03-18 13:31 +0000
    Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-03-18 11:08 -0400
  Re: Dimdows Decay Syndrome Continues CrudeSausage <crude@sausa.ge> - 2025-03-18 11:04 -0400
    Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-03-18 19:29 -0400
  Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-02 22:53 +0000
    Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-06-02 23:27 -0400

csiph-web