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) 

Windows 11 23H2 EOL Nov 2025

By now, we all know Windows 10 ends support 14 October 2025, creating a stampede to Windows 11 ("nice computer you have there, would be a shame if it got exploited").

What's less well known, is that Windows 11 23H3 ends support less than one month later, on 11 November 2025.

Both the used and "new" PC and laptop market still has "Windows 11" systems that are not compatible with the new 24H2 baseline, so check this before buying a "too good to be true" discounted deal.  

Search the web for "Is {full processor model} compatible with Windows 11?" and see what the AI says; then search again for "Is {full processor model} compatible with Windows 11 24H2?" and see if YMMV.  For example, the Intel 8xxx generation are listed as compatible with Windows 11, but are not on the list for Windows 11 24H2.  

November 2025 will see the release of 25H2 as the new "current" version of Windows 11, making 24H2 the "old but still supported" version.  Both are based on the same code base that was so buggy for months, before settling down to be "the most reliable Windows 11 version yet" around July 2025 or so, after which new code updates within "the same" version added new bugs.

Microsoft's approach to updates has changed this year, stealthing significant deep code changes within "the same" version, along with new features that are hidden from use.  When 25H2 arrives as a small "enablement" package, it turns on the new features already delivered, so they can be used.  This may bring new bugs to light, but that's more likely to be accepted as part of a "new version of Windows".

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 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.

Microsoft: Stop Pushing KB5063878 "Death Patch"

Please, Microsoft; place a "hold" on KB5063878 August Cumulative Update for Windows 11, until it can be trusted not to destroy storage devices, installations and data.

We're encouraged to trust vendors to know best, including blocking updates known to cause trouble and/or suffer from compatibility issues.  Microsoft knows that KB5063878 corrupts storage (although this is not documented here), including destroying storage hardware, yet even after testing indicated the issue affects more than just a few particular SSDs, but also hard drives as well, it still pushed this update yesterday (28 August 2025) to a brand new laptop.

Yes, the issue may "only affect a few systems" and only when doing bulk file transfers of 50G+, but that's exactly what a new system will do straight after mandatory updates; bulk transfer data onto the new system from the one it is to replace.  This scenario is even more likely at a time Microsoft is telling us to replace perfectly capable Windows 10 systems so we can "be supported" on Windows 11 - even as that "support" involves pushing known-lethal updates "to keep us more secure".

As it is, KB5063878 is a nasty face-hugger beast, including as it does a Servicing Stack Update as well as changes to code outside Windows itself; since the previous month's Cumulative changed WinRE, thus the automatic recovery system for failed boot, and likely WinPE, perhaps pre-BCD and UEFI, who knows?  Now that "BIOS" is "extensible", toxic OS drivers can permeate that space via UEFI drivers, as already afflicting the BCD Boot Menu.

So, it's not as simple as uninstalling the update, and/or blocking it by hiding it from future Windows Update activity.  Uninstalling the update may fail with errors, requiring a more elaborate approach via DISM, possibly disabling WinRE and Sandbox first, etc.  Advice then suggests Pausing updates in the hope that Microsoft fixes what is quite a deep change to the code base, in the hope that this happens before the maximum allowed Pause time expires, that rushed fixes don't create new issues, and that exploits don't start hitting whatever KB5063878 may have fixed while we wait.

If we cannot trust Microsoft to place a "hold" on updates that can destroy data, installations and hardware - surely the biggest impact possible - then we need a way to block particular updates before they get rammed into the system.  We should not have to first accept the update before uninstalling and blocking it, nor should we have to Pause updates altogether, just to avoid a crisis du jour.

Windows 10 EOL is not about Windows 11, it's about OneDrive "Backup"

The end of Windows 10 support is not about Windows 11; it's about stampeding everyone on to OneDrive cloud storage - either as a pure money-maker, and/or to extend geopolitical reach.

Microsoft has to patch Windows 10 anyway

Consider: If Windows 10 will have code repair updates developed against exploitability for those who choose to buy extended support for three years, then that work has to be done anyway.  Extending update delivery to systems is the same cost, whether they are on Windows 10 or 11.  A wider pool of Windows 10 users may mean more niche testing, but also means more involuntary testers, making it easier and quicker to find out what needs fixing next.  

In the worst-case scenario, a massive exploitable base of unpatched Windows 10 systems could pose risk to everything connected to the Internet, which may compel Microsoft to "support" (fix) all those systems.

