Windows 11 Canary Build 27954 Fixes SMB v1 NetBT Regression; Arm64 Bugs and PIX Issues

Today’s Canary-channel release of Windows 11 Insider Preview Build 27954 is a focused maintenance flight that fixes a handful of platform regressions while flagging a small set of high‑risk known issues that Insiders and developers must weigh before installing on active hardware.

Background / Overview​

Microsoft released Build 27954 to the Canary Channel as a narrow quality update, not a feature sweep. The public notes describe a concise set of general improvements and targeted fixes intended to improve stability for early testers. On the surface the build looks modest, but it includes an important networking fix affecting legacy SMB v1 over NetBIOS (NetBT) topologies, plus two known issues that matter to specific audiences: an increase in kernel bugchecks (green screens) on some Arm64 devices with error IRQL_NOT_LESS_OR_EQUAL, and a compatibility gap that prevents PIX on Windows from playing back GPU captures on this OS version.
The Canary Channel remains an experimental lab: builds here can change rapidly, contain short‑lived experiments, and are intentionally volatile. This flight demonstrates that pattern—small but surgical fixes, accompanied by a handful of developer‑focused regressions Insiders should treat seriously.

---

What’s included in Build 27954​

Changes and improvements (summary)​

• A small set of general improvements and reliability fixes intended to smooth the Insider experience.
• A networking fix addressing failures to access shared files and folders when using SMB v1 over NetBIOS over TCP/IP (NetBT) after recent updates.

These changes reflect the Canary Channel’s priority: quickly correcting regressions or small usability defects rather than shipping broad user-facing features.

Networking fix — SMB v1 over NetBT​

One of the most operationally significant items in this release is a fix for a regression where devices using SMB v1 over NetBT could no longer connect to shared files and folders after recent updates. While SMB v1 is deprecated and discouraged for security reasons, it remains in use in many legacy environments (older NAS appliances, legacy printers, and industrial devices).

• The practical impact: systems that rely on NetBIOS name resolution and SMB v1 could see interrupted file sharing between endpoints where one or both have been updated.
• The pragmatic mitigation used previously and recommended in the interim: allow SMB traffic to flow over direct TCP on port 445, which forces modern SMB transport and avoids the NetBT regression for many topologies.

This fix removes a blocker for environments that still rely on SMB v1 for legacy interoperability, but it also serves as a reminder that maintaining outdated network protocols increases operational risk.

---

Known issues and who they affect​

Arm64 kernel bugchecks (IRQL_NOT_LESS_OR_EQUAL)​

• Symptom: Some Insiders using Arm64 PCs may see an increase in bugchecks (green screens) with the error IRQL_NOT_LESS_OR_EQUAL while running recent Canary builds.
• Scope: Kernel‑level crash on Arm64 hardware. This is a severe class of failure because it can interrupt running workloads, risk data loss, and corrupt long‑running processes.
• Guidance: Arm64 owners — particularly those using Copilot+ Snapdragon devices and other Arm‑based PCs — should avoid installing this Canary build on any machine used for production or important work until Microsoft ships a targeted fix.

Why this matters: Arm64 is increasingly common in lightweight notebooks and developer machines. Kernel interrupt faults typically indicate a timing, driver, or low‑level code path regression; until the root cause is identified and patched, affected devices should remain on a safer Insider channel or stable builds.

PIX on Windows — GPU capture playback incompatibility​

• Symptom: PIX on Windows (the Microsoft GPU capture and performance analysis tool) is unable to play back GPU captures on this OS version.
• Impact: Game developers, driver engineers, and performance analysts that rely on PIX for frame‑accurate GPU traces will be blocked from using their standard workflow on machines upgraded to this build.
• Microsoft’s position: The PIX team plans a release to restore playback compatibility; the timeline provided in the release notes is an estimate and should be treated as provisional.

Interim options: If PIX playback is essential, developers are advised to:

• Keep a dedicated analysis machine on a supported channel, or
• Use private PIX builds provided by the team when requested via PIX feedback/reporting channels.

Because PIX workflows are critical to GPU pipeline validation, this incompatibility is a show‑stopper for developers who do not maintain an alternate test environment.

---

Technical context — SMB v1, NetBT, and the port‑445 workaround​

SMB historically supported two transport models:

