Why is Android text such a buggy mess?

Why is Android text handling such a buggy mess?

Because it is built on three layers of inaccurately-parsed encodings.

“Standards and wonderful – so many to choose from!”

Plain text

First came plain text to emulate and automate the typewriter.

So we had ASCII printable characters 32 to 127, beneath which were encoded via control codes to command typewriter actions to move the “paper” around.

Critically, 10 rolled paper down a line, while 13 returned the print position to the start of the line.

At this point, plain text went tribal; some expected a normal carriage return to do 13 only, others though it cheaper for 13 to imply a full 13, 10 (or is that 10, 13) sequence.

This UNIX vs. DOS squabble screws up text to this day.

Rich text

After emulating the humble typewriter, word processors privatized attempts to encode the full printing press. Rich Text Format was an early attempted standard, the way XML-based open alternatives [1] to MS Word may do today, while the PostScript printer control language morphed into PDF, the de facto standard to preserve DTP layout as editable text.

So far, so messy - but wait, it’s about to get worse.

To embrace the world’s glyphs beyond US/UK English, character size doubled from 8-bit bytes to 16-bit Unicode characters.

That in itself added a new spin to tribalized ASCII vs. ANSI vs. IBM vs. bits lost to transmission overheads. Let’s skip the quagmire of code pages, MIME encodings, 8-bit extensions for now (ideally, forever)...

ASCII defined 7 bits, with one bit of a byte (first or last end? pick your tribe) free for other use. But communications needed more bits that either had to be stolen from characters, or padded in such that 10 communication bits carried a character or control code.

Typically, these added communication control bits meant Parity, Escape, etc. (I can’t recall the details, dial-up notworking modems were so long ago and therapy has helped forget the horror)

So… there’s all that - but that was before HTML Hell.

HTML

HTML said; “forget rigorous formatting and DTP typesetting, let’s cheapen and enshittify that to simply pouring enriched text into whatever container the display device makes available”.

Not a bad idea in itself, but screwed up by three deep problems.

First, it inherited the “one lump or two” 10, 13, 10+13, 13+10 Carriage Return squabble, and to that, added a cavalier disregard for white space.

Spaces, tabs and line breaks get stripped and simplified to whatever deranged mess the parsing code deems appropriate. Program-to-blog has been a nightmare ever since.

Second, Gates’ Windows 98 “everything is a web page” mania that spread HTML into CHM Help files and HTT Folder Views, coincided with the big ‘oops’ of OOP - which created the exploitable mess we endure today.

Object Oriented Programming meant that everything was to be treated as an Object, with Properties (hidden internal variable) and Methods (code interfaces to expose variables… and ‘do stuff’).

So what was harmless readable text became a script-encrusted code risk… by design.

Third, “RTF’s Revenge” was added to the mix.

While HTML dumbed down text layout, Markup was added as a way to candy-up Comments and bloggery in general. This supported *bold*, /italics/, _underlining_ and to provide an antidote to proportional fonts, so that spaces to align columns could finally work like a real typewriter… but why bother, when HTML will screw that up anyway, unless it understands the ‘display as code’ directive.

All this in the hope some formatting bling will reduce ENRAGED ALLCAPS SCREAMING in Comments; don’t you know ALlCAPS should only be used to make EULAs unpalatable in tiny scroll-to-death frames?

So:

We now have three levels of interlocking syntax to parse; plain text control codes and escape sequences, HTML, and Markup. This is further polluted via Word behavior, e.g. “smart quotes”, should ‘text’ be pushed through .doc(x) rather than the Open word processor ODF file format that nothing in the ‘real’ (commercialized) world seems to use.

Can AI Help?

I submit to UI pressure and chat to Gemini, who understands the problem but cannot fix it, thus failing the performance evaluation part of the interview.

We chat, and at the end I ask for a transcript to paste from Google’s AI, through Google’s Android clipboard, into Google’s Docs App to store on Google’s Drive so I can FINALLY download ‘my’ chat back to my Android phone, so I can get it off the phone as a file to my PC via USB to pretend my content hasn’t been sucked into the Cloud.

The result is a total folkup. Fails to Copy to clipboard. Fails to Paste into Docs. Does not Select All, only some stuff. No alerts or errors of course, so things may look as if they worked, only to find you only have the last AI response of an hour-long 10-prompt Chat.

AND THEY WONDER WHY WE SCREAM IN ALLCAPS. Do you have an emoji for ‘tears of frustration and retching’? I do... &-Q

PS: [1] I asked CoPilot of ODF was based on XML, and it replied:

Not based on XML

OpenDocument Format (ODF) is not based on XML. ODF is an open file format for word processing documents, spreadsheets, presentations, and graphics, developed with the aim of providing an open, XML-based file format specification for office applications. It was based on the Sun Microsystems specification for OpenOffice.org  XML and is published as an ISO/IEC international standard ISO/IEC 26300 – Open Document Format for Office Applications (OpenDocument). 

So... it’s not based on XML, because it’s developed to provide an XML-based file format.

In other news, this chunk of AI-generated text line-breaks in the middle of words when pasted into this post (via LibreOffice Writer), as every “space” character is a no-break-space character, using a different underlying character code that looks the same (hello, homoglyph exploits) 

KB5063878: Too many NTFS Extents?