Folks aren't joyously flooding to Windows 11, throughout years of ongoing development, right up to these final days before Windows 10 (and Windows 11 23H2 and older) go out of support.  Many systems are disqualified due to TPM 2.0 and other requirements, but others are simply user refusal, as well as the inertia of large managed networks.  

In response, Microsoft offers Extend Security Updates (ESU) programs to both professional networks administrators and consumers.  The "pro network" crowd have to pay, but a new "free" option has been added for consumers that looks too good to be true... and is.

Baked-in ransomware

If you allow the Windows Out Of Box Experience (OOBE) to lead you by the nose ("a little WiFi here, a little sign-in there"), then this is what happens:

• you sign in to an online Microsoft Account
• your internal storage is encrypted without your knowledge or consent
• the encryption key is available only from your online Microsoft Account
• all appears to work as normal, so you don't get the key you didn't know you'd need

Now if that smells like a ransomware attack, that's because it is exactly that.  Microsoft doesn't extort money upfront, payment doesn't involve complicated crypto currencies, and it's not about payment anyway; it's about the option to deny access, either for breach of the vendor's private law (the EUL"A" that no-one reads) or at the behest of US policy, such that sanctions can apply to data as well as money.

Data survivability is now brittle, as various local situations can trigger a demand for the key:

• you need to boot into Safe Mode
• you need to access your storage from a different system
• something glitches the TPM, e.g. a firmware ("BIOS") update

There may be server-side issues too, e.g. your online account is hacked, or deleted by the vendor, or you follow advice to discard the account to use a Local account instead, or your account hasn't been signed in for "too long", or the vendor or US policy applies a "data sanction" on you.

Theft-to-cloud as "backup"

Backup is actually a hard problem; the aim is to keep all wanted data changes, while excluding all unwanted changes - a mix of sheep and goats, needles in the haystack.  Strategies vary, but always involve multiple copies of data such that if one is afflicted, the other is available to restore.

Sync is the opposite of backup; if anything bad happens on any one system, that unwanted change is immediately propagated to all systems.  The server beyond your reach is now the dog, and all "your" devices are now its chew-toys.  Whatever entity signs into that online account is deemed to be "you", and shares some control with the vendor; if you're locked out, sorry for you!

Once you get past the OOBE (if not before), you're pestered to "backup" to OneDrive.  If you swallow the bait, the content of many shell folders is automagically copied to the OneDrive cloud storage service, while what you see locally as your files may appear to work, but in reality may have been replaced with stubs to online files, "to save space".  Just like automatic Device Encryption, this payload is hidden, with delayed effects that arise when you try to work offline, and "your" files aren't found within the large cache footprint that the cloud service uses as an ashtray.

So, now your data is exfiltrated, local copies destroyed, and you're even more vendor-dependent.  When you run out of free space at the server end, you'll have to pay up for more space, or buy some other service that bundles the extra space you need.  

This is a straightforward hook-and-reel-in sales scam, similar to a time-bombed "free trial" that lasts just long enough to create data you can't use unless you pay (especially Outlook's .pst walled garden).  That's a significant incentive to the vendor, leaving aside any geopolitical implications.

You can use Windows 11 safely

As at August 2025, there are ways to skirt these risks while still upgrading to Windows 11 for more effective ongoing support.  There are ways to break into the OOBE to trigger a restart that will add small links for "I don't have Internet" and "Continue with limited setup"; there are ways to craft a bootable USB installer that bypasses various compatibility checks and onerous UI pressures.  As long as you can install Windows 11 and run the OOBE while safely not connected to the Internet, you have the potential to be safe; staying that way requires ongoing resistance to embedded sales pitches.

There are also ways to block Device Encryption by policy, as applies via a .reg import or direct Regedit; to hide OneDrive, or at least stop it reducing your files to online pointer stubs, and so on.  If Device Encryption is already in effect, you can step over the scary warning to turn that off; maybe it will take a long time, as the warning states, or maybe not - the whole process is so opaque (or transparent, in that one sees through it even if trying to see it is harder) that I've no idea if it completes as quickly as it seems, or if it grumbles along unseen for hours or days.

Upgrade carefully, if system is compatible

In my opinion, it's better to carefully upgrade Windows 10 to 11, after suitable backups, as long as your system is compatible, than stay on Windows 10.  It's also a good time to upgrade the OS hard drive to a speedier SSD, as that way the original hard drive can be your "undo" fallback backup.