• NetBIOS over TCP/IP (NetBT), which uses NetBIOS names and can run over ports 137–139 and additional NetBT plumbing, and
• Direct SMB over TCP using port 445, which is the modern transport for SMBv2/v3 and can also be used for SMBv1 if configured.

The regression fixed in Build 27954 affected scenarios where SMB v1 traffic was being carried over NetBT topologies. Allowing direct TCP on port 445 forces SMB to bypass NetBIOS/NetBT handling and route traffic over the direct TCP stack, restoring connectivity in the short term.
Operational guidance:

• Treat the port‑445 mitigation as a temporary workaround when coordinating patching across mixed environments.
• Prioritize migrating devices and services away from SMB v1 to SMB v2/3, both for security and compatibility.
• If your environment cannot immediately move away from SMB v1, plan a careful validation window for allowing TCP/445 due to network firewalling and security policy implications.

Security note: Enabling direct TCP (port 445) may expose services in environments where firewalling previously blocked SMB; work with security teams to ensure access controls and segmentation are in place.

---

Who should—and should not—install Build 27954​

This Canary flight is targeted and low‑risk if you meet certain criteria, but still inappropriate for production systems.
Install if:

• You run dedicated test hardware or virtual machines specifically for Insider testing.
• You are a developer or engineer who needs to validate the specific networking fix and can absorb the risk of other Canary regressions.
• You maintain alternate hardware for development and can preserve a separate PIX‑compatible environment (if you rely on PIX).

Do not install if:

• The machine is your daily driver, used for production work, or contains irreplaceable data (especially on Arm64 devices due to known kernel bugchecks).
• You rely on PIX on Windows for regular GPU analysis and do not have backup tooling.
• You are managing corporate fleets or production endpoints — Canary is not suitable for production validation.

---

Recommended preparation and a step‑by‑step checklist​

Before enrolling a device in the Canary Channel or installing Build 27954, perform these steps to reduce risk:

• Create a full image backup of your system disk (disk image or virtual machine snapshot).
• Export critical personal data and configuration (documents, browser profiles, 2FA keys if using local storage, etc.).
• Ensure you have bootable recovery media and a recovery plan for full restore if a rollback or crash leaves the device unbootable.
• Update firmware (UEFI/BIOS), storage controller firmware, and OEM drivers where available.
• For developer machines that depend on PIX: either postpone upgrade until PIX compatibility is confirmed, or keep a second device on a supported channel for profiling.
• If you still run SMB v1 devices in production, coordinate the port‑445 workaround through network/security teams before enabling it broadly.
• If you run Arm64 hardware: defer this build until Microsoft declares the Arm64 bugcheck fix is available.

Perform these validation steps after updating:

• Exercise file shares, RDP multi‑monitor sessions, printing paths, and any hardware‑specific workflows for 48–72 hours.
• If you encounter issues, collect logs (Setup logs, Event Viewer entries, minidumps) and file detailed reports via Feedback Hub so Microsoft can triage with signal.

---

Developer and enterprise considerations​

For game developers and GPU teams​

PIX incompatibility is the primary developer concern in this build. Because PIX captures and playback are central to frame‑by‑frame GPU diagnostics, teams should:

• Delay migrating critical performance validation systems to Canary builds.
• Use isolated VMs or secondary machines to validate Canary behavior while preserving a PIX‑enabled workstation for development and profiling.
• If immediate assistance is required, use PIX’s feedback channels to request private builds or guidance from the PIX team.

For enterprise IT and sysadmins​

• Avoid Canary flights on managed endpoints. Canary builds are experimental and can introduce regressions that impact enterprise workflows.
• If you need to validate the SMB fix or other narrow behaviors, isolate test devices within segmented lab networks and follow corporate change control procedures.
• Use Release Preview or Beta channels for broader pilot deployments where possible; those channels offer a better compromise between early access and stability.

Channel switching and rollback considerations​

• Moving off the Canary Channel to a channel with lower build numbers requires a clean install of Windows 11.
• Canary builds are not matched to final product releases; some features experimented on in Canary may be removed or never ship to general availability.
• Keep the desktop watermark and other Canary identifiers in mind when validating user‑facing behaviors; these are expected and normal for pre‑release builds.

---

Risk matrix — what to watch for over the next update cycles​

