Windows 11 Insider Preview Build 28020.1371 KB5073097: Start and Explorer fixes

Microsoft has pushed a small maintenance flight to the Windows Insider Canary Channel today — Windows 11 Insider Preview Build 28020.1371 (KB5073097) — delivering a handful of targeted fixes for Start, File Explorer, input settings, and an elevated Windows Terminal hang, while calling out one cosmetic known issue with the desktop watermark.

Background / Overview​

The Canary Channel is Microsoft’s fastest-moving Insider ring for platform-level experiments and early-stage changes that may never ship to general users. These builds are intentionally light on documentation, frequently gated by server-side feature flags, and can require a clean install to leave the channel once you’ve joined. The flighting model means a change in Canary may appear to a subset of Insiders first and then ramp up, or be abandoned entirely based on telemetry and feedback. Build 28020.1371 is a small cumulative update: it doesn’t surface new user-facing features but focuses on quality-of-life stability fixes for common daily workflows. That pattern — small, surgical fixes in Canary — is consistent with recent Canary releases in the 28000/28020 series.

---

What Microsoft shipped in Build 28020.1371​

At a glance, Microsoft lists the following fixes in the flight notes:

• Start menu: fixed a bug where selecting an item in a folder of pinned Start items could make the whole folder become invisible.
• File Explorer: addressed a white flash that could appear when navigating between pages for some Insiders after the prior flight.
• Input (Keyboard): corrected an inversion where the keyboard character repeat delay shown in Settings > Bluetooth & devices > Keyboard did not match the backend setting.
• Other:
• Fixed a root cause that could freeze PCs when attempting to run Windows Terminal elevated from a non-admin account.
• Fixed an issue where the Share dialog might incorrectly present an option to share to Shell Experience Host.
• Known issue: desktop watermark displays the wrong build number.

These are small, low-profile fixes but address areas that often generate daily friction and high-volume feedback from Insiders.

---

Why these fixes matter (technical and UX analysis)​

Each item in this flight ties to real-world pain points. The following subsections break down the probable causes, user impact, and risk profile for each fix.

Start menu: pinned-folder invisibility​

• What happened: Selecting something inside a pinned-folder could leave the containing folder invisible. The symptom is effectively data loss in the Start layout UI — pins are still present but not visible, causing confusion and repeated re-pinning work.
• Likely cause: UI state-management race or a layout invalidation bug inside Start’s pinned-folder component that occasionally fails to redraw or loses its visibility flag. Race conditions between user input, layout recalculation, and the pinned-data model are typical culprits.
• Impact: High for everyday users who rely on pinned Start items — lost discoverability and unresponsive Start visuals lead to frustration and support reports.
• Risk: Low risk to system stability; the fix is UX-focused and should not change underlying account settings. However, users who already lost visible pins may need to sign out/restart to force UI refresh.

File Explorer: white flash when navigating​

• What happened: A brief white flash occurs when moving between pages (likely between Home, Search, or other panes), producing a jarring visual artifact.
• Likely cause: Render-state regression after a recent change — possibly dark-mode repaint issues, animation timing, or a missing background composition step causing a default white draw before the final UI surface paints.
• Impact: Annoying but non-destructive; it affects perceived polish and accessibility (bright flashes can be discomforting for some users).
• Risk: Low; this is a visual fix. Monitor for associated regressions in Explorer rendering after the update.

Input: keyboard character repeat delay inverted in Settings​

• What happened: The UI control for character repeat delay in Settings was backwards compared with the actual backend value — e.g., the slider showed “short delay” while the system honored “long delay.”
• Likely cause: Parameter mapping inversion or unit mismatch between the Settings front-end and the kernel/input driver layer. This kind of error is classic when UI enumerations are updated but the value translation (UI → OS API) is reversed.
• Impact: Confusing keyboard behavior and poor discoverability when troubleshooting typing issues.
• Risk: Low on stability, medium on user trust — input settings must be accurate for users who rely on precise typing behavior (gamers, typists, accessibility users). After the fix, test the Settings toggle across expected ranges.

Windows Terminal elevated from non-admin: freeze/hang​

• What happened: Attempting to launch Windows Terminal elevated (Run as Administrator) from a non-admin account could cause a system freeze.
• Why it’s important: This is the most severe issue in the notes — a freeze implies the system becomes unresponsive, which can require a hard reset and potential data loss.
• Likely cause: UAC elevation flow interacting poorly with Terminal’s process model, or a deadlock during token creation, session switching, or the communication handshake between a non-elevated parent process and an elevated child. Another vector could be third-party credential providers or enterprise sign-in hooks interfering with the elevation flow.
• Impact: High — any freeze/hang requires careful remediation and a patch. The fix likely adjusts how Terminal requests elevation or guards against problematic states in the elevation handshake.
• Risk: Patches here are sensitive. While the fix reduces a serious stability hazard, it should be validated by Insiders especially on systems with custom credential providers, non-standard sign-in stacks, or security software that hooks process creation.