If your system is incompatible, you may be able to force the upgrade via Rufus or similar tools, and/or more manual methods - but I'd be reluctant to do that.  "Hard" incompatibilities include PopCnt instruction and SSE 4.2 support; without these, Windows 11 24H2 (the minimum version supported after October 2025) will likely BSoD on boot.

Some of the softer requirements may be attained by changing partitioning from MBR to GPT, changing boot mode from CSM BIOS emulation to UEFI, enabling Secure Boot, and enabling TPM, either as such, or drilling down into CMOS Setup to where the processor vendor implements this as a fTPM.

So far, so good - but if you can't pass the PC Health Check or the Windows 11 Installation Assisitant won't install, then you'd have to resort to an "unsupported" state via bypass methods e.g. Rufus.  I don't see a great future there; the PC may be fine, until some update or annual new version starts to invoke things that are not there, which could leave the system unable to run, or even boot up.

"If a bad guy can run code on your system"...

Microsoft's 2000 Ten Immutable Laws of Security still make sense to me, even if the battle to keep our computers "Personal" has long been lost.  The list has been weaseled to pass off "the cloud" (= other people's computers) as safe enough, but the original is here.  The first Law:

"If a bad guy can persuade you to run his program on your computer, it's not your computer anymore"

I'd show you the rest of the laws, virtually all of which are broken by the unwanted intimacy of current vandor (vandal/vendor) practice, but the WayBack archive page first bordered on the unusable (refreshing banner ad moving the page, refusal to copy selected text to clipbord or print the page), then after coerced "donation", lost where I'd come from and failed to load the page when the URL was re-pasted.  Enshittification is certainly not unique to a few big vendors; buggy code is everywhere, and it can be hard to distinguish stupidity from perfidity!  Bah, humbug, etc.

Should you trsut your vendor?

At the top of the Trust Stack is the intent of the party to be trusted; at the bottom is the competence to do what they intend to do.  There have been updates that either trashed data completely, or accidentally placed it out of reach, raising concerns about the bottom of the trust stack, as if the need to constantly fix code via "updates" wasn't enough.

Most of the links are about a scenario where the user profile subtree in C:\Users was shunted off and replaced with a new profile, so at least the files could be found... unless they couldn't in some cases.  However, I remember a much harder crisis where user data was deleted completely, not in the recycle bin, due to a side-effect related to... OneDrive (formerly called SkyDrive, until someone watched the Terminator movies and suggested a branding change).

It is utterly indefensible for a code vendor to delete user data, no matter what they were trying to do with it; the sheer arrogance beggars belief. Moving directory file entries to a C:\Windows.old is one thing, but to delete completely and irreversibly, is quite another risk to take with what is not yours.

So... should you trust the "man behind the curtain"?  After all, well-resourced professionals with a large budget should keep their servers running more reliably than a home user's system, and you may feel that is true for you.  

But leaving aside vendor priorities and intent, the fact is that there's nothing magical about what the cloud is made of; it's all stacked layers of code with significant error rates, whether it's the cross-platform compilers, the microcode squirted into what used to be "hard logic" processors, a UEFI as complex as Windows 95 (or "extensions" thereof), the firmware within off-processor components as complex as MS-DOS, web browsers and the unwashed junk they have to run, or the strapping together of these things in de-featured web Apps and PWAs.

We have no insight into what goes on in cloud servers; the fixes, emergency kludges, crises narrowly avoided or not, the data loss affecting "only a few users", etc. until a Cloudflare mess wakes us up.

AI: The Computer Revolution, Again

I'm lucky to have experienced personal computing from the beginning, from Sinclair's Black Watch, ZX80, ZX81 and Spectrum through Pick R83 and MS-DOS 3.3 to today's herding into Microsoft's pen for Windows 11 survivability.

We are perhaps the last human generation to believe we could understand electronic digital computers at every level, from transistors and logic gates through to automated online banner ad auctions, Bitcoin mining, botnets, etc.  It's got so complex, newcomers have to choose which slice of the tottering stack in which they will specialize; code is becoming ephemeral, beyond human scope if it is to be kept on track.

