Windows 11 Canary Build 27971 Adds Notification Center on Any Monitor

  • Thread Author
Microsoft's latest Canary build, Windows 11 build 27971, finally brings a long-requested convenience to multi-monitor users: the Notification Center can now be opened on secondary displays, allowing the calendar and a larger clock (including seconds) to appear on any monitor by clicking the date and time in that monitor's system tray.

A three-monitor setup on a wooden desk, with a calendar displayed on the right monitor.Background​

For years, Windows users with multi-monitor setups have cobbled together workarounds for a simple annoyance: the Windows 11 Notification Center and calendar have been tied to a single, primary display. That limitation forced users to move their mouse to the primary taskbar just to check the date, upcoming appointments, or glance at notifications. The change in build 27971 addresses a clear usability gap for power users, creators, and professionals who work across multiple screens.
This build is rolling out to the Canary channel of the Windows Insider program, after Microsoft previously tested the change with Dev and Beta channel Insiders. Alongside the multi-monitor Notification Center, the build includes a mix of practical fixes—File Explorer stability, lock screen media control behavior, input-API fixes for pen/handwriting—and a short list of known issues Insiders should be aware of.

What’s new in build 27971​

Notification Center on secondary monitors​

  • Open Notification Center from any monitor: Clicking the date/time in the system tray of any monitor will open the Notification Center on that monitor.
  • Calendar and larger clock: The calendar is now visible on any display, and there’s an option to show a bigger clock with seconds above the calendar.
  • Parity across monitors: The feature mirrors the primary-display experience so that critical items—notifications, quick actions, and the calendar—are accessible where users are actively working.
This is a straightforward quality-of-life improvement, but one with a large daily impact for multi-monitor users who frequently need quick access to time and schedule information without hunting for the primary taskbar.

Fixes included in this build​

  • File Explorer: Addressed a crash that could occur when transferring files to a network drive in recent Canary builds.
  • Lock and login screens: Fixed an issue where media controls might not display on the lock screen.
  • Input APIs: Resolved an underlying issue affecting pen and handwriting functionality that could cause apps to crash due to unexpected exceptions.
  • Other: Fixed problems causing protected content playback to fail in some apps, and addressed an issue preventing Hyper-V virtual machines with a Trusted Platform Module (TPM) from starting on ARM64 devices.

Known issues Insiders should note​

  • Settings: Settings may crash when accessing drive information under Settings > System > Storage. This also affects accessing drive information from a drive’s properties in File Explorer.
  • Start menu: New Start menu design may unexpectedly scroll to the top for Insiders using it.
  • Power and Battery: Reports indicate sleep and shutdown may not work correctly for some Insiders after recent Canary builds.

Why this matters: practical user impact​

Putting Notification Center on any monitor is a deceptively simple change with immediate, tangible benefits.
  • It reduces mouse travel and context switching for multi-monitor workflows, saving small amounts of time that add up throughout the day.
  • For creators and professionals who use a peripheral monitor as their main workspace, having the calendar and quick access to notifications on that display removes friction and improves situational awareness.
  • The option to show seconds on the clock is small but valuable for tasks that require precise timing (streaming, recording, live support, or time-sensitive workflows).
Beyond convenience, this is a signal that Microsoft is listening to long-standing requests from the Windows community and prioritizing multi-monitor ergonomics—a noticeable shift given how long the single-display limitation persisted.

Technical considerations and potential pitfalls​

While the change is welcome, there are several technical details and risks worth examining before Windows Insiders or enterprise teams adopt this build widely.

Implementation complexity​

Delivering system UI features across multiple displays is more complex than it first appears. The Notification Center and system tray are tightly coupled with the shell and explorer.exe; adding per-monitor instances requires careful handling of:
  • Per-display system tray and clock instances.
  • Focus and input routing so keyboard and pen inputs go to the correct window.
  • DPI scaling and per-monitor scaling consistency, especially when monitors have different DPIs and scale factors.
  • Visual composition with Desktop Window Manager (DWM) to ensure animations, shadows, and layering behave consistently.