Share dialog: option to share to Shell Experience Host​

• What happened: The share UI unexpectedly offered “Shell Experience Host” as a share target — a system component not intended for general content sharing.
• Likely cause: A mis-registered share target, incorrect filtering of share-capable apps, or a bug in the share-provider discovery pipeline that surfaced system-only components.
• Impact: Low functional risk, but confusing and potentially alarming to users seeing system processes appear in a share list.
• Risk: Minimal; this is cosmetic/product confusion and the fix improves the Share dialog’s target filtering.

---

Verification and sourcing — what we confirmed and what remains unverified​

• The build announcement and the short change list are available through community mirrors and Insider forums; a copy of the announced notes has been posted to community channels that track Insider releases.
• The broader Canary channel behavior (staged rollouts, experimental features, and the requirement for a clean install to leave the channel) is stated in Microsoft’s Flight Hub and past Insider posts and remains consistent with current Canary guidance.
• One item that could not be independently verified at publication time was a formal Microsoft Support KB page for KB5073097. Searches of Microsoft Update/Support catalog and the common KB index did not produce a canonical support article for KB5073097 (small Canary KBs are sometimes only referenced inside the Insider blog post or the update's metadata and don’t always get a separate Support page immediately). Treat the KB number as the update’s package identifier for the Insider flight rather than as a fully documented public servicing KB until Microsoft publishes a support article. This is a cautionary observation and not a contradiction of the release notes, but it’s worth noting for sysadmins who track KB pages for change logs and inventory.

If you rely on formal KB documentation to audit updates, monitor Microsoft’s Update Catalog and Support site in the coming days; Insider KBs frequently appear gradually or are deliberately minimal for Canary flights.

---

Practical guidance: who should install and how to validate​

This build is aimed at Windows Insiders who tolerate instability and want to test platform-level fixes. The short checklist below explains who should consider it and how to validate it.

• Recommended for:
• Windows Insiders with spare test devices who want to help validate the fixes.
• Enthusiasts who previously encountered one of the listed bugs and want to confirm remediation.
• Not recommended for:
• Production laptops, work-critical desktops, or devices lacking a recent backup.
• Machines that must remain on a supported channel for business-critical workflows.

How to install and verify:

• Ensure your PC is enrolled in the Windows Insider Program and set to the Canary Channel.
• Open Settings > Windows Update and check for updates. Install the offered update (listed under the package identifier shown in your Update history).
• After updating, confirm the build via winver (Win + R → winver) to display the OS build string.
• Validate fixes:
• Start menu: open pinned folders and perform selection actions that previously caused the invisibility bug.
• File Explorer: navigate between pages and observe whether the white flash remains.
• Keyboard repeat: Settings > Bluetooth & devices > Keyboard — set a delay and confirm actual key-repeat behavior in a text field.
• Windows Terminal: attempt to run Terminal elevated from a non-admin account (do this in a controlled environment; save work beforehand).
• Report any new or persisting issues using the Feedback Hub (Apps > Windows Terminal / File Explorer / Start menu) with precise reproduction steps and attach diagnostic traces when possible.

---

Troubleshooting and rollback notes​

• If you hit regressions after installing the Canary flight, standard troubleshooting applies: uninstall the update from Update history, reboot, and if that doesn’t resolve the issue, roll back to a system backup or recover from a system image.
• Important: leaving the Canary Channel and moving to a channel with a lower build number generally requires a clean installation of Windows 11. The Windows Insider process enforces this due to differences in flight-signed builds and feature enablement. Back up your data before experimenting in Canary.
• Use the Feedback Hub to send detailed diagnostic reports: a clear repro, steps to reproduce, and logs will increase the chance the engineering team can triage and validate fixes rapidly.

---

Enterprise perspective and risk assessment​

Although Canary Channel flights are not intended for enterprise deployment, the kinds of fixes in 28020.1371 are relevant to IT teams tracking user-reported issues:

• The Windows Terminal elevation freeze is the only fix that carries enterprise-grade risk if present — a system freeze can lead to data loss or interrupted services. IT teams should track any reports of Terminal elevation hangs from internal testers and keep Canary installs isolated.
• Visual and small input-setting fixes (Start menu, File Explorer flash, keyboard repeat) are primarily usability improvements and low risk. They’re worth validating in pilot groups if they were previously observed in your environment.
• Because Canary builds can be gated server-side and rely on feature flags, presence of the build on a device does not guarantee exposure to every experimental change — test plans should focus on symptoms and behaviors rather than build numbers alone.

---

What to watch next​

• Keep an eye on Flight Hub for any updates or retractions to the change log and for when the KB5073097 entry (if any) appears in the Microsoft Update Catalog.
• Watch Feedback Hub reports and Windows Insider community threads for any regressions introduced by this flight — particularly issues related to elevation flows and input behavior.
• Expect Microsoft to roll similar stable fixes into broader channels eventually, but remember that Canary is experimental: not every fix or concept here will propagate beyond the Insider rings.

---

Bottom line​

Build 28020.1371 is a small, focused Canary update that cleans up a handful of user-facing rough edges — from a disappearing pinned Start folder to a worrying freeze when running Windows Terminal elevated from a non-admin account. These fixes improve day-to-day reliability for Insiders and demonstrate Microsoft’s continued iterative approach to hardening Windows 11 at the platform level.
For Insiders: install on test hardware, verify the specific fixes you care about, and file feedback when behavior is unchanged or new problems appear. For IT and production users: continue to avoid Canary on critical machines, monitor Microsoft’s official KB/Flight Hub updates for formal documentation, and treat this flight as an early signal of stability work that may find its way into later, broader releases.

---

Appendix — quick checklist

• Use winver to confirm build after update.
• Test the four targeted areas (Start, Explorer, Keyboard, Terminal).
• Report via Feedback Hub with repro steps.
• Back up important data before experimenting; leaving Canary requires a clean install.

---

Source: Microsoft - Windows Insiders Blog Announcing Windows 11 Insider Preview Build 28020.1371 (Canary Channel)

 

[ChatGPT]

Microsoft has pushed a small maintenance flight to the Windows Insider Canary Channel — Windows 11 Insider Preview Build 28020.1371 (KB5073097) — that focuses on a handful of targeted stability and UX fixes for Start, File Explorer, input settings and an elevated Windows Terminal hang, while calling out a cosmetic watermark mismatch as a known issue.

Background / Overview​

The Canary Channel is Microsoft’s most experimental Insider ring, used to trial platform-level changes, silicon enablement work and early-stage UX experiments that may never ship broadly. Canary builds are frequently light on consumer-facing documentation, staged behind server-side feature flags, and can require a clean install to exit the channel. The current 26H1 branch — which surfaces a visible version bump for Windows 11 — is positioned primarily for platform enablement rather than a mainstream feature update, and Canary serves as the primary testbed for that work. Build 28020.1371 is not a feature release. It is a small cumulative flight that addresses several practical pain points Insiders have reported after recent Canary flights: a disappearing pinned Start-folder bug, a white flash in File Explorer when navigating between pages, a Settings UI / backend mismatch for keyboard repeat delay, a Windows Terminal elevation freeze from non-admin accounts, and a spurious Share target entry. Microsoft also warns that the desktop watermark is showing the wrong build number for some Insiders.

---

What Microsoft shipped in Build 28020.1371​

At-a-glance list​

• Start menu: fixed an issue where selecting an item in a folder of pinned Start items could make the entire folder become invisible.
• File Explorer: fixed a white flash that could appear when navigating between pages for some Insiders after the prior flight.
• Input (Keyboard): corrected an inversion where the keyboard character repeat delay shown in Settings > Bluetooth & devices > Keyboard did not match the backend setting.
• Other: fixed a root cause that could freeze PCs when attempting to run Windows Terminal elevated from a non-admin account; fixed an issue where the Share dialog might incorrectly present an option to share to Shell Experience Host. A cosmetic known issue: the desktop watermark can show the wrong build number.

These items are consistent with the pattern of “surgical” Canary updates: no major features, but corrective fixes aimed at high-feedback areas.

---

Deep dive: Start menu pinned-folder invisibility​

Symptom and user impact​

Insiders reported that interacting with a pinned-folder inside Start — for example, selecting an app within the folder — could leave the containing folder invisible afterwards, even though the pins still exist. The effect is effectively temporary loss of discoverability: pinned apps remain present in the Start layout data but are not rendered visibly, which leads to confusion and repeated re-pinning. This is a high-friction UX regression for everyday users who rely on Start pins for quick access.

Likely cause and technical analysis​

While Microsoft’s short flight note does not provide a line-by-line root-cause, the observed behavior is consistent with a UI state-management race or a layout invalidation bug: either the pinned-folder component fails to redraw after a selection, or an internal visibility flag is toggled incorrectly following a navigation/selection event. Race conditions between input handling, layout recalculation and the pinned-data model are common causes in complex shell components. Because this is primarily a rendering/UI state issue, the fix is low risk to kernel or storage subsystems but important for perceived reliability.

What to test after installing​

• Open Start, create or locate a folder of pinned items.
• Select an item inside the folder.
• Observe whether the folder remains visible and whether icons/labels render correctly.
• If the folder appears invisible, sign out or reboot to check for UI refresh behavior.

If the issue persists after the update, file detailed repro steps to Feedback Hub and include screenshots or a short screen capture.

---

Deep dive: File Explorer white flash when navigating​

Symptom and user impact​

Some Insiders saw a white flash when moving between File Explorer pages (for example, from Home to Search or other panes) after the previous Canary flight. The effect is jarring and potentially accessibility-unfriendly (bright flashes may be discomforting for some users), but it is non-destructive.

Likely technical explanation​

This kind of artifact typically points to a render-state regression: an interim default background color (white) paints before the final themed UI finishes composing, a missing background brush in the composition pipeline, or an animation timing mismatch causing an out-of-order frame to display. Dark-mode treatments are a frequent source of these regressions when theme transitions or repaint gating are adjusted. The fix likely restores the correct composition order or ensures the themed background is ready before swapping in the page content.

What to test after installing​

• Open File Explorer and navigate between Home, Search and other pages repeatedly.
• Observe for any flashes during transitions, both in light and dark themes.
• Verify same behavior on secondary monitors and across mixed-DPI setups if available.

If visible flashes remain, capture a short video and submit it through Feedback Hub to help Microsoft correlate telemetry with repro traces.

---

Deep dive: Input (keyboard) — character repeat delay inversion​

Symptom and user impact​

The Settings UI element for keyboard character repeat delay (Settings > Bluetooth & devices > Keyboard) was displaying a value that was inverted relative to what the system actually used. In other words, the UI could say “short delay” while the backend honored “long delay,” producing confusing typing behavior. This undermines trust in Settings and creates practical annoyances for gamers, touch-typists and accessibility users who rely on precise repeat rates.

Cause analysis and risk​

This issue most likely stems from a parameter mapping inversion — either an enumeration mismatch between the Settings front-end and the input subsystem, or a units/scale conversion error. These are classic front-end ↔ back-end translation bugs (for example, where 0–3 in the UI maps to 3–0 in the system). The fix is low risk to system stability but must be verified across different keyboard drivers and international IME setups. The correction restores parity between what users set and what the OS enforces.

What to test after installing​

• Adjust the repeat delay slider across its full range and type into Notepad or a similar text field to confirm the delay matches the selected setting.
• Test with different physical keyboards and any installed IMEs to ensure consistent behavior.
• If enterprise-managed group policies control keyboard behavior, validate that policies are still respected.

---

Deep dive: Windows Terminal elevation hang (freeze) from non-admin accounts​

Symptom and severity​

The most serious fix in this flight addresses a scenario where attempting to run Windows Terminal elevated from a non-admin account could freeze the PC. A freeze implies system unresponsiveness that can require a hard reset and risks data loss, making this a high-severity regression while it existed. Microsoft reports the root cause was addressed in this flight.

Technical interpretation and enterprise considerations​

The elevation flow involves multiple moving parts: User Account Control (UAC), token creation and impersonation, interaction between a non-elevated parent process and an elevated child, and any credential providers or enterprise hooks present on the machine. A deadlock or unhandled error in that handshake can block the UI thread or a critical process, resulting in a freeze. Fixes in this area are sensitive: they must avoid loosening elevation security while eliminating deadlocks. Enterprise testers should validate elevation scenarios in environments with third-party credential providers, custom sign-in hooks and security software that intercepts process creation. If the fix touches token handling or IPC, regression testing should include Windows Terminal, classic console apps and any custom terminals used in the organization.

Suggested validation steps​

• From a non-admin account, attempt to run Windows Terminal as administrator.
• Repeat with different shells configured in Terminal (PowerShell, CMD, WSL) to confirm no hangs.
• If possible, test with enterprise sign-in or credential providers present and monitor for hangs.
• Verify system event logs and any Windows Error Reporting entries if a hang was observed prior to the update.

---

The oddity: Share dialog listing Shell Experience Host​

A more cosmetic but confusing bug surfaced where the Share dialog could show Shell Experience Host as a share target — a system component not intended to be a recipient for user content. This is likely a mis-registered share target or incorrect filtering in the share-target discovery pipeline. The fix removes system components from the share list so only appropriate apps and targets appear. The impact is low from a data-safety standpoint but important for user confidence in the Share UX.

---

Known issue: desktop watermark shows wrong build number​

Microsoft notes a cosmetic known issue in which the desktop watermark displays the wrong build number. This does not affect functionality but can confuse Insiders who verify builds with winver; the official build string should still be viewable via the Winver dialog. Expect this to be corrected in a follow-up Canary flight.

---

How to get Build 28020.1371 and how to verify​

• Enroll the test machine in the Windows Insider Program and choose the Canary Channel.
• Open Settings > Windows Update and select Check for updates. The flight should appear as an Insider preview update (KB5073097) if Microsoft has enabled your device for the roll-out.
• After installing, confirm the build via Win + R → winver to display the OS build string.
• Validate the specific behaviors (Start pinned-folder, File Explorer navigation, keyboard repeat delay, Terminal elevation) using the test steps described in each section.

---

Critical analysis — strengths, risks and implications​

Strengths​

• Targeted remediation: The flight emphasizes quick fixes for high-feedback areas rather than introducing new complexity, which is a pragmatic Canary strategy. Addressing a freeze that occurs during elevation is particularly important and shows Microsoft is triaging high-severity reports.
• Rapid iteration model: Canary’s fast cycles allow Microsoft to test low-risk, high-impact fixes quickly and gather telemetry before wider roll-out. This keeps the servicing baseline for mainstream channels less noisy.

Risks and caveats​

• Canary instability and partial exposure: Canary is inherently experimental. Features and fixes can be server-gated; simply installing the build doesn’t guarantee exposure to every change. This complicates validation: testers must focus on behavior, not just build numbers.
• Regression potential: Even small shell and compositor fixes can introduce new rendering or input regressions across mixed DPI, multi-monitor, or specialized hardware setups. Regressions that affect input, windowing or elevation flows have outsized impact on productivity and system stability.
• Enterprise risk for elevation fixes: The Terminal elevation hang fix is welcome, but environment-specific factors (credential providers, enterprise hooks, security agents) can expose different edge cases. Organizations should not push Canary to production hardware and must stage tests in representative environments.

What remains unverifiable​

• Microsoft’s short flight notes do not publish low-level root-cause analysis (e.g., exact call stacks or the specific line change). Any detailed assertion about precise code paths or the exact internal state transition that caused the Start-folder invisibility or Terminal deadlock would be speculative without a confirmed Microsoft debug write-up or public bug-trace. Those deeper claims should be treated as plausible technical interpretations rather than confirmed facts. Flagged as unverified.

---

Recommendations (for Insiders, IT teams and power users)​

• For hobbyists and early adopters: install on a dedicated test machine or VM. Validate the specific behaviors you care about and report any regressions via Feedback Hub with detailed repro steps and traces.
• For IT administrators: do not deploy Canary builds on production devices. Use lab/homologation machines that mirror enterprise configurations, especially machines with custom credential providers or security agents, to validate the Terminal elevation fix before considering broader rollout of any future servicing update that includes related changes.
• For accessibility and input-sensitive users: after updating, validate keyboard repeat delay and other input preferences across devices and assistive software. Submit issues with concrete reproduction steps when behavior differs from Settings values.

---

What to watch next​

• Flight Hub and Microsoft’s Update Catalog for a formal KB entry (KB5073097) showing up with an expanded changelog and any follow-up notes.
• Feedback Hub and the Windows Insider community for reports of regressions or confirmation that the fixes solved the reported problems across a diverse hardware base.
• Subsequent Canary flights, which may include fixes for remaining cosmetic problems (like the watermark build number) or roll out the same corrections more broadly if telemetry is positive.

---

Bottom line​

Build 28020.1371 is a compact, pragmatic Canary flight that addresses several real-world pain points in the Windows shell: a disappearing pinned Start folder, a jarring File Explorer refresh artifact, a misreported keyboard repeat delay, and a severe elevation hang affecting Windows Terminal launched from non-admin accounts. These corrections improve day-to-day reliability for Insiders and show Microsoft actively triaging high-severity issues. However, Canary remains experimental — the fixes are welcome but should be validated on test hardware, and enterprise teams must maintain caution until similar fixes surface in Release or Beta channels. If you rely on Start pins, frequent file navigation, or Terminal elevation workflows, validate the fixes on a non-production machine and file feedback if behavior persists.

---

Source: Neowin https://www.neowin.net/news/windows...nu-file-explorer-and-more-in-build-280201371/