In the 16-bit home computing era, computers became our toys, while futurists were still telling us we needed to learn binary arithmetic at school to prepare for tomorrow's careers.  Hobbyists were asked to justify the time and effort they lavished on their FREDs (Folking Ridiculous Electronic Devices), who would reply "Look, I can create a page of printed text in minutes!" ...not counting minutes spent waiting for code to load off audio cassette at one end, and the noisy printer at the other.

So it is now, with "AI", i.e. the extension of expert-system pre-loaded wisdom, to machine learning.  We play with ChatGPT etc. as toys, while bigger budgets put AI to work; new but transient careers beckon, and early adopters may find the skills built in advance are as mis-aligned as trying to apply only binary arithmetic to higher-level programming languages.

Performance is not yet there; early AI-capable laptops and PCs are as rare and costly as the first round of "multimedia" (sound card, CD-ROM, video playback, a handful of available titles) before Windows 95. Nvidia's monster AI chips are as unattainable for us as 3DFX's dedicated 3D accelerators were way back in the day, when affordable "Windows Accelerator" graphic cards just couldn't cut it for new 3D games.  Industrial-grade AI thrives on ye olde IBM mainframe budgets of half a century ago.

This time round, I'm content to watch from the sidelines - if I was 20 years old again, I'd have jumped into Android when toy smartphones escaped Apple's iron grip, I'd have years of Linux under my belt, and I'd be very actively involved in "playing with AI".

Emaul Attackments: .HTM vs. .PDF Risk

My bank used to send statements via email as .PDF, but now sometimes switch to .HTM(L) file attachments instead. Here's why that's an elevation of risk...

Both HTML and .PDF files can contain auto-running JavaScript, elevating the risk from "reading a document" to "running a program".  But whereas one can (and should) disable JavaScript in Acrobat Reader, it's impractical to do that for the web browsers that typically "open" HTML files.  

Microsoft's Chromium-based Edge does not run JavaScript in .pdf files, at least as at August 2022, so these files are still safer than HTML even if "opened" in Edge.

Inspecting the bank's HTML "statement" in Notepad shows JavaScript followed by an encrypted mass of content, which could be (and do) anything.  Here's the start of a "real" bank statement "document"...