Any of these areas can introduce regressions, especially in secondary workflows that aren't exercised in single-monitor setups.

Performance and battery implications​

  • The optional clock with seconds updates every second, which can increase CPU wakeups and GPU composition work, particularly on machines with many monitors or those running on battery-powered devices. Expect slightly higher power draw while this option is active, especially on laptops using external monitors.
  • Insiders who enable seconds on multiple monitors should monitor power usage and battery life impact; Microsoft often balances UI fluidity against energy consumption in subsequent builds.

DRM and protected content​

  • The build includes fixes for protected content playback, but per-monitor rendering changes can complicate DRM paths. Some apps rely on secure video pipelines tied to the primary display; extending UI functionality across displays can expose corner cases where playback fails or requires additional secure path handling.

Virtualization and ARM64 TPM interaction​

  • The build fixes an issue where Hyper-V VMs using a TPM would not start on ARM64 devices. This is significant for developers and organizations standardizing on ARM64 hardware or using Windows on Arm for testing.
  • However, virtualization and secure enclave interactions are fragile; enterprise teams should validate their VM provisioning workflows and attestation paths before declaring broad compatibility.

Input and pen/handwriting​

  • Fixes addressing unexpected exceptions in input-related APIs reduce app crashes when using pen and handwriting. Apps that implement custom handwriting or inking logic should retest these code paths across windows and monitors.
  • Per-monitor UI changes can expose race conditions in event handling or message routing, so developers should watch for regressions and ensure robust exception handling.

How to get and test build 27971 (Canary)​

This build is available to Insiders in the Canary channel. Because Canary builds are an early preview, they are intended for exploratory testing and feedback—not production use.
  • Join the Windows Insider Program and select the Canary channel in Settings > Windows Update > Windows Insider Program.
  • Check for updates and install build 27971 when it appears.
  • After installation, connect multiple monitors and ensure each monitor shows the taskbar and system tray.
  • Click the date/time in the system tray on a secondary monitor to open the Notification Center and verify:
  • The calendar displays on that monitor.
  • The option to enable the bigger clock with seconds appears and updates correctly.
  • Notifications and quick actions behave as expected.
When testing, try scenarios that often produce edge cases:
  • Different DPIs and scaling settings across displays.
  • Mixed landscape and portrait orientations.
  • Multiple displays connected via different interfaces (DisplayPort, HDMI, USB-C).
  • Use pen or inking input while the Notification Center is open on a secondary display.
  • Transfer files to network drives to verify File Explorer stability.
  • Start Hyper-V VMs with TPM on ARM64 hardware, if available.

Troubleshooting and mitigations​

If you encounter the known issues or other regressions, consider these mitigations while testing Canary builds:
  • Settings/Drive info crash: Avoid opening drive information from Settings or drive properties until a fix ships. Use Disk Management or command-line tools as a temporary alternative.
  • File Explorer crashes: If transferring large files to network drives triggers crashes, pause those operations and use robust copy tools (robocopy) or try transferring smaller batches.
  • Lock screen media controls: If media controls fail to display on the lock screen intermittently, confirm you have the latest audio drivers and related codecs installed; rebooting can sometimes restore expected behavior.
  • Sleep/shutdown problems: If sleep or shutdown behaves incorrectly, avoid leaving critical work unsaved and use the Feedback Hub to file detailed reports including repro steps and logs.
  • Start menu scrolling: If the new Start unexpectedly scrolls to the top, pin or reorganize frequently used pinned apps and avoid making Start menu changes that trigger scrolling until Microsoft patches the bug.
Always create a System Restore point and ensure recovery media or a full backup before installing Canary builds on production or primary work machines.

Enterprise and IT admin guidance​