• Arm64 kernel regressions (IRQL_NOT_LESS_OR_EQUAL) — High risk for Arm64 daily drivers and long‑running workloads. Prioritize a patch from Microsoft before upgrading production Arm‑based machines.
• Toolchain breakage (PIX playback) — High risk for developers who rely on GPU capture analysis; impact mitigated by private PIX builds or holding off on upgrades.
• Legacy network topologies (SMB v1 + NetBT) — Medium operational risk where legacy devices remain in use; the port‑445 workaround helps but requires firewall/security coordination.
• Installer rollback or driver incompatibilities — Medium risk in Canary due to driver interactions; ensure backups and be prepared to restore images.
• Feature volatility — Low to medium risk for general Insiders; expect features and UI experiments to come and go without guaranteed release timelines.

---

Critical analysis — strengths and potential pitfalls​

Strengths of Build 27954​

• Surgical fixes: The release focuses on targeted, high‑impact regressions rather than broad, risky feature additions. That approach reduces noise and quickly improves testability for select scenarios.
• Operational pragmatism: Addressing the SMB v1/NetBT regression recognizes real‑world legacy environments and reduces operational friction for those Insiders still testing legacy integrations.
• Clear developer communication: Microsoft’s acknowledgment of PIX playback issues and a stated plan to ship a resolution gives developers a visible remediation path—even if the timeline is provisional.

Potential pitfalls and risks​

• Canary volatility remains: Even small maintenance flights can surface new regressions elsewhere in the stack. Insiders must treat Canary machines as disposable test rigs.
• Arm64 regression severity: Kernel bugchecks are inherently disruptive. Without an immediate fix, Arm64 owners face unacceptable risk if they install this build on production devices.
• PIX timeline uncertainty: Roadmaps that reference “end of month” deliveries are estimates. Teams should treat such timelines as provisional and plan contingencies.
• Legacy protocol reliance: The recurrence of SMB v1 problems is a symptom of long‑running technical debt in enterprise networks. Relying on temporary workarounds delays necessary migrations to more secure SMB versions.

---

Practical recommendations (short list)​

• Backup first: Full disk image + exported critical data.
• Keep Canary on test devices only — avoid upgrading laptops and workstations you rely on daily.
• Arm64 owners: wait for the fix; do not install this build on mission‑critical Arm hardware.
• Developers using PIX: maintain a PIX‑able environment on non‑Canary builds, or request private PIX builds if blocked.
• Network teams: use port‑445 workaround sparingly and plan SMB v1 migration as a priority.
• File Feedback Hub reports with logs and traces to accelerate Microsoft’s triage — structured data matters.

---

Conclusion​

Windows 11 Insider Preview Build 27954 is a pragmatic, low‑footprint Canary release that cleans up a couple of thorny problems while calling out a small set of high‑impact known issues. For Insiders who run isolated test rigs and those validating legacy SMB topologies, the build is worth testing; for Arm64 users and developers dependent on PIX, this flight is an explicit no‑go until Microsoft ships targeted fixes.
The Canary Channel continues to be Microsoft’s primary experimentation ground—fast, iterative, and sometimes unstable. That trade‑off is the channel’s point. The best approach for testers and IT teams remains conservative: prepare recovery plans, segment test hardware, and treat Canary builds as early warning systems rather than production fixes.

---

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

 

[ChatGPT]

Microsoft’s latest Canary-channel build for Windows 11 promises a smoother, more reliable Insider experience—but the small changelog masks a mix of targeted fixes, ongoing risk areas, and developer tooling gaps that Insiders should treat with careful optimism and a plan for mitigation.

Background​

Microsoft released Windows 11 Insider Preview build 27954 to the Canary channel with a short, focused changelog that emphasizes a set of general improvements and a specific networking fix for legacy SMB v1 over NetBIOS (NetBT). The company frames the release as an overall quality-of-life update for Insiders in the Canary flight, noting several bug fixes and “underlying improvements” that are not fully disclosed in public notes. At the same time Microsoft acknowledged a couple of significant known issues: a rise in kernel bugchecks (blue screens) on some Arm64 devices, and a developer tooling regression where PIX on Windows is unable to play back GPU captures on that OS version until a PIX update ships. Community discussion and independent reporting show these points are the most consequential parts of the release for everyday Insiders, IT pros, and game/developer tool users.

---

What changed in Build 27954 (quick summary)​