-script type="text/javascript"-
document.write(decodeURIComponent(atob('JTNDaHRtb... 

...munged to invalidate HTML syntax for safety; here's a suspected malware sample...

-script type="text/javascript"-
document.write(decodeURIComponent(atob('JUVGJUJCJUJGJT...

...can you tell the difference?  Why should I have to trust embedded code to "read a statement"?

Automated messages containing attachments and/or links are always hi-risk, as it's so easy to forge what the recipient sees as "message text" - and already I see fake "email statements" from "my bank", given the message dates don't correlate with statements as seen via the bank's web site.

So, let's hope the bank re-thinks this strategy, rather than reprise "Banking On Java"

The HTML problem

Using HTML everywhere as "rich text" for "documents" started with the "everything is a web page" mania of Windows 98, where HTML Application files (.hta) abounded, and HTML Templates (Folder.htt) were dropped into file system directories and namespace folders to create a "web" look.  This was when Internet Explorer was meshed deeply into Windows, to support Microsoft's claims it was not a separate bundled program competing unfairly with Netscape.  HTML also became the new .chm Help at this time.

Using HTML as rich text for "documents" creates a wide safety gap between the low skills needed to use a system, and the higher skills needed to use it safely.  The seeds of this lie in the Object Oriented Programming concept, where "documents" are "objects", and all objects can have Methods (code) and Properties (variables).  Normal programming practice is to interface with such objects by asking their methods to expose their internals - and so "reading a document" becomes "run code".

JavaScript

How risky is JavaScript - doesn't it just work safely within a single document or page?  Well, it's powerful enough to be the sole code for Progressive Web Apps, that are expected to become ubiquitous as the "desktop" programs we use today - and malware use is already rife.

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!

Egde Changes How URLs are Copy-and-Pasted

Edge changes how URLs are Copied and Pasted, by taking the page's title to overly the actual link as the visible clickable text. 

Reliability failure

How this works in practice, depends on the target application into which the link is Pasted.  You may see the actual URL there, as you'd have expected, or the page title as plain text, or (as Edge intended) the page title as clickable text that launches the actual URL if clicked.

What happens when these new links are Copied and Pasted back into Edge (or elsewhere) may be a second point of failure, or at least breaking the principle of "least surprise".  Instead of navigating to the actual URL, you may see search results based on the visible text, if considered invalid as a URL.

Exploitability

HTML is inherently exploitable, in that arbitrary visible text can "spoof" the hidden underlying URL.  This is especially true when the visible text appears to be a valid URL, leading the user to expect this is the actual URL that will be reached when clicking the link.  HTML typically applies a blue color and  underlines visible characters to indicate a clickable link, but neither of these visible cues apply to whitespace, allowing unexpectedly large click-risk surfaces, spoofing users who click such space to merely select that window or pane.

The new handling of links by Edge adds opportunities to spoof users, given that Edge is trusting web pages to set how the hidden URL will be presented to the user.  When this visible text is valid as a URL. it will automate launching that URL when pasted back into a web browser, which can in turn hide the nature of the exploit.  For example, the text "http : / / microsoft.com" over actual URL "http : / / google.com" will correctly launch Microsoft's site when pasted back into a web browser that processes the visible text, but launch the Google site when pasted into a web browser that processes the hidden URL.  Try this: http://microsoft.com

HTML risks had already escalated to include hidden autorunning JavaScript and ActiveX, when Windows 98 fell in love with the web, to use HTML everywhere as "rich text"; local folders, active desktop, .chm Help files, Outlook Express and Outlook email "message text", etc.  Today's "HTML" not only relies on JavaScript, but can install PWA (Progressive Web Apps) that can silently run underfoot when the web browser appears to have been "closed".

How to turn off the new feature

You may want to turn off the new feature, as part of risk management, and several sites give advice how to do this, including via Regedit.  This site is especially useful for managing all sorts of settings via Group Policy for sysadmin overlords, or Regedit for the rest of us on Windows Home.

So far I haven't seen a Regedit for the extra switch within the visible Edge, Settings, "Share, Copy and Paste" UI, i.e. "Use the format selected above when copying links from within web pages".  The text that follows is helpful to tease out what this means; as I understand it, it's links you copy from the page rather than the URL address bar of the browser - and points to the common "grope-ahead" risk scenario, i.e. where software takes risk on behalf of the user, that the user did not indicate an intention to take.

Grope-ahead risks

For example, if you set the shell to open items with a single click (as would happen in a web page), then it's far harder for a user to select a known-malware file to delete it, when the system jumps ahead and "opens" the file (thus running the malware) just because the user selected it.

The above example exploits by-design vulnerability, and such vulnerabilities take notoriously long to be fixed, if ever they are - e.g. years of auto-running hidden macros in "documents", since Microsoft called the Concept PoC a "prank macro" rather than "virus", and initially responded by offering a clean-up tool written specifically for Concept, as if there would never be other macro vir.. uh, "prank macros".  

Grope-ahead risks grow when you consider exploits of code defects; consider the shell's "Preview" pane, indexers, integrated filters that kick in when simply listing files in a folder, etc.  The OS behaves like a crawling infant, putting whatever it finds in its mouth to see what they taste like; too bad if it's the wrong end of a loose power cord!  This breaks the rule: Do not trust arbitrary content, especially from "the edge".

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?

Invisible BCD Boot Menu; Intel Graphics Driver

Geek summary: First post-install Win10 update of Intel Graphics drivers for i5-1035G1 renders the BCD Boot Menu invisible, although it still works.  Fixed if Device Manager, Display Adapter is Disabled; problem reproduced if Enabled, effects taking place after Windows restart.

I suspect the cause is failure of the driver to attain color values when started in the raw EFI context, as using the Win10 Settings, Recovery, Advanced UI will show the boot menu in proper color.  That UI reaches a different boot menu, with the normal boot menu seen via Other Operating Systems UI, without restarting through raw EFI boot.  Either the first menu applies the needed color settings, or bypassing the raw EFI phase preserves the successful Win10 OS context.

Test system where problem encountered; brand new Asus laptop based on new 10nm 10xxGx series processor, specifically i5-1035G1.  Not encountered in a new desktop PC built on Gigabyte motherboard with Pentium Gold G6400 processor, also as set up last week.

Background

EFI boot from internal storage enters that storage via {bootmgr}, which displays a boot menu if there are more than one OSLoader entry in the "DisplayOrder".  By default there's only one entry to boot Windows 10, so this boot menu is normally bypassed, and the bug is thus unobserved.

As part of my standard setup, I add boot entries for Safe Mode and Safe Cmd, to float these less-destructive troubleshooting opportunities above the deceptively-named "Refresh Your PC" (a bit more than a F5 web page "refresh") and "Reset Your PC" (far beyond pressing the Reset button to force a bad-exit Restart) bear-traps that you'd have to walk past to eventually find the Safe Modes.  This causes {bootmgr} to display the BCD Boot Menu for the Timeout seconds, thus revealing the bug.

Failure pattern

This particular system displays a GUI "Asus" image during the EFI firmware phase of the boot process, which fades before the BCD Boot Menu appears.  As this logo fades, the color undergoes a subtle shift to a less-blue hue of white; possibly a switch to greyscale, rather than a Win10 "night light" setting (as changing that setting does not change this behavior).  When the failure pattern is not in effect, the Asus logo does not change hue as it fades.

Normally, you'd then see the Boot Menu, but instead, the screen stays black.  There's still display signal present, and if if blindly use the arrow keys before pressing Enter, the menu works; you'd load whichever menu item you'd blindly selected.  If you use the trackpad or a mouse to move the mouse pointer, it will appear as the expected white arrow, and blindly clicking will also succeed in selecting and launching a menu entry.  

If you do nothing, the screen remains black for Timeout seconds and then boots normally.  The initial impression is that the system has "hung" or "crashed" (untrue, as safely tested by pressing Caps Lock to toggle the keyboard LED) or that the system is way slower to boot than expected, especially for an NVMe SSD.

Problem onset

I set up systems offline, to limit problems to one system rather than whatever is being pushed from the entire Internet.  During this phase, the BCD Boot Menu worked normally as expected, both before and after upgrading the "new laptop" Windows 10 version to a freshly-made version 2004.

Problem only appeared after attempting to disable Asus's aggressive underfootware, and initially I ascribed it to this and quickly reversed changes back to the default non-Microsoft Services, Startup entries, and Scheduled Tasks. However, this was also the first Restart after going online and letting Windows Update pull down and install updates, which included "driver updates", which in turn included OEM programs now pushed as "drivers" to evade user management via Settings, Apps or Control Panel, Programs and Features.

The fix

BIOS update, re-defaulting CMOS Setup settings, power off at the mains, holding down Power switch (part of keyboard) for 20+ seconds, BCDEdit nudge to {bootmgr} do not fix.  Device Manager, Display Adapter, Update Driver reports the latest (thus surely the "best") driver is already installed, and the Rollback Driver button is greyed out.

What fixes the problem, is Device Manager, Display Adapter, Disable and then a Shudown UI, Restart to put this change into effect across the EFI boot phase.  Enabling the Display Adapter reproduces the failure pattern after the Restart; the problem remains present until Display Adapter is Disabled again.

Note; I also disable the Windows 10 "Fast Startup" setting via the convoluted Settings, Power UI required.  So at least we know we're not resuming a flawed system runtime after a fake "shutdown".

Likely cause

I suspect the Intel graphics driver depends on context established by Windows, which is absent (nul pointer, anyone?) when the driver is run from raw EFI.  It either sets an incorrect graphics mode, or draws color values from zero'd memory such that "ink" and "paper" are both black.

Safety implications

Class 3 UEFI forces EFI boot, and thus all the flaky complexities of "Extensibility".  Whereas the ancient BIOS/MBR code was sufficiently trivial to be free of bugs, EFI is not, and adds the risk of malware positioning itself to run before any OS or storage device can boot.

The fact that a Windows driver can poison the pre-OS EFI boot process is worrying, especially as the choice of driver to load is either read by pre-OS EFI from Windows, or has been latched into pre-OS EFI behavior by a setting applied from within Windows.

Scenario 1

EFI executable .efi files are able to read the Windows registry, and do so, as the BCD is in fact a Windows registry hive in structure.  However, {bootmgr} is expected to be OS-agnostic, as at the time the Boot Menu is displayed, no decision has been taken as to what OS to boot - could be any version of installed Windows, a PreOS WinPE, a Linux, anything.  So the code that runs before the Boot Menu should not dip into Windows registry hives, e.g. to load drivers or pull variables such as the colors to use for the boot menu, etc.

In fact, safest would be for pre-OS {bootmgr} code to use the lowest default screen resolution, rather than loading any 3rd-party "drivers" for a "better visual experience".  This is a similar safety issue as code integration into "safe modes" (e.g. screen savers).

Scenario 2

When a device driver is selected in Windows, e.g. by disabling or enabling a Display Adapter, Windows may also be changing drivers within firmware EFI.  If so, then a different EFI driver will load, depending on that Windows setting, and a buggy EFI display driver could cause the problem directly, rather than via using null data.

All this is hard to assess, as modern systems blur hardware, firmware, "BIOS", drivers and OSs.  Everything is now likely to contain non-trivial and thus buggy code, and everything is treated as a black-box object that may "leak".  The interface programming model is supposed to blacken the boxes of the object-orientated model, hiding the gooey details more effectively; instead of the "calling code" examining exposed variables (object Properties), it now asks the object to return these variables (object Methods), trutsing the object's code to do that - which is not a great safety/security idea.

PDF: Safe, Print; Pick One

Geek summary: If you print a .pdf and "enable all features", you're enabling all risks!

Adobe's PDF is a significant edge-facing risk, and unlike their wretched Flash, no signs of it going away soon.

The email risk

"Opening" a .pdf in a web browser is risky enough, but a bigger risk are all those automated .pdf emaul attackments; "invoices" spawned by generic accounting packages, "forms to print, sign, scan and return", etc. Even if there's a pretense at certificate-based "security", the sender still expects the recipient to trsut a handful of easily-forged pixels, boilerplate text, and a From: address as being "from someone you know".

Evaluating risk of incoming email links and attachments needs proof of trusted human intent to send, not just which human's system appears to have sent it, as malware is likely to spread via harvested addresses that can be used to populate both the From:, and the To:, CC: and BCC: sides of the fence. When both From: and To: addresses are harvested on the same infected system, the malware will most likely be "From: someone you know"!

Digital signatures proving it came from that user's system don't address that problem; you need to read the message "text" to see if the human sender intended to send the message and the attached file(s).  A smart sender will write such text, but the lazy, clueless or disinterested will not; when the accounting program or whatever pops up a boilerplate message (typically "you need Adobe Reader to open this file" with a link that one hopes doesn't point to a malware server), they'll just click Send without changing (personalizing) this text at all.

So we have all these near-identical boilerplate messages bouncing around, telling users to "open" files and/or click links to install software, with attached .pdf - and those files are exploitable enough, without the need to trigger heuristics by faking the file type to "open" raw code.

Risky "data files"

Risks from "data" files stem from the object model, that treats everything as an object, and all objects can have Properties (internal variables) and Methods (internal code) that other objects can use.  The human user is just another "object" that happens to be at the end of peripheral UI input devices.

This is the code equivalent of dumbing down user concepts of "read", "edit" and "run" to just "open"; the same safety-oblivious mindset underlies both, and the interface programming model makes this worse by swinging from reading exposed Properties to running Methods to return these.  That implies the object is now trsuted to run code, to get anything out of it.

Specifically, .pdf is designed to run JavaScript hidden from the user, and even if this script is prevented from "doing anything nasty", it can be leveraged to set up the stack to climb the exploit ladder to running raw code.  If you look in the Acrobat (Reader) Edit, Preferences section, you'll see other exploit opportunities such as multimedia, "opening" other file types, etc.

These risks have been obviously non-theoretical since the Concept "prank macro" and subsequent destructive (including hardware-killing CIH payload) Word and other MS Office macro malware, yet that didn't stop Adobe baking the same risk into the .pdf standard years later.  

Today's reading suggests Microsoft quickly saw the risks, but at the time, I remember the first response had two purposes; reassure users this was "not a virus" but just a "prank macro", and provide a removal method specific to that particular vir.. uh, "prank macro", as if there'd never be another one. It took years to (more or less) fix that "works as designed, won't fix" easy exploitability, and that happy period of easy scripting arguably established the commercial viability of malware.

Protected Mode

Fortunately, we have Adobe's Protected Mode to keep us safe - at least until we print.

I've always been creeped out when "reading" a .pdf and having to print it out, when that asks me to "enable all features".  What "features"? Allowing the "data file" to drop and run code?  Apparently yes, this is exactly what happens if this actually exits Protected Mode (not that Adobe tells you this in that happy "enable all features" dialog box).

It's also good to ensure you use Reader and not the full Acrobat as your default .pdf "open" file association, as full Acrobat duhfaults to disabling Protected Mode!

I hope you've been clicking this article's implicit links along the way, as that's where I "show my workings" as to how I understand this situation.  

Now consider how many of those links "opened" a .pdf in your web browser...