For IT administrators and enterprise deployments, the guidance is clear:
  • Do not deploy Canary builds in production. Canary channel builds are early-stage and intended solely for testing and telemetry gathering.
  • Use dedicated test devices for functional, compatibility, and performance testing. Validate line-of-business applications, virtualization workflows, and device management policies against the build.
  • Pay particular attention to Hyper-V/TPM workflows on ARM64 if your environment uses Windows on Arm devices for development or thin-client roles.
  • Document test cases for per-monitor behavior, protected content playback, and input/pen scenarios so that desktop support and application owners can reproduce and sign off on fixes.
Enterprises should prioritize stability over new ergonomics. While the multi-monitor Notification Center will eventually benefit many users, widespread adoption should follow Beta or Release Preview channels after Microsoft stabilizes known regressions.

Developer and ISV implications​

Application developers and independent software vendors must consider the expanded surface area this change creates.

What to test​

  • Notification and toast handling: Ensure notifications display and route correctly when the Notification Center is opened from various monitors.
  • Input and focus events: Validate that keyboard focus and input context (pen/ink, mouse) behave as expected in multi-monitor scenarios.
  • DPI-aware rendering: Test apps with mixed-DPI configurations; per-monitor UI elements may now overlap or interact with system UI more often.
  • Protected media paths: For media applications using DRM, verify playback across displays and validate fallback behavior if secure pipelines fail.
  • Exception resilience: Given past input-related exceptions, apps must handle unexpected exceptions gracefully and avoid crashes from API changes.

Recommended developer actions​

  • Update test suites to include multi-monitor and mixed-DPI test cases.
  • Use defensive coding for APIs that handle system UI interactions or rely on the system tray.
  • Monitor telemetry and crash analytics for new patterns after the build becomes broadly available.
  • Provide clear guidance to users about known limitations and recommended workarounds where necessary.

Security and privacy considerations​

Adding system UI elements to multiple displays is unlikely to introduce direct security vulnerabilities, but a few indirect concerns deserve attention:
  • Screen privacy: Users who rely on a single primary display for sensitive notifications should be aware that notifications may now appear on other connected displays when the Notification Center is opened there.
  • Screen capture and secure content: Applications and services that rely on display-based secure paths must continue to validate that protected content cannot be captured or rendered via insecure pipelines on secondary monitors.
  • Telemetry and diagnostics: Canary builds collect telemetry to inform development; administrators should ensure telemetry collection aligns with organizational privacy policies when testing.

What to watch next​

Key indicators to monitor in upcoming Insider releases and eventual public builds:
  • Whether Microsoft enables the feature by default or leaves it as an opt-in for users who want the seconds clock or per-monitor Notification Center behavior.
  • Further fixes for the reported Settings crash, File Explorer stability, and power-related regressions.
  • How the feature propagates through Dev and Beta channels into a production release—timing and cadence will determine when mainstream users benefit.
  • Any additional per-monitor improvements (e.g., per-monitor quick settings, independent system trays, or per-display notification preferences).
These cues will inform whether the change is a quick usability tweak or part of a larger effort to make the Windows shell more multi-monitor friendly.

Conclusion​

Windows 11 build 27971 delivers a meaningful but overdue quality-of-life improvement: the Notification Center is now accessible from secondary monitors, complete with calendar visibility and an optional seconds-enabled clock. The change streamlines everyday workflows for users who rely on multiple displays and signals a renewed focus on multi-monitor ergonomics from Microsoft.
The build also addresses several important bugs—File Explorer crashes with network transfers, lock screen media control display issues, input API exceptions, protected content playback, and Hyper-V/TPM problems on ARM64—but retains a handful of known issues that warrant caution. Canary-channel status means the build is for testing, not production, and Insiders should proceed with backups and measured testing.
For daily users, the update reduces friction and improves convenience. For IT admins, developers, and enterprises, it highlights the perennial balancing act between feature velocity and stability. The recommendation is straightforward: test thoroughly, report issues with precise repro steps, and wait for Beta/Release Preview stabilization before broad deployment. The multi-monitor Notification Center is a welcome addition—one that, done right, quietly makes multi-display work less annoying and more efficient.