• A set of small, general improvements meant to improve the experience of Insiders running Canary-channel builds.
• A targeted networking fix: resolved an issue where clients using Server Message Block version 1 (SMBv1) over NetBIOS over TCP/IP (NetBT) could fail to connect to shared files and folders following recent updates.
• Known issues called out by Microsoft:
• Some Arm64 PCs may experience increased bugchecks with the IRQL_NOT_LESS_OR_EQUAL stop code.
• PIX on Windows cannot play back GPU captures on this OS version; Microsoft expects to address this in a PIX release (timing referenced to a near-term update).

These points are short but consequential: the SMBv1 fix directly affects legacy networking scenarios, while the Arm64 and PIX issues impact system stability and developer workflows respectively.

---

Overview and context: Canary channel realities​

Why Canary matters​

The Canary channel is Microsoft’s earliest preview ring for Windows 11. Builds in this channel are the most experimental: they expose platform-level changes and feature experiments that may never ship to broad releases. Canary is intended for enthusiasts and developers who can tolerate instability in exchange for seeing Microsoft’s earliest work. Microsoft explicitly warns that features in Canary may be rolled back, modified, or never make it into a shipping release.

The trade-off: early access vs. risk​

Canary builds historically trade polish for speed. That pattern explains the short and targeted changelog of build 27954: Microsoft is shipping incremental fixes and telemetry-driven adjustments rather than feature rollouts. Insiders should treat these builds as testbeds, not production releases, and plan upgrades accordingly.

---

Deep dive: the SMBv1 over NetBIOS fix and what it means​

The problem​

After recent security updates earlier in the year, administrators and home users reported failures when connecting to SMBv1 shares over NetBIOS over TCP/IP (NetBT). The symptom was straightforward: attempts to reach legacy network shares (often older NAS devices, embedded Linux boxes, and retro hardware) failed, even when SMBv1 support remained installed. Microsoft acknowledged the issue and labeled it a known compatibility problem introduced by cumulative updates. Independent reporting tracked the same rollback/compatibility behavior across Windows client and server families.

The fix in build 27954​

Microsoft’s notes for the new Canary build explicitly state that the update “fixed an issue where you might not be able to connect to shared files and folders if you were using the Server Message Block (SMB) v1 protocol on NetBIOS over TCP/IP NetBIOS (NetBT) after the latest updates.” This is a surgical compatibility fix to restore access to SMBv1+NetBT scenarios while the long-term plan remains to encourage migration away from SMBv1.

Practical guidance and caveats​

• SMBv1 is obsolete and insecure; Microsoft has been deprecating it for years. The long-term solution is migration to SMBv2/SMBv3 or upgrading legacy devices that cannot support modern SMB. Multiple security advisories and IT posts stress that continuing to run SMBv1 is a risk.
• Temporary workarounds that have been recommended in the field include allowing direct-TCP SMB traffic on TCP port 445 to force connections off NetBT and onto SMB over direct TCP. This restores connectivity in many cases but is a network-configuration workaround rather than a security fix. Treat it as a stopgap, and apply it only in trusted network environments.
• Enterprise environments using very old devices should inventory SMB usage immediately and plan remediation or segmentation. Allowing SMBv1 traffic at network boundaries is a short-term triage step, not a long-term posture.

---

The Arm64 IRQL_NOT_LESS_OR_EQUAL bugchecks: severity, scope, and mitigation​

What Microsoft reported​

Microsoft listed a known issue that “some Insiders with Arm64 PCs” are experiencing an increase in bugchecks (the blue-screen stop code IRQL_NOT_LESS_OR_EQUAL) on recent Canary builds. This error indicates a kernel‑mode component attempted to access pageable memory at a raised interrupt request level and is frequently associated with device driver problems, platform firmware interactions, or other kernel code defects. Microsoft stated it is working on a fix.

Why this matters more on Arm64​

Arm64-based Windows devices (including Copilot+ and Snapdragon platforms) have a smaller driver and firmware ecosystem than x86 PCs. Drivers compiled or tuned for x86 may not have identical behavior on Arm64, and platform firmware differences can make certain kernel paths more fragile. An uptick in IRQL‑related bugchecks on Arm64 systems is significant because:

• Kernel bugchecks can corrupt user data and interrupt long-running tasks.
• They undermine confidence in using Canary builds for daily workflows on Arm64 devices.
• They signal possible regressions in drivers or kernel-mode platform code that need focused diagnostics and driver/firmware collaboration.

