Microsoft dropped Canary build 27943 today, and while it patches several everyday annoyances—hung storage scans, duplicate taskbar previews, and flaky HDR—two showstopping regressions demand immediate attention. The build delivers a small set of fixes that improve the Windows Insider experience, but the official changelog flags repeated install rollbacks with error 0xC1900101 and an Arm64-specific kernel crash bug that can green-screen devices with IRQL_NOT_LESS_OR_EQUAL. These aren't minor glitches; they're hard blockers for anyone who values uptime.

The fixes that make the cut

Build 27943 addresses a handful of real-world pains that Insiders have been flagging for weeks. Microsoft's changelog, confirmed by hands-on reports from the Canary corridor, details these improvements:

Storage Settings scanner no longer hangs

The Settings > System > Storage > Temporary files page had a reproducible freeze that stalled when enumerating temporary content. That hang also suppressed the "Clean up previous Windows installations" entry, blocking Insiders from reclaiming multi-gigabyte artifacts left behind by earlier builds. Power users routinely rely on that one-click cleanup to free space after an upgrade; its disappearance forced deeper dives into DISM or third-party tools. The fix restores the full scanning path so the cleanup option surfaces reliably. For anyone managing test VMs or multi-boot setups, this is more than a cosmetic patch—it recovers a safe, predictable way to shed installation leftovers without touching the command line.

Taskbar thumbnail duplication squashed

A strange visual glitch produced duplicate preview thumbnails when hovering over a minimized app after switching virtual desktops. The extra thumbnail flickered into view and then vanished, muddying the taskbar's at-a-glance clarity. The build eliminates that ghost image, tightening the multitasking experience for users who juggle multiple desktops. Small UI fixes like this accumulate to define perceived polish, especially on devices with many windows open.

HDR toggling now sticks

Several Insiders reported that enabling HDR in Settings would immediately flip back to SDR, requiring multiple attempts or a full restart to keep HDR on. That regression broke workflows for color-critical creators and gamers who depend on accurate display profiles. Build 27943 ensures the toggle remains active after a single click, restoring the intended behavior. Because HDR relies on a chain of display driver, EDID handshake, and OS compositing, Microsoft advises continued vigilance after upgrading—the fix is in the UI layer, but underlying driver interactions can still cause issues on specific hardware.

Pluton Event Viewer noise silenced

Devices with a Microsoft Pluton security chip were logging a spurious Event Viewer error 57 every boot: "The Microsoft Pluton Cryptographic Provider provider was not loaded because initialization failed." These entries generated false alarms for system administrators sifting through event logs for real threats. The build removes the noise, cutting down on unnecessary troubleshooting and clarifying the telemetry stream.

Smaller polish items

Enter now confirms a PIN when casting from Quick Settings, a fix for those who stream presentations or media to nearby screens. Group Policy Editor rendering errors with Chinese display language—large blank areas and garbled layout—also received a correction, aiding admins who manage policies in multi-language environments.

The showstopping regressions

Despite the polish, two known issues in this flight make it dangerous for daily drivers. Microsoft flags both prominently in the release notes, and the Canary community has echoed the warnings.

Install rollbacks: 0xC1900101-0x20017 and 0xC1900101-0x30017

The 0xC1900101 error family signals that Windows Setup hit a driver or firmware incompatibility during the SafeOS boot phase. In this build, the rollback isn't a one-off fluke. Microsoft explicitly states that affected devices will repeatedly roll back, even after retrying, and that investigation is underway. Troubleshooting logs—Setuperr.log and Setupact.log from %windir%\Panther—typically point to the offending driver, which could be tied to storage controllers, encryption software, or USB peripherals. Standard mitigation includes disconnecting all non-essential devices, removing third-party antivirus and disk encryption, and updating BIOS and drivers before attempting the upgrade. But this time, even clean boots have not universally cleared the block, suggesting a deeper issue in the migration engine. Until a corrective patch arrives, this build is a no-go for any machine where failure isn't an option.

Arm64 IRQL_NOT_LESS_OR_EQUAL bugchecks

Another new blocker targets Arm64 PCs. The IRQL_NOT_LESS_OR_EQUAL stop code (bug check 0xA) means kernel-mode code touched memory it wasn't supposed to, often due to a bad driver paging operation or a NULL pointer dereference at high IRQL. On Arm64 hardware, platform firmware and driver maturity vary more widely than in the x64 ecosystem, so such regressions can appear suddenly. A green screen in this context is a full system crash that can corrupt data and force a power cycle. Microsoft is working on a fix, but for now, any Arm64 daily driver is at risk. Test rigs with full disk images are the only safe landing pads.

GPU capture playback broken for developers

PIX on Windows, Microsoft's tool for profiling and debugging DirectX applications, cannot replay GPU captures on build 27943. The capture format depends on tight alignment between OS build, GPU driver, and PIX version. Microsoft estimates a PIX update by the end of September, but that's a target, not a guarantee. In the interim, developers who rely on PIX for shader analysis or performance tuning must either stay on an older Windows build or use the DirectX Discord or feedback channels to request private builds. Graphics flickering in browsers, flagged separately, compounds the nuisance for GPU debugging, though it affects a broader set of users and is under separate investigation.

Audio and graphics: additional friction