Source: Neowin Microsoft adds a long-overdue feature to Windows 11 taskbar in build 27971
 

Microsoft is reintroducing a small but meaningful convenience for multi‑monitor users with Windows 11 Insider Preview Build 27971 in the Canary Channel: Notification Center is now functional on secondary displays and the calendar flyout can optionally show a larger clock with seconds, while a handful of stability fixes address real‑world pain points — but Canary‑class risks and a few known regressions mean this is best viewed as an incremental quality‑of‑life update for testers, not a production rollout.

Dual-monitor Windows setup with a blue abstract wallpaper, keyboard and mouse.Background​

Windows 11’s initial redesign removed or altered several subtle interactions that long‑time Windows 10 users relied on, and one recurring complaint was the Taskbar behavior on multi‑monitor setups. Under the early Windows 11 model the secondary displays showed the date and time but lacked interactivity — clicking them didn’t open the Notification Center or the calendar flyout, forcing users to move back to the primary monitor to check alerts or the expanded clock. That friction became a high‑visibility usability gap for people who work across multiple screens.
Microsoft has been iterating on this area across Insider channels, restoring select Windows 10‑era behaviors while trying to preserve Windows 11’s cleaner default UI. Build 27971 continues that course: it restores Notification Center functionality to secondary monitors and provides an opt‑in larger clock that displays seconds inside the calendar flyout. At the same time, the build includes several fixes for recent stability issues and flags a set of known regressions Canary testers should watch for.

What’s new in Build 27971 (Canary)​

The headline features in Build 27971 are modest but practical — focused on usability and stability rather than dramatic new capabilities.
  • Notification Center on secondary monitors: Clicking the date/time area in the taskbar on a secondary display now opens the Notification Center and calendar flyout, matching the behavior on the primary display.
  • Optional bigger clock with seconds in the calendar flyout: A toggle in Settings lets you enable a larger clock (including seconds) above the date and calendar grid inside the Notification Center flyout. The option is off by default.
  • Multiple stability fixes: The build addresses several recent regressions, including a File Explorer crash when transferring files to a network drive, lock and login screen media control display problems, a pen/handwriting input regression tied to microsoft.ink.dll, a protected content playback failure, and an issue preventing Hyper‑V VMs with TPM from starting on ARM64 machines.
  • Known issues remain: Settings may crash when accessing drive information (Settings > System > Storage), the new Start menu can unexpectedly scroll to the top for some Insiders, and some Canary users report sleep and shutdown problems after recent flights.
These items reflect a pragmatic, user‑centered push: restore parity where users expected it, fix high‑impact crashes, and continue gathering telemetry before enabling wider rollout.

Why the Notification Center change matters​

For power users and knowledge workers who rely on two or more displays, the small interaction cost of moving the cursor to the primary monitor for every calendar glance or to dismiss a notification adds up into repeated micro‑interruptions. Restoring the ability to open Notification Center on the active screen removes that friction and improves flow.
Key practical benefits:
  • Less cursor travel: Stay in context on the active monitor. Check or dismiss notifications without switching displays.
  • Faster calendar access: View calendar events, start Focus sessions, or glance at a more detailed clock on whichever monitor you’re using.
  • Parity with prior behavior: The change restores an interaction many users expect from Windows 10, reducing the learning curve and potential annoyance when migrating to or testing Windows 11.
This is a usability change rather than an engineering overhaul; nevertheless, its impact is disproportionately large for daily workflows.

How the bigger clock with seconds works (and how to enable it)​

The new clock option is intentionally opt‑in. Microsoft preserved the minimal taskbar look for default users while offering a place to surface second‑level precision for those who need it.
To enable the bigger clock with seconds inside the Notification Center (calendar flyout):
  • Open Settings.
  • Go to Time & language > Date & time.
  • Look for the toggle labeled Show time in the Notification Center and switch it on.
  • Click the date/time in the taskbar (or press Win+N) to open the Notification Center and confirm the larger clock (HH:MM:SS) appears above the calendar.