Practical recommendations​

• Avoid installing these Canary builds on Arm64 machines you rely on for productivity. Treat any Arm64 laptop or tablet as a test device only.
• If you already installed the build and see IRQL_NOT_LESS_OR_EQUAL crashes:
• Collect and submit Feedback Hub reports with attached minidumps.
• Use Windows’ built-in memory diagnostics and run SFC/DISM to rule out corruption as a first step; driver/firmware regressions are more likely but standard diagnostics are still recommended.
• If you must evaluate the build on Arm64, snapshot or backup the device first and avoid data-sensitive operations during testing.
• Watch for follow-up builds or advisories; Microsoft usually issues targeted fixes for severe kernel regressions in subsequent Canary flights.

---

PIX playback failure: developer tooling interruption and workarounds​

The issue​

Microsoft explicitly lists a developer tooling problem: PIX on Windows is “unable to play back GPU captures on this OS version.” PIX is Microsoft’s GPU capture and analysis tool used by game developers and driver teams. Playback requires tight compatibility between the capture metadata, GPU driver, and OS replay environment. When playback fails on a given OS build, it blocks the end-to-end capture/analysis workflow for developers. Microsoft indicated a PIX update will be released to address the regression.

Why this is serious for developers​

• Without reliable PIX playback, GPU capture analysis, frame debugging, and performance investigations are impeded.
• Driver teams and game developers depend on PIX for reproducible replays across GPUs and drivers.
• Delays in PIX updates can slow debugging cycles and temporarily reduce productivity for studios working on time-sensitive fixes.

Mitigations and practical steps​

• Microsoft recommended using the “Send Feedback” button in PIX or contacting the DirectX Discord for private builds or assistance until the public PIX release arrives. Developers who are blocked should follow those channels for access to interim PIX versions or private playback builds.
• If PIX playback is critical and cannot be postponed, avoid moving to the Canary build until the PIX update ships or use a separate machine for development that remains on a supported OS version.

---

What Microsoft left unsaid — the “underlying improvements” problem​

The build notes mention “other underlying improvements” that Microsoft did not disclose. That is standard practice for many preview releases—Microsoft will often lump telemetry-driven or engineering-level changes under an umbrella phrase when they are not user-facing or when they are iterative fixes that could be removed. While this is expected, it has implications:

• Undocumented “under-the-hood” changes may affect specific hardware or driver interactions unexpectedly.
• Insiders who run large, heterogeneous fleets should be prepared for surprise regressions and maintain conservative update practices on critical systems.
• The absence of full transparency is a trade-off: faster engineering cycles and more frequent builds in return for less granular public documentation.

This lack of disclosure is not necessarily malicious or negligent, but it increases the need for careful telemetry, logging, and feedback when you test Canary builds.

---

Community reaction and how insiders are responding​

Windows enthusiast forums and the WindowsForum community have repeatedly emphasized caution with Canary builds. Community threads highlight two major themes:

• Appreciation for Microsoft’s rapid bug fixes and iterative polish in Canary builds.
• Concern about running Canary on production machines, especially Arm64-based Copilot+ devices and when developer tooling like PIX is inoperable.

Many Insiders are adopting conservative tactics: using virtual machines or sacrificial test hardware, backing up critical data, and holding off on Canary updates for work-critical systems until a clean signal arrives that issues are resolved.

---

Risk checklist for Windows 11 Insiders considering build 27954​

• Risk: Kernel bugchecks on Arm64
• Severity: High for Arm64 user productivity; potential data loss.
• Action: Don’t install on daily-driver Arm64 devices; collect minidumps if you hit crashes.
• Risk: PIX playback regression for GPU captures
• Severity: High for graphics developers; medium for other users.
• Action: Hold off on upgrading development machines that rely on PIX, or request interim PIX builds via Microsoft channels.
• Risk: SMBv1 connectivity disruption for legacy devices
• Severity: Medium for environments still using SMBv1; low for modern deployments.
• Action: If you rely on SMBv1, apply Microsoft’s temporary mitigation (force SMB over TCP/port 445) and plan migration to SMBv2/v3.
• Risk: Undocumented low-level changes
• Severity: Low–medium depending on hardware diversity.
• Action: Use backups, collect diagnostic traces, and report issues via Feedback Hub.

---

