Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.comp.os.windows-11 > #16688 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2025-02-01 21:55 +0000 |
| Last post | 2025-04-09 00:15 +0000 |
| Articles | 6 on this page of 66 — 15 participants |
Back to article view | Back to alt.comp.os.windows-11
Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-01 21:55 +0000
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-01 19:07 -0500
Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-01 20:11 -0500
Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-02 03:24 +0000
Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2025-02-02 04:05 +0000
Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) CrudeSausage <crude@sausa.ge> - 2025-02-02 07:19 -0500
Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-02-02 07:55 -0500
Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 23:22 +0000
Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Paul <nospam@needed.invalid> - 2025-02-02 00:08 -0500
Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Java Jive <java@evij.com.invalid> - 2025-02-02 13:57 +0000
Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 23:19 +0000
Re: Dimdows Decay Syndrome Continues Mark Lloyd <not.email@all.invalid> - 2025-02-02 19:26 +0000
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-02 14:49 -0500
Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-02 15:29 -0500
Re: Dimdows Decay Syndrome Continues chrisv <chrisv@nospam.invalid> - 2025-02-02 15:26 -0600
Re: Dimdows Decay Syndrome Continues Java Jive <java@evij.com.invalid> - 2025-02-03 02:50 +0000
Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-03 04:03 +0000
Re: Dimdows Decay Syndrome Continues Jeff Barnett <jbb@notatt.com> - 2025-02-02 23:17 -0700
Re: Dimdows Decay Syndrome Continues Java Jive <java@evij.com.invalid> - 2025-02-03 13:16 +0000
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-07 20:03 -0500
Re: Dimdows Decay Syndrome Continues Andy Burns <usenet@andyburns.uk> - 2025-02-08 20:12 +0000
Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-08 21:06 -0500
Re: Dimdows Decay Syndrome Continues CrudeSausage <crude@sausa.ge> - 2025-02-02 07:11 -0500
Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 21:34 +0000
Re: Dimdows Decay Syndrome Continues CrudeSausage <crude@sausa.ge> - 2025-02-07 20:29 -0500
Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 06:36 +0000
Kexec (and HyperV) (was: Re: Dimdows Decay Syndrome Continues) vallor <vallor@cultnix.org> - 2025-02-08 08:44 +0000
Re: Kexec (and HyperV) Paul <nospam@needed.invalid> - 2025-02-08 06:41 -0500
Re: Kexec (and HyperV) (was: Re: Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 23:42 +0000
Re: Kexec (and HyperV) (was: Re: Dimdows Decay Syndrome Continues) vallor <vallor@cultnix.org> - 2025-02-09 00:25 +0000
Re: Dimdows Decay Syndrome Continues CrudeSausage <crude@sausa.ge> - 2025-02-08 09:05 -0500
Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 23:44 +0000
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-08 19:05 -0500
Re: Dimdows Decay Syndrome Continues vallor <vallor@cultnix.org> - 2025-02-09 13:58 +0000
Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-08 21:18 -0500
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-07 21:05 -0500
Re: Dimdows Decay Syndrome Continues Physfitfreak <physfitfreak@gmail.com> - 2025-02-01 21:53 -0600
Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 21:41 +0000
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-07 19:14 -0500
Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-07 20:26 -0500
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-07 20:50 -0500
Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-07 21:57 -0500
Re: Dimdows Decay Syndrome Continues Frank Slootweg <this@ddress.is.invalid> - 2025-02-08 15:22 +0000
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-08 11:24 -0500
Re: Dimdows Decay Syndrome Continues Frank Slootweg <this@ddress.is.invalid> - 2025-02-08 18:36 +0000
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-08 13:49 -0500
Re: Dimdows Decay Syndrome Continues Physfitfreak <physfitfreak@gmail.com> - 2025-02-08 13:48 -0600
Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-08 19:43 +0000
Re: Dimdows Decay Syndrome Continues Frank Slootweg <this@ddress.is.invalid> - 2025-02-08 20:41 +0000
Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-08 16:12 -0500
Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-09 00:35 +0000
Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 23:54 +0000
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-08 19:07 -0500
Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-09 00:40 +0000
Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-18 21:51 +0000
Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-18 17:11 -0500
Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-19 01:06 +0000
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
Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-27 22:03 +0000
Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-09 00:15 +0000
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | CrudeSausage <crude@sausa.ge> |
|---|---|
| Date | 2025-03-18 11:04 -0400 |
| Message-ID | <6YfCP.870900$eNx6.224256@fx14.iad> |
| In reply to | #17811 |
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. -- God be with you, CrudeSausage John 14:6
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-03-18 19:29 -0400 |
| Message-ID | <vrcvkg$3hu6v$1@dont-email.me> |
| In reply to | #17818 |
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
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-06-02 22:53 +0000 |
| Message-ID | <101la0o$3ihfc$1@dont-email.me> |
| In reply to | #17811 |
This time, the bugs in the update are so bad that Microsoft has had to issue an emergency, unscheduled update to fix the update <https://www.computerworld.com/article/4000386/microsoft-issues-out-of-band-patches-for-windows-11-startup-failure.html>. There are all kinds of lovely excuses in the article about how testing can never cover every real-world possibility. But the fact remains that the the frequency of this problem on Windows is way greater than on any other comparable platform.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-06-02 23:27 -0400 |
| Message-ID | <101lq3k$3pljv$1@dont-email.me> |
| In reply to | #19978 |
On Mon, 6/2/2025 6:53 PM, Lawrence D'Oliveiro wrote: > This time, the bugs in the update are so bad that Microsoft has had to > issue an emergency, unscheduled update to fix the update > <https://www.computerworld.com/article/4000386/microsoft-issues-out-of-band-patches-for-windows-11-startup-failure.html>. > > There are all kinds of lovely excuses in the article about how testing > can never cover every real-world possibility. But the fact remains > that the the frequency of this problem on Windows is way greater than > on any other comparable platform. > Gee, it looks like it has happened before. https://answers.microsoft.com/en-us/windows/forum/all/recovery-error-acpisys-your-pc-needs-to-be/42cf8731-6775-4ab4-ac8e-c2db82aaf2bf A Reddit thread says: "ACPI.sys is the AML interpreter. The AML code is part of the BIOS, try updating the BIOS" https://en.wikipedia.org/wiki/ACPI#AML At the BIOS development time, AML bytecode is compiled from the ASL (ACPI Source Language) code.[8][9] [8] "ACPI in FreeBSD" http://www.usenix.org/events/usenix02/tech/freenix/full_papers/watanabe/watanabe.ps [9] "ACPI in Linux" https://www.kernel.org/doc/ols/2005/ols2005v1-pages-59-76.pdf That at least hints that ACPI.sys would have to deal with the quirks in various released computer hardware (some kind of table passed by the BIOS). And you also happen to know, that the BIOS emulation in virtual machine hosting, is a "shell" of a BIOS. The implementation is incomplete. Just yesterday I got a taste of this while installing Windows 7 in a VM, to take pictures. The legacy BIOS install worked OK, but when I switched on UEFI in the VM, the install disc basically crashed. And that's the interaction with an incomplete UEFI design. When I switched to physical hardware (4930K), the UEFI install sequence completed with no problem at all. That's an actual frictional area on all OSes. When you buy a Lemon Laptop with bad AML code in it, you are constantly dealing with shit issues like that. Usually, the laptop company did not make the laptop themselves, they got it from an ODM, and the ODM does not provide continuing maintenance contract. The OEM is supposed to provide maintenance to end customers. Maybe in a Linux thread, you would see a reference to "you should install CoreBoot" when it looks like the laptop has bad code in it. It means that some amount of "quirks code" would be in ACPI.sys. And in a VM with an incomplete (and *never* gets fixed) UEFI, there is always the possibility of a bad ending. The people who write hosting software, they only work on their skeletal UEFI code, until "something booted, lets go for lunch". So while we could have a discussion about complexity, this is an area with a "history", and nobody is immune to getting rough treatment. It's pretty hard to predict in advance, what products have bad code in them, until someone among end users tests the hardware. Who knows, maybe the article would be less eventful, if it contained details, instances, A vs B, so we can see what percentage of users might be affected. Paul
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-27 22:03 +0000 |
| Message-ID | <vs4i0d$179rs$1@dont-email.me> |
| In reply to | #16688 |
On Sat, 1 Feb 2025 21:55:15 -0000 (UTC), I wrote: > Not the first time Windows has had this sort of trouble! It has become > a regular occurrence the past few years. And still not fixed. <https://www.zdnet.com/article/10-pesky-windows-11-24h2-bugs-still-haunting-pcs-despite-several-patches/>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-04-09 00:15 +0000 |
| Message-ID | <vt4e79$3c3q3$1@dont-email.me> |
| In reply to | #16688 |
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. This is happening so often now that it should be completely yawnworthy; the news should be when it *doesn’t* happen. Except that too many Dimdows users still seem to believe that Microsoft produces a quality product or something, so they still get continually surprised when Microsoft makes their machines malfunction <https://www.zdnet.com/article/windows-11-24h2-is-crashing-on-many-pcs-due-to-conflict-with-security-driver/>.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | alt.comp.os.windows-11
csiph-web