Notes and caveats:
  • The toggle appears only on machines where the feature has been activated; Microsoft uses staged rollouts and server‑side gating, so not every device on the same build will show the option immediately.
  • Enabling the clock here does not force seconds onto the taskbar itself; it only changes the expanded Notification Center flyout. This preserves a clean taskbar while providing detailed time when you intentionally open the flyout.
  • If the toggle is not present, the feature may still be gated for your device. Avoid using unsupported hacks to enable hidden flags unless you fully understand the risks of manipulating internal feature gates.

Fixes included — what they mean for users and admins​

Build 27971 bundles several targeted fixes that address recent, disruptive regressions:
  • File Explorer crash when transferring files to network drives: This was a high‑impact bug for users who work with NAS or SMB shares; fixing it reduces data‑movement interruptions and lowers the risk of lost context during transfers.
  • Lock and login screen media controls: Media controls that fail to display break playback control when the device is locked or at the sign‑in screen. The fix restores expected behavior, improving media usability.
  • microsoft.ink.dll pen/handwriting regression: An underlying API issue was causing pen and handwriting input to fail or apps to crash. The update stabilizes pen input, which is important for Surface and other stylus users, as well as accessibility workflows.
  • Protected content playback failure: Fixing this prevents certain DRM‑protected streams or applications from failing to play content, a critical issue for apps that rely on HDCP or other content protection paths.
  • Hyper‑V virtual machines with TPM on ARM64: The patch addresses VM boot failures for ARM64 devices using a Trusted Platform Module, which is significant for developers and testers running virtualized environments on ARM‑based hardware.
For IT administrators, the fixes reduce immediate headaches for device fleets that participate in Insider testing. However, the Canary Channel is early and experimental; organizations should avoid deploying Canary builds broadly and instead validate fixes in controlled test environments first.

Known issues and risks to watch​

Microsoft candidly lists several known issues in this Canary flight. These are important because Canary builds are inherently experimental and meant to expose issues early.
  • Settings may crash when accessing drive information: Navigating to Settings > System > Storage or viewing drive properties in File Explorer may crash Settings. This indicates lingering regressions in the storage‑info plumbing and can disrupt routine maintenance tasks.
  • Start menu scroll regression (new Start): Some Insiders testing the new Start menu report that it may unexpectedly scroll to the top. This is a UI annoyance that can hinder discoverability or navigation in pinned apps and recommendations.
  • Sleep and shutdown problems under investigation: Reports of devices failing to enter sleep or not shutting down correctly after recent Canary builds have surfaced. These are high‑impact issues that can affect battery life, remote management, and user confidence.
  • Canary instability: Beyond the listed items, Canary builds may include regressions not yet catalogued. Back up data and avoid Canary on mission‑critical devices.
Mitigation and precautions:
  • Use Canary builds only on expendable test hardware or VMs.
  • Create full system backups or snapshots before upgrading.
  • Track Feedback Hub reports and Microsoft’s Insider blog for fixes and guidance.
  • If you encounter the Settings crash, avoid the specific path and use alternative tools (e.g., Disk Management or PowerShell) to fetch drive info until a fix arrives.
  • For sleep/shutdown regressions, consider reverting to the previous flight via a clean install, or pause Insider builds while troubleshooting.

What this tells us about Microsoft’s approach​

Several broader patterns are visible in this release:
  • Incremental restoration and responsiveness: Microsoft continues restoring select Windows 10 behaviors based on user feedback rather than a wholesale UI rollback. The opt‑in clock with seconds is a compromise that respects both minimalism and power‑user needs.
  • Staged feature delivery: Features are being shipped to Insiders behind toggles and server‑side gating. This reduces risk by allowing Microsoft to monitor telemetry and user feedback before enabling features widely.
  • Quality focus on high‑impact regressions: The bug fixes in this build prioritize issues that break common workflows (File Explorer transfers, pen input, VM boot failures). This indicates a focus on reducing tester friction ahead of broader stabilizations.
  • Channel complexity remains: Canary, Dev, Beta, and Release Preview all receive different flights and sometimes the same feature lands in different channels at different times. This staggered model complicates QA for ISVs and IT admins who must plan compatibility testing across channels.