Step-by-step mitigation and recommended workflows​

• Inventory devices and roles.
• Mark which machines are production, which are test, and which are development rigs.
• Tag Arm64 devices and GPUs used for development as high‑risk for this build.
• Backup before you upgrade.
• Create a full system image or ensure file-history / cloud backups are up to date.
• Use test hardware or virtual machines.
• Canary builds are best evaluated on isolated hardware or VMs to avoid surprise disruption.
• For SMBv1 environments:
• Apply the short-term workaround (allow TCP 445 to prefer direct-TCP SMB) only in trusted contexts.
• Plan migration: upgrade NAS firmware, replace devices that cannot support SMBv2/SMBv3, or segment legacy systems.
• For developers using PIX:
• Delay installing build 27954 on development machines until PIX playback is restored.
• If immediate testing is required, contact Microsoft via PIX feedback or the DirectX Discord to request interim PIX builds or guidance.
• Report issues effectively.
• Use Feedback Hub and include minidump files, reproducible steps, and device specifics (CPU architecture, driver versions, firmware versions).
• For driver and platform vendors, open coordinated vendor bug reports if you can reproduce hardware-specific behavior.

---

Strengths and positives in Microsoft’s approach​

• Focused fixes: The SMBv1 compatibility fix demonstrates Microsoft’s willingness to address high-impact compatibility issues even when they touch legacy, deprecated protocols.
• Openness about developer tooling regressions: Calling out PIX playback problems and giving a remediation timeline is responsible and helps developers plan.
• Canary’s value: For power users and developers who accept risk, Canary remains an essential channel to validate fixes and influence platform development through telemetry and feedback.

---

Risks and outstanding concerns​

• Stability on Arm64: Kernel-level bugchecks are a red flag when they affect a platform subset (Arm64) and should be treated as a priority fix area. Running Canary on Arm64 hardware that you need day-to-day remains high risk.
• Developer workflow interruption: PIX playback failures are more than an annoyance for developers; they interrupt debugging and performance analysis cycles, with knock-on effects to driver and game development timelines.
• Legacy protocol dependence: While Microsoft is justified in discouraging SMBv1, there is friction and business impact for organizations still reliant on ancient devices—these groups need migration plans and clearer long-term guidance.

---

Final verdict — who should install build 27954​

• Installers recommended:
• Enthusiasts and testers with disposable test hardware or virtual machines who want to validate the Canary stream and file Feedback Hub reports.
• IT pros who need to validate fixes for legacy SMBv1 in a controlled test network before rolling changes across enterprise fleets.
• Installers not recommended:
• Users who rely on Arm64 laptops/tablets for daily productivity.
• Game developers and driver teams reliant on PIX playback for debugging and performance tuning (unless interim PIX builds are available).
• Administrators with mission-critical SMBv1 infrastructure and no migration path.

---

Looking ahead: what to watch for​

• Subsequent Canary builds: Microsoft will likely push a follow-up Canary flight that addresses Arm64 bugchecks; Insiders should monitor Desktop watermark cycle notes and the Windows Insider blog for updated guidance.
• PIX release timing: Microsoft indicated a PIX release to restore playback—developers should watch the PIX dev blog or Microsoft engineering channels for the update and request private builds if blocked.
• SMBv1 long-term plan: Expect continued messaging from Microsoft to migrate away from SMBv1; organizations still reliant on SMBv1 must accelerate remediation strategies.

---

Conclusion​

Build 27954 is emblematic of the Canary channel’s role: quick fixes, iterative improvements, and public transparency about known issues. The SMBv1 compatibility restoration is a welcome, pragmatic fix for legacy environments, and Microsoft’s candor about PIX and Arm64 regressions helps affected users plan. However, the presence of kernel bugchecks on Arm64 and a broken developer workflow for PIX are significant practical concerns that make this build suitable only for test environments and not for production or development machines that cannot tolerate interruptions.
For Insiders who want to stay on the cutting edge, build 27954 delivers modest improvements and demonstrates Microsoft’s responsiveness. Those who need reliability should delay upgrading until the Arm64 stability issues are resolved and the PIX playback regression is fixed. In all cases, back up systems, isolate test devices, and file detailed feedback so Microsoft can iterate toward a safer, more stable Windows 11 experience.

---

Source: Neowin Microsoft promises it has improved user's experience on Windows 11 with latest build