Still thinking about KB5063878 (when you get to remember a KB number, it's usually a bad one) and several things in the code stack may apply; Device Encryption, Ring -2, bigLITTLE cores and threads, file system resource depletion, motherboard and device firmware, processor microcode, motherboard chipset, and those elusive "Hardware Error" items that turn up in Reliability.

Disable Sandbox?

This recent article holds a clue, if you scroll down about a third way down, and I paste: 

“I myself was able to recreate the same initial error I got while copying the 151G file. Not only that, but the epic fail originated a WHEA hardware error in the event viewer related to the PCIe controller, which eventually forced me to restart. I then disabled sandbox, uninstalled the update, and the file copied just fine without a hitch… no errors, no freezes, no hangs.”

“I have a Crucial T710 2T, and I also suffered a glitch. Not as serious, but nevertheless, a glitch. I tried transferring a 151G file; it failed, and it lingered in my SSD as a ‘ghost’ file. I could not delete it, access it, or anything. After 3 attempts, I was able to delete it via Safe Boot Minimal,” another tester told Windows Latest.

After that, the article blandly states...

We don’t know how some people have a botched-up SSD after the recent Windows updates, but it appears to affect a very small number of users, and unless Microsoft finds something in telemetry data, we’ll never know what really happened.

No, it's not OK to shrug off data and storage loss as JOOTT (Just One Of Those Things), even if affecting "a very small number of users".  

Good to know that disabling Sandbox may be a workaround, and a lot cleaner than "just" trying to uninstall the face-hugging KB, where disabling the Sandbox may be required before this will work beyond an error and failure to uninstall.

Dead runtimes don't talk

Forget telemetry, it can't tell you anything about the most significant failures that kill the runtime, if not the entire system.  A bullet through the brain means you can't even log "Something went wrong"; don't get distracted by the tyranny of the measurable!

Reliability: Hardware Error

Part of the support ritual is to check Reliability, a useful feature prototyped in Vista and maturing somewhat thereafter, as a manageable tap into the fire-hose of Event Spewer.

There, I often see "Hardware error" in systems that are otherwise fine, with nothing amiss on DISM and SFC do-it-for-me code fixers.  There are no further details for these entries, and so far my limited efforts to link them to Event Viewer items has not shed a light.  Perhaps they are related to GPU glitches, or something else too deep in the hardware, such as... PCIe.

Ring -2

I can't find links for this, or recall the name of the subsystem involved, but I remember what I read; that a deep processor ring -2 mode is how "BIOS" presents USB keyboard and mouse to software as if they were PS/2, and by implication, possibly legacy hardware emulation in general.

In this mode, regular CPU execution (including kernel Ring 0) is paused while the Ring -2 code does its thing.  Any bugs here are likely to hard-hang the system, but could delay return to the point that time-sensitive code may time out or fail.  This code is so deep under the kernel carpet, perhaps Windows can only report "Hardware error"?

Under-the-rug stuff like this, or "remote admin" opportunities, are a great place for malware to dabble.

Current favorite: NTFS Extents

We know not to defrag SSDs, as that "just moves the junk around" and hammers the flash memory cells' limited write life; it's better to ask the SSD firmware to Trim, and hope it will eventually do so.  

Keeping track of where the file system thinks things are, and where the SSD firmware chooses to (eventually) write them, is the black art of the SSD firmware, and likely a big reason why SSDs cost more than the bare flash memory sold as camera cards and USB flash drives.  There's very likely to be resource limitations and opportunities for things to go wrong in this space, which may be why Phison found themselves in the cross-hairs after KB5063878 brought our new crisis du jour.

Upstairs in the NTFS, there's a known resource depletion risk; cluster chaining info "Extents".  Whereas FATxx dedicates slabs of pre-booked space for cluster chaining info (i.e. which storage block is next after reading the current one), NTFS stores the start of each run of contiguous clusters, and presumably how long the chain will be before the next extent is to continue the chain.

This avoids the scalability impact of FATxx File Allocation Tables, at the risk of adding the "lie to me" meta-bugs of "thin provisioning", e.g. where assumed compression, sparse files etc. fail to actually fit within available space.  There's also a lot of hop, skip and jump when MFT and other files have to extended to arbitrary fragments in the storage map, inviting further resource depletions and errors elsewhere, boosting write amplification, and widening critical periods while our digital Superman is poised mid-leap between skyscrapers.

The mystery is then not why things go wrong during massive file ops on a busy NTFS that has never been defragged, but why this is only rearing its head after KB5063878?  

• What code has KB5063878 changed?  
• Is it specific to the Sandbox subsystem?  
• Is it affected by Intel's bigLITTLE mix of "real" and "eco" cores, and how Windows assigns threads to these? 
• Does it happen less if stealth Device Encryption is not imposed?  
• Does it still happen when offline, excluding incoming pokes?  
• Does it still happen if all Power Management is disabled and flattened, including Modern Connected Standby and network "magic packet" wakes?  
• Is it related to any particular hardware or firmware, aside from SSD controllers?  
• Does it happen to low-spec SSDs, eMMCs and hard drives, or over SATA or USB?

These may be the next set of questions to test, now that we may have repro(ducability) at last.

KB5063878 Bug: Gotcha!!

I think I've figured out the data-killing KB5063878 bug; it's when UAC tangles with UI-less activities, as described in this report.  Throws back to Vista's birth pains, when attempting add back lost immutability to the many-to-many relationship between things that happen, to what should not be allowed  :-)

The report speaks of unexpected UAC prompts that now pop up due to changes added by KB5063878.  

If that collides with last month's changes to UI-less "pre-Windows" code, e.g. before BCD is processed to menu OSLoaders (or blunder into {default}), or when WinRE boots instead, or when a "mini-Windows" is applying deep code changes before Windows loads, then you'll never see an error message, let alone UAC prompt to which the user can respond.  

This is vendor-knows-best territory, locking out users and administrators alike.

Now if those changes were attempting to change partitioning, e.g. to shrink C: for space to be assigned to a new WinRE Recovery partition, then things could get messy - especially in a multi-threaded environment, and/or failure of the "black box" of steps to be properly atomic.  

For example, imagine if one part of the process is allowed to message updated partition info to other threads, but another part of the process is blocked from actually applying those changes, then the runtime hopefully will screw up and crash out of functioning before it writes raw data to the wrong storage addresses, trashing file systems and/or partitions.  If less lucky, such writes may trash these structures, so the storage is latched into a corrupted state.

So, is an apparent automatic recovery on reboot, actually safe?  Well, if NTFS C: is foreshortened, everything may still appear valid and work.  If the runtime crashes out, then the "dirty bit" should remain set, prompting the next boot's AutoChk to "kill, bury, deny" the file system's partition-end mismatch, "fixing" it to something at least valid for future file system operations. 

The user may or may not see an AutoChk prompt to press a key to skip checking drive C:, but with fast-enough SSDs and the trend to hide details from users ("don'tcha wurry your pretty littul haid, Sue-Ellen, ever'thing's gonna be fine-just-fine"), perhaps that will be hidden, too.

This assumes Fast Startup doesn't just resume the doomed runtime and botch everything not already botched thus far, but that's likely to have been disabled for the next boot by some sort of "update in progress, boot properly, run this OSLoader instead" or similar logic.

Anyway, I think that is where I'd dig next, if trying to fix this mess, rather than just claiming "not my dog" after testing to clear a path to legally disclaim responsibility.

Why does bulk testing miss this?

Previous post explains that; bug may only arise when the full set of real-world conditions apply.  Simply trashing an SSD controller with bulk writes from a KB5063878-updated Win11 won't do it, and neither may a virginal Win11 24H2 update to KB5063878 do it, if bulk writes don't happen at a time to overlap other factors that may not be present, etc.

Why only with bulk operations?

There may be race conditions involving various levels of OS and component cache managements that arise only in the context of cache saturation and flush periods extending beyond sate time-outs or blind wait periods.  There may also be interplay with Delayed Start and Scheduled Tasks, especially when certain OEMs trigger underfootware to run every few minutes.

Vendor disclosure attempted

I've alerted Microsoft via Feedback Hub, and my ex-MVP colleagues via private email list, in case they don't experience the same lightbulb effect I did, when reading the "feed seed" article linked above.

KB5063878 Storage Corruption: External Factors?

Following up on reports and post-test denials of August Cumulative + SSU KB5063878 corrupting and possibly destroying storage when under a 50G+ bulk operation load, some likely scenarios come to mind, that may be missed during artificial accelerated testing sessions.

The initial focus was on SSDs based on Phison controllers, prompting Phison to test and exclude their controllers as a cause of the problem, while recommending heat sinks to protect SSDs against load-related failures.  Subsequent reports suggest other SSDs, and even hard drives, can also be affected.

Accelerated testing?

Phison claims 4,500 cumulative testing hours across the drives reported as potentially impacted and conducted over 2,200 test cycles, which would be 187 days of testing if done on a single device.  Testing 1,000 devices in parallel would reduce testing clock time to 4.5 hours per device, each iterating to a bit over 2 test cycles per device.  You can shift the numbers around, e.g. 100 devices etc. limited by the number of clock days since the problems were first reported - but it's unlikely testing would have been real-world, i.e. based on individually-installed Windows 11 with a wide range of co-installed software, etc.

From Phison's perspective, all those software variables are irrelevant; as long as the hardware itself can be shown to work, it's some other vendors' problem if it's a software thing.  In any case, attention shifts off Phison, and hardware specifics, once reports of other storage devices are considered.  This spectrum of affected devices also suggests this isn't limited to overheating hi-performance SSDs.

The MemTest86 experience

A familiar type of artificial accelerated testing is MemTest86, in search of "bad RAM", but also as proof of hardware ability to not crash, power off, reset or lock up over a "long enough" clock-time period.  I've done this for decades of PC builds, troubleshooting, laptop pre-acceptance testing, etc. and have settled on 24 hours as the shortest 99%-certain test period.  

I've seen one case where the first error showed up at around 25 hours, and one where the first error showed up in an over-weekend 100+hour unattended test run.  In both cases, the first error was the only error, and neither system latched into a persistent error state thereafter.

Shorter test periods, e.g. 18 hours, would be more convenient, e.g. allowing in and out turnaround within the same time of day, but I saw too many first-errors within the 18 to 24 hour period.  Clearly, this makes the typical default 4-pass loops completing in an hour or two, unfit to be trusted as exclusionary.

Even so, "burn-in" testing with MemTest86 is not real-world, as it exercises a very limited subset of what the tested hardware has to do.  It doesn't test GPU or DMA access to RAM, localized heat related to different kinds of CPU activity, and obviously anything to do with storage or other components.

Cache and Race Conditions

Microsoft's test methods are reportedly thorough, but not detailed, and are likely also to involve accelerated automated test methods that may be as narrow in their way, as is MemTest86's testing of processor and RAM.  

Variables may include how soon after Windows 11 boot the tests are started, bearing in mind how "underfootware" can be triggered at arbitrary times - consider Delayed Start, that seeks to pretend Windows boots faster than it actually completes all inits and startups; application pre-loading that seeks to pretend applications aren't slow, but your Windows and hardware may be, stuff triggered via Scheduled Tasks, and hidden ServiceWorkers that may be triggered remotely.

Bulk operations will saturate caches, possibly revealing lower raw direct transfer speeds.  These caches will be full at the "end" of file operations, needing time to spool out to where the data has already pretended to have been written... can you guess the problems that may happen next?

Modern PCs are more like networks of DOS-sized systems.  A modern CPU has enough cache RAM to run a Windows 9x installation, while firmware logic within black-box devices such as hard and solid-state "disk" storage is at least a 20th-century DOS or BIOS.

Computational scale

There's a certain size of code that we may expect to be bug-free, at least if kept fully encapsulated; I'd guess somewhere between a DOS in a 1M memory map, and a Win9x in 4M or so.  

Beyond that, things rapidly bog down such that attempts to complete a project will fail and have to be abandoned (WinAmp 3, Netscape, the original Microsoft Edge, even Windows 11 24H2's attempts to become acceptably reliable before 25H2 is due), or it will become a bunch of separate boxes of code linked together, as is the case with modern PC hardware subsystems and "web apps", or a thin layer of new top-soil over a decades-old mass of existing code, e.g. just about every OS other than Windows that is based on ancient *NIX, or how Windows 95 had to re-use solid 16-bit Assembly code to dance within 4M of RAM.

Whether it's a team of human workers, or a map of code black-boxes, new challenges and inefficiencies arise in how these interact.  Add race conditions that arise when critical periods shift in phase, and exclusionary testing becomes a really hard problem that may defy automation.

So yes; Phison may prove thier controllers are OK, and Microsoft may conclude KB5063878 is OK, but neither may satisfy our need to be sure the KB will be safe on our particular systems, for reasons that both vendors can blow off as "not our problem".  And what happens with this KB, may happen again with others, so we need a systematic fix for future scenarios.

Power (mis-)management

One very likely scenario involves power management, when power to a subsystem is cut before that subsystem has actually done the work that it claimed to have finished.

Consider an external USB hard drive and "Safe To Remove".  To be aware that an external device is connected, it helps to see the relevant icon in the SysTray (sorry, "notification area"), but it's hidden under the More... by default.  To click on it in order to initiate a "Safe To Remove" data flush to storage, you have to see the icon, which is instead hidden on the assumption you only need to see it when it has something to "notify" you.  So far, so... not good.

Let's say you do remember you have an external plugged in and you do click the icon, then await the feedback that the device is safe to remove, or should not be removed because it is still in use.  If you have Focus Assist enabled, you will never see that feedback, because that Notification is not considered sufficiently important, even though it's a part of your Focus that is to be Assisted.  So, how are you supposed to know you can safely unplug the storage device?

We're told this "doesn't matter", but I've seen enough corrupted external storage to know that it does.  The damage may be hidden by the "kill, bury, deny" logic of NTFS transaction rollback, AutoChk and ChkDsk, but you're still losing data that you expected to have been written to storage.

Finally, listen to how external USB hard drives often burble on after the "Safe To Remove" notification pops up.  Has the drive firmware really flushed its cache to platters, or did it lie when it told the parent subsystem that it had finished all pending writes?  Which drives do you think will look faster when tested by hardware reviewers, and feel faster to users (at least while all appears to be well)?

The same glitches that can corrupt external drives, can lose data if a component is expected to be idle, having completed all pending tasks, thus safe to be powered off.

Fast Startup and partition changes

So far, we've considered loss of pending write operations when caches take too long to flush, and/or when subsystems are prematurely disconnected and/or powered off - but there's another aspect to KB5063878 that could trash file systems and partitioning, if factors excluded from automated and/or accelerated testing were to pop up in real-world scenarios as occasional race conditions.

By duhfault, Windows 11 fakes "shutdown" as part of the Fast Startup "feature".  Specifically, instead of doing a true shutdown (which has its own risks when wait time is shorter than time needed to complete tasks), Fast Startup hibernates the system state after all users are logged out.  

The next startup then appears to be faster, because the previous runtime state is Resumed, persisting any runtime glitches, resource depletions, etc.  More to the point, all sorts of sanity-checks and initializations are bypassed, on the assumption that the way things were at (fake) "shutdown", are still holding true when the runtime session is resumed.

So, if an external USB drive was disconnected while the system was "shut down", anything that was still to be saved within the hibernated runtime, will be lost.  And if any changes to partitioning were made in between the (fake) "shutdown" and "startup", then the continued runtime will be unaware, and will write raw storage data blocks to where the partitions and file systems... used to be.

It was this that alerted me to the dangers of "Fast Startup", after booting USB partitioning tools to resize and shift partitions while the system was "shut down".  The next Windows boot then promptly destroyed C: and other partitions, by overwriting the raw areas of storage where these partitions and their file systems were defined.  Fast Startup is Not Your Friend.

The failure pattern I saw when Fast Startup missed out-of-runtime partition changes, is similar to that reported for KB5063878; drives "stop responding" and/or vanishing, once write operations no longer continue using stale and invalid in-memory assumptions on partition and file system raw locations, which may only happen once those raw storage blocks are lost from cache and have to be reloaded, only to find the structures trashed by preceding mis-directed writes.

The next boot may or may not silently "fix" things, either via AutoChk file system "repair", or by WinRE's startup recovery, or even the new "call home and auto-fix" facility that may or may not yet be in play.  These "fixes" may cover up the damage and data loss, but is that enough for you?

KB5063878 and WinRE

KB5063878 does more than change code within Windows; it also changes WinRE.  The previous monthly Cumulative also changed pre-OS code, such as the mini-Windows that hosts the installer for Windows, and/or that which processes the BCD before the decision to boot Windows is taken, as well as the Servicing Stack.  These deeper changes make it harder to uninstall the KB, as the code that manages the uninstallation is itself subject to changes imposed by the KB being uninstalled!

When setting up a new laptop already running 24H2, I noted a 850M Recovery partition as expected.  From within Windows, I shrunk C: to 150G, creating a new D: partition to fill the remaining space on the 500G SSD up to the 850M Recovery and vendor-specific 260M MyAsus partitions at the "end".

Windows Update installed only one Cumulative update, being KB5063878, along with the usual Defender and Dot Net updates.  This may or may not have included changes added by the July 2025 Cumulative, thus creating a "YMMV" for those who had already installed the July Cumulative separately, to become the baseline to which uninstalling KB5063878 would return.

So right there, we have a divergence that would probably be missed by automated testing my Microsoft and Phison, as they seek to disclaim responsibility for reported problems.

After these updates, the space previously occupied by the 850M Recovery partition was left empty, while C: was now smaller, with space between C: and D: being allocated to a new 950M Recovery partition.  It's unclear as to when these partitioning changes were applied, and there may be opportunities for these changes to be mis-merged with bulk file operations, lost to un-flushed caches in prematurely disconnected subsystems and/or hardware devices, tangled up with Modern Connected Standby and/or fake "Shutdown" of Fast Startup, etc.  

"Many a slip between cup and the lip", as they say.  These are the specific scenarios I'd set out to test, if I had the resources to do so - KB5063878 and/or Phison may not be "to blame" when considered in isolation, but nothing exists in isolation in today's sprawling, over-connected infosphere.

What next?

Microsoft is still pushing KB5063878 while still investigating reports of significant data loss.

So, as we can't trust vendors to block dangerous updates from the server side, we need ways to block specific updates before they install, especially when these are too entangled to be uninstalled once injected into the system.

And yes, we can expect scenarios where a malicious FUD campaign may socially-engineer users into delaying updates, to hold the door open to exploit code defects the updates would have fixed.

As it is, this risk is greater when we have to advise users to Pause all updates altogether, as the only way to avoid a specific update reported to be toxic.

Firefox 132.0 Breaks Netflix, 132.0.1 Still Broken?

Firefox 132.0 breaks Netflix at the point content should start streaming, with Netflix error code F7361-1253-806E0005, as tested on Windows 10 22H2, Firefox 32-bit on 64-bit Windows.  

This is positioned as a DRM issue (no surprise, as DRM is code designed to break playback), said to be fixed in Firefox 132.0.1, but I'm still seeing the same failure pattern.

Well, bugs like this can happen; that's Strike One - but wait, this reveals two deeper issues...

1: No way to undo a toxic update

If your code needs to be "updated" (i.e. fixed) so often that automatic updates are preferred (at least by the vendor), then you need to be humble about such updates, in case they create new problems.  That means the ability to undo an update that may be messing things up - but I can't find that facility in Firefox; Strike Two. 

2: Update breaks data?

Fortunately, I kept a full offline installer for the previous version of Firefox, to undo whatever the latest update may have broken.  I could install that over the newer code base as an "upgrade"; no warnings about version revision or side effects.  But when Firefox started after this version fall-back, it warned: "Using an older version of Firefox can corrupt ... an existing Firefox profile.  To protect your information, create a new profile for this version of Firefox".  

Only choices from that modal dialog box were Exit or Create New Profile.  I certainly did not want to botch my profile by starting a new one that might lose all "my stuff", so chose to Exit. Strike Three.

Now, this worrying if this is not specific to 132.0, i.e. if Mozilla thinks it's OK to routinely botch user profiles and "just" spawn new ones, whenever one tries to undo a toxic update.  Changing data compatibility is non-trivial, should seldom happen, and be well-tested and documented if it does.  

A bland "well, we may botch your data, so let us 'protect' you as the only way to run the program, or go away" doesn't cut it, especially with no further details on what would happen if one "just" starts a new profile.  That approach amounts to "Trsut us, we're a software vendor" when the competence layer of the trust stack is already broken by the toxic update.

I re-installed broken 132.0, used Edge instead, watched for a bug-fix version, saw 132.0.1, downloaded and installed that, and lo!  Netflix still broken.  I presume the Netflix issue will eventually be fixed, or maybe it's something specific to my setup, making "Strike One" a "No Ball".  But now we've caught the "man behind the curtain" on Strikes Two and Three, not sure if I'll go back for more of the same.

Black but Working BCD Boot Menu; A Fix

In the age of UEFI PCs running Windows 10 and later, you may find a situation where the BCD Boot Menu is invisible as a black screen, but still works if navigated from the keyboard.  Enter will end the timeout, arrow keys will change the selection, etc.

This problem pattern is not the same as others that are more commonly described online; the menu that does not appear because it is bypassed (Fast Start, Timeout = 0, etc.) or other boot issues that may use a different BCD, bypass the BCD altogether, boot the wrong storage device, hang or crash before reaching UEFI boot due to hardware issues, etc.  

Recently I saw my 3rd case of this problem pattern, having described the first and second cases previously.  In all three cases, the boot menu works just fine, but can't be seen because the screen (or all screens, if multiple connected) stay black.  There's signal to the screen that the monitor accepts, rather than suspending due to incompatibility, but everything is black, with no visible mouse pointer or text-mode blinking cursor.

One fix is to disable the graphics adapter in Windows Device Manager, forcing Windows to use the Microsoft Basic Adapter driver instead of the driver specific to the system's GPU (as detected by Windows).  This proves this to be a "kick away the ladder" metabug, where something that should affect only Windows (the choice of graphics driver) affects the underlying UEFI system level beneath, with the potential to make it impossible to boot Windows to undo the damage.

Another fix for older systems, is to avoid UEFI in favor of CSM "BIOS", but this option is no longer available with Class 3 UEFI, and is increasingly untenable as Windows and hardware evolves.

Today's fix is to force the "legacy" type of BCD Boot Menu via a BCDEdit setting, specifically...

bcdedit /set "{current}" bootmenupolicy legacy

 ...where "{Current}" can be replaced with "{Default}" or more specific OSLoader GUIDs, as displayed explicitly via the /V option in BCDEdit. The visible impact is a text-mode white on black boot menu instead of the blue graphic boot menu; also, the menu text for OSLoaders that use RAMDisk will be taken from the RAMDisk defining GUID in BCD, rather than the OSLoader's GUID.

The implications of all this are twofold. 

First, the pre-Windows UEFI boot process is affected by choice of drivers in Windows, extending to how the BCD registry hive is interpreted by {bootmgr} (as seen from BCDEdit).

Second, the code that processes the BCD to display the Boot Menu has two pathways; that of the Windows 7 era Boot Menu that still works when forced via "bootmenupolicy legacy", and the newer Windows 10 era code that screws up the display when problematic drivers are in effect.

The safety implications go deeper; that an attack can be made through Windows to "brick" the system at the pre-Windows UEFI system level, such that no storage device can boot.  "Windows" device drivers should not integrate into the system as firmware "Extensions"!

Disable ALL WiFi Auto-Connect!

Windows 10 and 11 both duhfault to auto-connecting every "secure" WiFi network they can detect, relying on the absence of "remembered" key to block unintended connections. This logic is often expressed in forum threads, when folks post that they want to stop all WiFi Auto-Connect, rather than stepping on ants one at a time, or disabling the WiFi adapter.  

Even when command-line methods are offered, they all involve naming the specific WiFi network you want to "fix"; useless for control over all networks that may be discovered, other than the few you may want to actually use.

As it is, you can't access Properties for a WiFi network until it's connected, so you can't even attempt to UNcheck "yes, let's stick our fingers in the electricity socket without asking first".  Not having they key to connect may prevent unwanted connections, but also places that network beyond Settings control.  Entering a key to connect to an unwanted network may let you in to its Properties and thus ability to UNcheck "Auto-connect when in range", but now you have the risk of a "remembered" key.  Either way, you're forced to take more risk than should be the case.

Cannot connect to this network

I suspect this behavior may be a cause of the "Cannot connect to this network" problem.  In my case, I have a distant main router and a closer slave router; the slave hosts two WiFi networks, one of which is limited to Internet access only, for safer guest use.  All three WiFi networks use WPA2, but the "full access" slave router WiFi network has never had a key entered.  None of these networks are to "Auto-connect", but without the key, this setting cannot be applied to the full-access slave router network.

Sometimes (no predictable pattern) when starting a laptop close to the slave router, manually connecting the guest network will fail with a "Cannot connect..." message.  All other "secure" networks within range are found defaulted to [x] Connect Automatically, and clearing these checkboxes does not "stick".

Sometimes temporarily checking Auto-connect for the intended connection will work; other times, nothing works short of "just" restarting Windows.  The same intermittent failure pattern affects two different Win10 laptops, set up in the same way.  When connected via (unwanted) Auto-connect, clearing the Auto-connect checkbox sometimes drops the connection and the whole mess starts again.

Meta-bug

Lacking a way to set behavior of newly-spawned entities, before they are spawned, is a common meta-bug that often creates exploit opportunities.  This WiFi issue is just another instance of this meta-level bug.

Windows has become hell-bent on connecting to the Internet, from OOBE's lure of "a little WiFi here...", the constant pressure to "just" auto-sign in to an online Microsoft Account, and the duhfault behavior of all "secure" WiFi networks to auto-connect on the basis that a missing key is safety enough.

I wish Microsoft would respect the "My" in "My Computer", and at least offer solid settings to stay off networks and the Internet until this is initiated by the user!

Intel 10nm GPU Driver Blanks BCD Boot Menu

This is the second case of a brand new laptop based on Intel's 10nm 10xxGx processors, in which the Intel Display Adapter driver causes the BCD {BootMrg} menu to be invisible (black-on-black), though still working.  Here's how to demonstrate the bug:

1. Run BCDEdit from an "As Admin" Cmd or PowerShell
2. Add an OSLoader entry to BCD {BootMgr}, so BCD boot menu will be invoked
3. Set the Timeout to 15 or so
   
4. Restart system from cold, i.e. not "Fast Startup", Resume from Sleep or Hibernate, etc.
5. Rotating dots will vanish to blank black screen, where you should have seen the boot menu
6. Wait for timeout or press Enter; system will boot as expected
7. Device Manager, select Intel Display Adapter, Disable
8. Repeat from (4), menu will now appear as it should, OK
9. Device Manager, select Intel Display Adapter, Enable
10. Repeat from (4), menu will fail to be visible again

The current case is a Dell Inspiron 3593 based on i7-1065G7, whereas the first case was an Asus X509JA-i541GT based on i5-1035G1.  Both processors are 10nm but have different integrated GPUs.  Windows 10 versions 1909 (Dell original), 2004 (Asus updated) and 20H2 (Dell updated) equally affected.

Click the link words to drill down into detail, and here for a fuller description of the problem.

Don't Kick Away The Ladder

You climb a ladder onto the roof, then kick away the ladder. 
How do you safely get down to put the ladder back up so you can safely get down?

Such an obvious f-up, you wonder why I need write this post.  Like a cartoon character who runs off a cliff, panics while briefly suspended in mid-air, then inevitably plunges to a cartoon death; surely, system designers aren't that stupid?  

Examples abound, especially in the age of Class 3 UEFI that forces us to share these stupid risks. The "Extensibility" of UEFI allows code to be integrated before any OS can boot, and this code can persist into the OS runtime, so it's hard to see how this can be "more secure" when fundamentally unsafe.  Years of (U)EFI's buggy "growing up in public" makes it clear such code is insufficiently trivial to be free of exploitable bugs.  A ladder should be trivial enough to never break; flaky firmware can break systems in ways that cannot be fixed!

I'm setting up a new Dell laptop, and in the firmware setup, is an on-by-default option to allow UEFI firmware to connect to the Internet and grope for "updates", before any OS is booted from which malware could be tackled, as if vendor supply-chain attacks had not already happened.  Specifically, if attempts to boot Windows fail successively "too many times", the firmware will try to launch Dell's repair, and if that in turn fails, will try to download the repair material via the Internet.

This Dell laptop also suffers from this bug, based as it is on the same 10nm Intel processor family.  The problem applies to both the original Windows 10 1909 installation, and after this was upgraded to 20H2 as per current Media Creation Tool.  The .iso created by this tool no longer fits a standard DVDR disc, so a bootable USB stick was created instead, and the file set copied from there. 

The laptop's nice NVMe SSD can't be seen from my rescue WinPE boot discs, nor from a freshly-downloaded Kaspersky Rescue Disk; none of these can see the drive via the PCI interface.  Once again, the ladder is kicked away; crucial boot-time code should "always just work", i.e. standard trivial code baked into the firmware, not requiring "special drivers" to work.

As it is, the nature of the UEFI display bug demonstrates how a setting at the top of the ladder (Windows 10 Device Manager, enabling or disabling the Intel display adapter) kicks away the bottom of the ladder (OS-level setting affects pre-OS UEFI, such that pre-OS BCD boot menu fails to display).

Do we really have to wait for more shoes to drop?

Firefox Memory Leaks

 I use Firefox without extensions and plugins, and find it "leaks memory"; specifically, the memory footprint as seen via Win10 Ctl+Alt+Del Task Manager increases towards 2G over days of mult-tab use, whereupon the entire system slows down and becomes less responsive, while Firefox becomes as crabby as a sleepless toddler (prolly for much the same reasons).

For this reason, I use 32-bit Firefox, to limit its address range and thus impact on the rest of the system.  Going 64-bit would only "solve" the problem in the same way a bigger gas tank would "solve" a leak, i.e. delay the onset of inevitable problems.  32 bits can address a 4G range, halved to 2G for signed offset addressing as is likely for Firefox's internal memory (mis-)management.

So when I saw "CVE-2020-15254: Undefined behavior in bounded channel of crossbeam rust crate" (seriously, WTF is a "crossbeam rust crate"?), I went Aha!  And when I read "The impact on Firefox is undetermined", I went Aha! again, as in "geez Mozilla, don't you know Firefox leaks like a tennis net in a wind tunnel, haven't you even begun to wonder why?"

At the meta level, there's a familiar problem of per-instance vs. aggregate cost; since the days of DOS and Borland's program compilers, it's been "do we frequently ask the OS for small memory allocations, or do we seldom ask for large allocations and manages the details in-house?".  Do you pull cash from an ATM for each cash purchase, or do you draw once a week and manage your own wallet of cash?

Such details may be managed in-house by Firefox developers, or more it's more likely "sub-contracted out" to some 3rd-party generic code library, prolly whatever came with the source code compiler or other development tools.  As a cross-platform program, this is less likely to be handed off to the platform-specific OS; in fact, platform independence is a strong reason for in-house memory management.

Which brings us to another meta-level problem; "black box" code re-usability.  The idea is that such blocks of code should hide their internal details and only expose a limited surface that is trivial enough to rely on (if all non-trivial code has bugs, keep all crucial code trivial!) but in practice they always leak, and such leaks may be exploitable - hence the CVE number.

When Add/Remove Doesn't Remove

Technorati tags: Uninstaller, XP, bug

What do you do when you go to XP's Control Panel, Add/Remove Programs, find the software you want to remove, and the entry has no Remove button on it?

I found an answer in a forum thread, as follows...

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{Program Name}

If NoRemove is set to 1, the Remove button will be unavailable
If NoModify is set to 1, the Change button will be unavailable

Note that as the {program name} may be a CLSID, you may need to search for the product name (e.g. "Intel Audio Studio", using what you saw in Add/Remove) to locate the correct entry in which to find the relevant NoRemove setting.

Intel Audio Studio

In my case, I'd had to replace a failed Intel 945G chipset motherboard with a new Intel G33 chipset motherboard with attendant processor upgrade.  XP died on a BSoD STOP error on all boots, as expected (a self-serving product fragility that helps limit "license creep") so the next step was to "just" do a repair install... but that's another day's blogging.

The other motherboard came with Intel Audio Studio, which installs and uninstalls along with the sound drivers.  But when the motherboard changes, the old sound device vanishes from Device Manager, so you no longer have an UI from which the device (and thus drivers, and thus associated bundleware) can be removed.

Hence the problem: Add/Remove Programs has an entry for Intel Audio Studio, but that entry has no Remove button.  It "doesn't need it" (so implies the text within the entry) because it is "installed and uninstalled with the drivers".

The meta-bug behind the bug

Alun Jones said "Don't solve problems, solve classes of problems", and by meta-bugs, I mean the classes of problems behind the bugs you step on one by one.

Have you noticed how few USB-interfaced hardware vendors create driver installations that work with the Windows PnP detection, prompt, and install sequence?  Most vendors tell you to avoid that by first auto-running their installation CD or running their Setup.exe, and then plugging in the USB device only after the "drivers" are loaded.

One reason may be because the vendor wants to install a range of software that is broader than that handled by the device driver installation purpose.  And this is where the meta-bug comes in, because whereas drivers are suppressed when the device is not found, the rest of the bundled software is not.  This is what causes your Display Properties dialogs to crash when you replace your graphics card, if the old graphics card left device-specific code hooked into the Properties page.

In this case, the meta-bug caused an apparent inability to uninstall Intel Audio Studio.  With the new motherboard in place, a dialog appears on every boot to the effect that Intel Audio Studio doesn't work with the system's (different) audio, prompting my attempts to uninstall the software via Add/Remove Programs.

What is particularly annoying, is that Intel's web site has nothing I could find on this issue - either via their own site search, or combining www.intel.com with appropriate search terms in a general Internet Google search.

Three Little Pigs Build Computers

Technorati tags: Safety, Parable

If you don't like long fairy tales, skip ahead to the conclusions!

Once upon a time, there were three little pigs who set out to become building contractors.

One insisted everyone build their house on his land using only his materials, and charged too much money.  He didn't sell that many houses, and this story is not about that little pig.

One believed that people should build their own houses, and that houses should be built for free.  Many people were very interested in this, and often started building such houses, but found it too difficult and gave up, and this story is not about that little pig either.

Pig Makes Good: The Early Years

All of these pigs grew up in houses made of bricks, but this was a new planet where bricks weren't available (I did say "set out", didn't I?), so they had to make do with other materials instead.  At first, they made houses out of these materials the way their brick houses were made back home, but there were so many people wanting houses in the same place that they started joining them together in various ways.

The main pig became very successful, not only making houses for nearly everyone on the planet, but employing lots of builders to do so; soon, there wasn't a single builder who knew everything needed to build a complete house.

As more people came to the new planet, most of the big's earnings came from building hotels and blocks of flats.  They still built lots of houses, but stopped thinking about how those would be made because that wasn't where the money was, and besides, those folks will always buy their houses anyway.

Wolf Atrocities: The Response

After a while, folks started complaining that homeowners were being eaten by wolves, and the quality of houses came into question.  Wolves will be wolves, it was agreed, but surely the idea of a house is to protect one from them?

Some folks suggested building houses out of sticks instead of straw, but the pig said "we have too many pre-built walls that we already made out of straw; it would take far too long to re-do everything in sticks".

Others felt that building out of straw vs. sticks didn't matter too much, as long as you did something about the open windows and weak door hinges. 

The pig said "if you want stronger doors, speak to the Door Lock team.  What's that about 'hinges'?  We don't have a "Hinge Team", so we can't pass those suggestions anywhere.  I promise we'll make doors with even stronger locks in future! (the squeaky things at the other end of the door will stay the same, of course)"

The pig also said "we've always built with open windows, and other businesses have come to depend on them.  How are folks going to deliver goods and services if they can't climb in through the window?  Why not retire to one of the bedrooms, and lock yourself in?  If you get eaten, it's your fault, because you will insist in walking around in other rooms that aren't meant for you - you are a resident, not a chef or a barman, so you don't belong in the kitchen or living room." 

So the new houses were built with stronger locks and new bedroom doors.  And as folks still needed to eat and go to the bathroom, they'd leave the bedroom doors unlocked and get eaten while in the other rooms.

Conclusions

1.  The past can tell you only so much about the future.

If you focus on large-volume quality data from the real world while designing new products, you will design products that solve yesterday's problems while being wide open to tomorrow's new problems.

To avoid this trap, you need to brainstorm new designs with homeowners from the start, rather than present them with a near-completed beta product where the design is already cast in stone.  You also need to listen to theorists who cannot point to detailed real-world data because what they are talking about does not yet exist in the real world, and pay as much attention to these as you do to the detailed real-world feedback you get on things that already exist.

2.  Straw and sticks will never be bricks.

Know that you're forced to build with weak materials (exploitable code) and design your structures accordingly.  Any functionality may suddenly become a death trap or fire hazard, no matter what it was designed to be; so make sure such things can be amputated or walled off at a moment's notice.

3.  Airliners should not attempt aerobatics.

Know that you are human, and are building with straw and sticks.  Don't build death-defying skyscrapers that pose deliberate and unnecessary risks to homeowners.  In particular, don't build in facilities that allow arbitrary passing wolves to overpower residents in their houses, even if that is appropriate design when you are building hotels owned by wolves.

Risky tricks like DRM, product activation, linking real-time WGA to DoS payloads etc. have no business in teetering edifices built from twigs.

4.  Expose wildcard teams to new ideas.

Microsoft gets better at what they do well, while remaining poor at what they do poorly, or on issues to which they remain oblivious.  Why is this?

Partly this is from over-reliance on rich but historical data, as per my first conclusion in this list.  But it is also because their ability to develop is structured by present resource commitments.  For something they already do, there will be a product team; any idea on how to do that stuff better may reach this team, who will understand what it's about and can swiftly incorporate such feedback.

But if they've never seen the need for something, they will have never formed a team to develop it.  Any feedback on such matters will fall on dry ground; there is literally non-one there to process such material.

5.  Handle unstructured feedback.

Microsoft regularly solicits feedback via surveys etc. but once again, these measure what is measurable, rather than what's important - so the objective of "getting new ideas" remains un-met. 

Yes, it's easier to capture data gathered as responses to radio buttons, checkboxes, ordered pick lists and yes/no questions - but that limits input to what the designers of the survey had thought of already.

At the very least, every survey should end with a generic question such as: "On a scale from X to Y, how well do you think this survey covers what you feel should be surveyed?" followed by a large empty "comments" text box. 

A high dissatisfaction score should warn you that you are digging in the wrong place; the response might be to form a wild-card team and pass the dissatisfied returns to them for assessment of any free-form comments that may give a sense of where you should be digging instead.

6.  The cheapest lunch is where you haven't looked yet.

The saying "whenever I lose something, it's always in the last place I'd think to look for it!" is a truism, because once you find it, you stop looking.  In fact, "lost things" are just the least successful tail of your usual access methods.

You stop looking when you find an answer, but that doesn't mean you have the best answer - there may be better ones if you'd look a bit further.

With a mature product that still has problems, the biggest gains are most likely to be found where no-one's started looking yet - rather than improving existing strengths past the point of diminishing returns.

7.  In the land of the blind, name tags aren't useful.

The Internet is an unbounded mesh of strangers, so identity-based solutions don't apply.  Once you initiate networking, as opposed to generic Internet access (e.g. after you log into a secure site), such solutions may become useful... but even then, only if the user has a template of expectations to match whatever identity has been proven.  Even then, the process is only as robust as the twigs out of which it is built, and the Internet is a very windy place.

For this reason, I'd rate risk management as more important for malware and safety, both out on the web and within the system.  This is the barely-touched area that is most likely to provide your cheapest lunch.

8.  Who are the wolves?

All pigs become wolves in the dark. 

We are the wolves, and so are you.  There's no such thing as a special set of saintly piggies (e.g. "media content providers", "software vendors", etc.) who can be trusted with raw pork.

Meta-Bug: UI Refresh That Doesn't

Technorati tags: Bug, Meta-bug

If you can read this post, you're lucky, because I think I've just edited this blog's framework into the ground!

The case was a meta-bug (i.e. a conceptual bug that underlies other bugs).  I was trying to add a poll to the blog, which was rejected due to some date format thing.  So; is "07/07/19" yy/mm/dd or mm/yy/dd?  Do my preferences for dd/mm/yy(yy) have any bearing on what the error report shows?  None of that is the bug, by the way; just bad error message design - in fact, it may be that the new Poll thing is just plain broken.

Here's the bug: If I try a different date that is also "wrong", will I be able to visually tell the difference between nothing happening when I click Save, and getting the exact same error message invisibly "refreshed" over the old one?  What happens if I ASSume that "nothing happened" and I machine-gun the dumb-ass Save button 100 times out of frustration?

Er... I wish the last question was rhetorical, heh.  I've just closed the browser window that has been "Saving..." my blog for the last unfeasibly large number of minutes.

So if you're looking at a blog layout that is currently less than fully-assed, with a dead poll that was "fished" before it was born, then you know why.

Bah!  User failure strikes again...