Practical guidance: how to get the build, check for the feature, and report issues​

  • To receive Canary builds, opt into the Windows Insider Program and choose the Canary Channel. Note that switching between channels may require a clean install under certain circumstances.
  • After installing Build 27971, check Settings > Time & language > Date & time for the Show time in the Notification Center toggle to enable the seconds clock.
  • If the toggle is absent, the feature may be server‑gated; be patient or check other Insider channels if you need the behavior sooner.
  • Use the Feedback Hub (Win+F) to file reproducible bug reports. Include repro steps, screenshots, and system details for the fastest response.
  • For enterprise testing, stage the build on a small set of non‑critical systems and validate common workflows: file transfers to network shares, pen input, protected playback, and Hyper‑V boot scenarios on ARM64 devices.

Developer and enterprise implications​

  • Developers: The fix to Hyper‑V VM startup with TPM on ARM64 is particularly relevant for developers targeting ARM‑based devices or using virtualized test benches. Ensuring VM images and dev toolchains boot reliably is crucial for cross‑platform development.
  • Independent software vendors (ISVs): Staged UI changes can affect UI automation tests and accessibility flows. ISVs should monitor Insider channels, update automation scripts, and test for layout and focus regressions caused by Notification Center or Start menu tweaks.
  • IT administrators: Canary Channel builds are unsuitable for production fleets. However, the fixes in 27971 signal issues to watch in preproduction testing (storage info crash, sleep/shutdown regressions). Administrators should coordinate Insider testing with their application and driver vendors to catch regressions early.

The risk/reward calculus for enabling the new features​

This update embodies a familiar trade‑off:
  • Reward: Restored multi‑monitor parity and an opt‑in seconds clock offer immediate, tangible productivity improvements. The bug fixes tackle high‑pain regressions that were impeding key workflows.
  • Risk: Canary Channel instability and outstanding known issues mean testers may encounter crashes, UI oddities, or power management problems. The feature’s staged rollout also creates device‑to‑device inconsistency.
Recommendation: try Build 27971 if you are a Windows Insider who wants early access and can accept some instability. For production machines, continue to wait for features to reach the Beta/Release Preview channels and for the known issues to be resolved.

What to expect next​

Microsoft’s pattern suggests the multi‑monitor Notification Center and the optional seconds clock will continue rolling out through Insiders while telemetry informs changes. The company is likely to:
  • Broaden the rollout if telemetry is positive and no regression spikes appear.
  • Backfill fixes for the listed known issues in subsequent Canary flights.
  • Migrate successful changes to Dev/Beta and then to broader preview channels before general availability.
Because features are server‑gated, patience will be required: installing the build does not guarantee immediate feature activation for every device. The restoration of long‑requested behaviors suggests Microsoft is responsive to community feedback, but the precise timeline for broad availability depends on telemetry and bug resolution.

Final takeaways​

Build 27971 is a focused, practical update that restores an expectation many multi‑monitor users had: the ability to manage notifications and view a larger, second‑accurate clock from any display. Coupled with several important fixes — from File Explorer stability to pen input and VM boot reliability — the build represents progress toward smoothing Windows 11’s rough edges.
However, the Canary Channel label is not incidental. Insiders should balance the productivity gains against the increased likelihood of regressions and follow prudent testing practices: backup, snapshot, and restrict Canary to non‑critical systems. For enterprises and cautious users, waiting for the change to propagate to Beta or Release Preview channels is the safer route.
The update is small in scope but high in daily utility: for multi‑monitor power users, it restores a glancing behavior that removes friction; for Microsoft, it’s another step in the long process of refining Windows 11’s UX while responding to community feedback.

Source: Windows Report Windows 11 Canary Build 27971 Brings Bigger Clock With Seconds to Notification Center
 

Back
Top