Beyond the highlighted regressions, audio driver corruption and screen flicker remain active investigations. On some Canary machines, audio stops working entirely and Device Manager shows yellow exclamation marks on devices like "ACPI Audio Compositor." The workaround—manually selecting a known driver from the local list via "Update driver" > "Browse my computer for drivers" > "Let me pick"—can restore sound, but the root cause is a driver-OS interaction that Microsoft hasn't pinned down. Owners of affected devices will find themselves repeating the procedure after each boot or upgrade attempt. Screen flickering, particularly in browsers, has also been reported, possibly tied to GPU scheduling changes in the Canary line.

Who should dare install build 27943?

Canary flights are experimental by design, but this one's rogues' gallery of blockers narrows the audience sharply. The following guidance distills Microsoft's notes and community vetting:

  • Production endpoints: Do not install. The rollback bug alone disqualifies it. Wait for a later flight that clears these issues.
  • Dedicated test hardware: Install only after creating a full system image and verifying recovery media. Expect potential downtime and data loss. It's a test build.
  • Arm64 devices: Avoid entirely until the IRQL regression is fixed. Even on non-critical hardware, a kernel crash can leave a machine unbootable without a recovery image.
  • GPU developers using PIX: Defer the OS upgrade or maintain a separate capture-analysis machine on a supported build. Relying on an estimated fix date is gambling with a development pipeline.
  • Power users curious about the fixes: If you have a sacrificial test rig and can afford to lose whatever is on it, go ahead. The storage and HDR fixes are tangible quality-of-life improvements, but the risks dominate.

Pre-flight checklist for the intrepid

If you ignore the warnings, at least follow these steps to minimize damage:

  1. Create a full disk image and ensure a bootable USB recovery drive is on hand.
  2. Export driver lists with pnputil /enum-drivers and note all third-party software.
  3. Update firmware, chipset drivers, and discrete GPU drivers to the latest OEM versions.
  4. Temporarily uninstall or disable third-party security suites, disk encryption, and virtualization software that hooks into storage or memory.
  5. Disconnect all non-essential USB and Bluetooth peripherals before launching setup.
  6. Pilot the build on the test machine for 48–72 hours before trusting it with any critical data.

Troubleshooting when things go wrong

Handling a 0xC1900101 rollback

  • Preserve the Panther logs immediately. Copy %windir%\Panther\Setuperr.log and Setupact.log to external storage before the system rolls back and potentially deletes them.
  • Analyze the bottom of Setuperr.log for the last operation that failed; this often reveals the driver or service that caused the safe-boot abort.
  • Perform a clean boot, disable all non-Microsoft services and startup items, and retry the upgrade with peripherals disconnected.
  • If the system becomes unbootable after rollback, use the recovery image to restore, not the built-in reset.

Fixing broken audio drivers

  • Open Device Manager, locate the device with the yellow exclamation mark (e.g., "ACPI Audio Compositor").
  • Right-click > Update driver > Browse my computer for drivers > Let me pick from a list of available drivers on my computer.
  • Select the most recent driver from the list and click Next. If no specific drivers appear and you see only common hardware types, the device is not related to this audio issue; seek separate remediation.
  • Repeat for every device showing an exclamation mark. Note that a Windows Update driver refresh may overwrite your selection in the future, so monitor after subsequent Canary builds.

PIX playback failures

  • Use the Send Feedback button in PIX to submit capture files and system details to the DirectX team. Include the build number, GPU driver version, and the DirectX Discord handle if applicable.
  • Consider requesting private PIX builds through the DirectX Discord or related insider channels. Maintain a separate analysis machine with a stable Windows version until official support resumes.

Enterprise and developer implications

Enterprises that validate Canary builds for early compatibility testing should avoid this flight entirely. A reproducible rollback that bricks an upgrade path is a non-starter for fleet management. Hardware vendors and driver developers, however, should pay close attention: the prevalence of 0xC1900101 in this build signals a possible shift in the migration engine's handling of SafeOS that could affect future feature updates. Partner coordination with Microsoft's driver validation teams is critical to resolve the incompatibility before it reaches broader rings.

For graphics tooling, this episode underscores the fragility of GPU capture workflows on insider builds. Teams that depend on PIX or similar profiling tools should budget for periodic OS-driven breakage and maintain a stable, parallel environment for analysis. Microsoft's PIX team has been responsive in the past, but the estimated September fix date is not a service-level agreement; developers relying on it should have a fallback plan.

The bottom line

Build 27943 is a quintessential Canary maintenance flight: it delivers targeted fixes that genuinely improve the Insider experience, yet it introduces regressions severe enough to make the build unusable for anyone who can't afford crashes and rollbacks. The storage scanner hang fix, the taskbar thumbnail cleanup, and the HDR toggle reliability patch are all welcome adjustments that show Microsoft is listening to feedback. However, the repeated 0xC1900101 install failures and the Arm64 kernel bugcheck override those gains for all but the most isolated test scenarios.

Microsoft's transparency in documenting these blockers is commendable, but the message is clear: Canary builds remain experimental plumbing exercises, not daily-driver candidates. For those who do jump in, backup discipline and a healthy tolerance for downtime are prerequisites. Everyone else should wait for the next flight, when the fix for the rollback and Arm64 crash finally lands. Until then, build 27943 is a compelling test subject—but only on hardware you can afford to lose.