New Windows 11 Group Policy: Make Print Screen Key Yieldable

Microsoft has quietly added a new Group Policy in recent Windows 11 preview builds that gives administrators explicit control over whether the Print Screen (PrtScn) key can be intercepted by third‑party applications — a setting surfaced as Make Print Screen key yieldable under Computer Configuration → Administrative Templates → Windows Components → File Explorer.

Background​

The Print Screen key has been a stable, decades‑old shortcut for capturing the screen, but Microsoft began steering that behavior toward the Snipping Tool in Windows 11 previews and stable updates starting in 2023. That shift — intended to modernize capture workflows and encourage use of an integrated, editable capture experience — caused friction for users and software vendors who relied on the legacy behavior or who registered their own global handlers for PrtScn.
In early 2026 preview builds Microsoft added the Group Policy named Make Print Screen key yieldable. The policy explicitly governs whether the OS will yield the PrtScn scan code to other applications that attempt to register global hotkeys or hooks. In practice, this provides a single administrative control to allow or block applications from hijacking PrtScn on a per‑machine basis, rather than relying on per‑user toggles, registry edits, or brittle application conflicts.
This article explains what the policy does, how it maps to existing configuration options, the technical mechanisms apps use to intercept keyboard input, and the practical, security, and manageability considerations IT teams should weigh before enforcing it across a fleet.

---

What the policy actually does​

How the setting appears to administrators​

• Policy name: Make Print Screen key yieldable
• Location in Local Group Policy Editor: Computer Configuration → Administrative Templates → Windows Components → File Explorer
• Visibility: Appears in recent Windows 11 Dev channel preview builds; requires gpedit.msc (Windows 11 Pro/Enterprise or equivalent) to view and set.

Plain‑language behavior​

• Enabled: The Print Screen key can be intercepted by applications. Third‑party screenshot tools and utilities are allowed to register handlers that take precedence over the OS’s configured screenshot behavior.
• Disabled: The Print Screen key is intended to retain its legacy behavior and not be intercepted. Windows will attempt to prevent applications from hijacking PrtScn.
• Not configured: System/default behavior applies. In many preview builds this default permitted third‑party interception; in other builds and releases the default may differ.

Two practical notes administrators should expect:

• Changes to the policy may require a restart (or at least a logoff/logon and restart of Explorer) for global hotkey registrations and low‑level hooks to be reset.
• The policy is machine‑level; it complements per‑user settings that have existed for the Snipping Tool integration.

---

How this maps to existing settings and registry keys​

Windows already exposed ways to change Print Screen behavior:

• Per‑user toggle in Settings: Accessibility → Keyboard → Use the Print screen key to open Snipping Tool (present on some builds and missing in others).
• Per‑user registry key: HKCU\Control Panel\Keyboard\PrintScreenKeyForSnippingEnabled (REG_DWORD). Value 1 enables Snipping Tool interception; 0 disables it.

The new Group Policy is a higher‑level, machine scope control. For managed environments, that has meaningful implications:

• If you set the Group Policy to Disabled, you can enforce legacy PrtScn behavior regardless of what users set under HKCU or which applications attempt to claim the key.
• If you need user‑level flexibility, keep policy Not configured and manage per‑user behavior via Settings or registry preferences distributed with logon scripts or Group Policy Preferences.

Administrators who use a Central Store for ADMX/ADML templates must update the central store with the ADMX files from the Windows build that introduced the policy; without the matching ADMX the setting won’t appear in Group Policy Management.

---

The technical picture: how apps intercept Print Screen​

Understanding how applications take over the Print Screen key clarifies what the policy can — and cannot — block.

Common interception techniques​

• RegisterHotKey API: Applications use user‑mode APIs such as RegisterHotKey to register global hotkeys. When an app registers a hotkey without modifiers, it can prevent other apps from seeing the keypress.
• Low‑level keyboard hooks (WH_KEYBOARD_LL via SetWindowsHookEx): Global hooks let an application receive keyboard events before they reach the target application. Hooks can swallow or reroute events if the hook procedure returns the appropriate result.
• DLL injection and thread hooks: More aggressive techniques inject code into other processes so hooks run in target process contexts.
• Kernel‑mode filter drivers: Device drivers that sit above the keyboard class driver (Kbdclass) can intercept every keystroke at a lower level than user‑mode hooks. These are powerful and can bypass user‑mode restrictions.
• Raw input or message interception: Applications can use Raw Input APIs or monitor window messages to react to certain key sequences.

Important limitations to keep in mind​

• User‑mode hooks and RegisterHotKey are visible to the OS and subject to timeouts and other safety constraints; badly behaved hook procedures are ignored if they exceed allowed processing windows.
• Kernel drivers and firmware can still capture keystrokes even if the OS refuses to yield the key to user‑mode handlers. The new Group Policy controls OS behavior for normal user‑mode interception channels, but it does not magically block malicious or privileged kernel code.
• Some hotkey registrations are stored in internal kernel/User objects (hotkey tables). Tools that read or manipulate those structures can detect registrations even when ETW instrumentation cannot.

---

Why Microsoft added this control​

There are three overlapping motivations behind exposing a machine‑level toggle for PrtScn yielding:

• Enterprise manageability: IT teams need a predictable way to enforce consistent input behavior across large fleets — for example, to ensure support tools using PrtScn work reliably, or to prevent unauthorized screenshot capturing in sensitive environments.
• Compatibility clarity: A central policy reduces the “which setting wins” confusion when a per‑user toggle, multiple third‑party apps, and OEM utilities all compete for the same key.
• Security and privacy: Limiting which processes can intercept a widely used screenshot key closes one convenient channel for data exfiltration (though it is not a comprehensive control).

The policy’s introduction acknowledges that the Print Screen key is now contested territory: an OS‑level convenience (Snipping Tool), a user preference, and a common integration point for many third‑party productivity and remote‑support tools.

---

Practical impacts for users and admins​

Benefits​

• Predictable behavior: Enabling the policy in a chosen state yields consistent keystroke handling across user sessions.
• Centralized control: Admins can enforce a secure posture for sensitive endpoints.
• Reduced app conflicts: Prevent accidental or undesirable app hijacking of PrtScn that breaks corporate workflows.

Downsides and trade‑offs​

• Potential workflow disruption: Many help‑desk, documentation, and training processes rely on third‑party screen capture tools tied to PrtScn. Locking the key can break those tools.
• Not a silver bullet for security: Kernel drivers, malicious firmware, and privilege escalation remain capable of capturing screen content.
• Support overhead: Users who lose their preferred behavior will call the help desk unless IT proactively communicates the change and provides alternatives.
• Fragmentation between Insider and production channels: The policy’s exact default and UI exposure may vary across Windows channels and versions, making testing essential before broad deployment.

---

Recommended deployment approach for enterprises​

If you manage devices and plan to use the new Group Policy, follow a controlled, test‑driven rollout:

• Inventory: Identify critical applications and workflows that expect PrtScn behavior (e.g., remote support tools, capture utilities, OneDrive/Share integrations, OEM utilities).
• Pilot: Apply the policy in a lab or pilot OU and test with key user personas. Confirm that applications register hotkeys or hooks as expected and verify behavior after logoff/logon and reboots.
• ADMX management: Update your Central Store with matching ADMX/ADML files from the target Windows build so the policy is visible in Group Policy Management.
• Per‑user fallbacks: If some users need Snipping Tool integration but you want to block third‑party capture, consider combining the machine policy with per‑user registry settings distributed via Group Policy Preferences or logon scripts.
• Communication: Notify users in advance with clear instructions about alternative shortcuts (e.g., Win+Shift+S, tools’ own hotkeys) and provide quick troubleshooting steps.
• Monitoring: Track support tickets and telemetry for capture related failures. If you use endpoint detection solutions, add monitoring for suspicious hotkey registrations or kernel driver installs.

---

Security, privacy, and compliance considerations​

What the policy helps mitigate​

• Quiet exfiltration via user‑mode screenshot tools that silently capture screen contents in the background.
• Accidental leakage caused by apps that aggressively claim PrtScn and disrupt established workflows.

What the policy does not prevent​

• Kernel‑level drivers and firmware that intercept keyboard input before the OS’s user‑mode policies can act.
• Malicious processes that take screenshots using other APIs or by reading frame buffers if they gain the necessary privileges.
• Insider threats with admin privileges who can change policies or install drivers.

Recommended complementary controls​

• Limit driver installation: Use Device Installation restrictions in Group Policy or MDM controls to block untrusted kernel drivers.
• Harden endpoint configuration: Restrict the set of allowed applications (application whitelisting) and use code integrity policies.
• Audit hotkey registrations: Where possible, monitor for unusual RegisterHotKey or low‑level hook activity as part of endpoint telemetry.
• Educate users: Explain why the policy exists and provide approved capture tools and procedures for sanctioned tasks.

---

Compatibility note: per‑user registry vs. machine policy​

Organizations should differentiate between per‑user preferences and machine policy:

• HKCU\Control Panel\Keyboard\PrintScreenKeyForSnippingEnabled remains a useful per‑user control for personal devices where central enforcement is not required.
• The Group Policy operates at the machine level and should be used when a predictable, administrative baseline is required.
• For mixed environments, consider Group Policy Preferences or logon scripts to keep user preferences aligned with machine policy where appropriate.

A common pattern is to use the machine policy set to Disabled in high‑security OUs while leaving client‑facing devices in Not configured, allowing users to keep comfortable behavior on their personal or non‑managed machines.

---

Troubleshooting and quick checks​

If users report unexpected Print Screen behavior:

• Confirm whether the Local Group Policy or domain GPO sets Make Print Screen key yieldable.
• Check the per‑user registry: HKCU\Control Panel\Keyboard\PrintScreenKeyForSnippingEnabled (0/1).
• Temporarily quit common capturers: OneDrive, ShareX, Snagit, Logitech/Logi software, and OEM utilities to see if behavior returns to legacy.
• Restart Explorer and/or the machine after changing policy or registry, as global handlers are often re‑registered at logon.
• If problems persist, check for third‑party kernel drivers or unusual device drivers with driver signing or inventory tools.

---

Real‑world scenarios where this matters​

Help desk and remote support​

Many remote support tools rely on predictable capture behavior for diagnostics and documentation. If the Print Screen key is unexpectedly claimed by Snipping Tool, remote support workflows that capture full screens may break. Enforcing the machine policy in support environments ensures third‑party tools retain the expected hotkey behavior.

Regulated industries​

In environments with strict data‑loss prevention (DLP) rules, preventing unapproved apps from intercepting PrtScn reduces one attack surface for exfiltration. However, DLP policies should still inspect file transfer channels, clipboard activity, and network egress; the new policy is only a narrow but useful control.

Creative and power users​

Designers, writers, and power users often use specialized capture workflows (snipping with time delay, multi‑monitor full‑screen capture, annotation pipelines). Locking PrtScn to a single behavior may disrupt productivity. For these user groups, allow yieldable behavior and instead control app installation or use sanctioned capture tools.

---

Developer and vendor perspective​

Third‑party screenshot tools have historically used a mix of RegisterHotKey and low‑level hooks to capture PrtScn reliably. A machine policy that blocks interception may force developers to:

• Offer explicit installer options to register alternate hotkeys (e.g., Ctrl+Alt+PrtScn).
• Use documentation and user education to instruct customers on how to opt into PrtScn behavior on their machines.
• Work with enterprise customers to ensure their app’s hotkey strategy is compatible with enforced policies.

For vendors of legitimate capture tools, the change is a reminder to design graceful fallbacks and clear messaging when the OS prevents a requested hotkey registration.

---

Verdict: useful, but not a panacea​

The Make Print Screen key yieldable Group Policy is a pragmatic, overdue administrative control that brings clarity and manageability to an increasingly contested input. It gives administrators a direct lever to ensure consistent behavior across managed devices and can reduce a modest class of accidental or malicious screenshot capture.
However, it is not a comprehensive security control. Kernel drivers, compromised firmware, and high‑privilege malware remain outside its reach. For most organizations the policy should be treated as part of a layered approach: combined with driver installation restrictions, application control, DLP, and user communication to deliver both security and usability.

---

Actionable checklist for IT teams​

• Identify all apps that rely on PrtScn and test their behavior with the policy both Enabled and Disabled.
• Update your ADMX Central Store to the build that introduced the policy so GPO editors show the setting.
• Pilot the policy in a small OU and collect user feedback for one business cycle.
• If you plan to enforce Disabled, provide an approved capture tool with a documented alternate hotkey and user instructions.
• Use application control and driver installation policies to reduce the risk of kernel‑level interception.
• Monitor support queues and adjust communication and training materials to minimize friction.

---

Final thoughts​

A single clearly named Group Policy that controls whether the Print Screen key is yieldable addresses a messy, long‑running clash between legacy behavior, modern OS convenience, and third‑party integrations. For administrators it is a welcome tool — but one that must be wielded with care. Test extensively, communicate proactively, and treat the setting as one element in a broader endpoint security and usability strategy rather than a standalone fix.

---

Source: Windows Report https://windowsreport.com/microsoft-adds-make-print-screen-key-yieldable-policy-to-windows-11/

 

[ChatGPT]

Microsoft's long-running tug-of-war over the Print Screen (PrtScn) key just tilted toward flexibility: preview builds of Windows 11 now expose a machine‑level Group Policy that explicitly lets administrators choose whether the Print Screen key can be yielded to third‑party screenshot utilities. That change — observed in Dev Channel builds (notably Build 26300) — gives power users and IT teams a single, centralized control to either lock the key to Windows’ legacy/snipping behavior or allow apps like ShareX, Greenshot, and Lightshot to register the key and handle captures directly. For anyone who relies on advanced capture workflows — or for administrators who need predictable, auditable screenshot behavior — this is a consequential and welcome addition. It also opens a new set of management and security considerations that every IT pro should evaluate before rolling it out.

Background / Overview​

Windows has handled the Print Screen key the same basic way for decades: press PrtScn and the current screen is copied to the clipboard; Win+PrtScn saves a file to Pictures\Screenshots; and Alt+PrtScn captures the active window. In recent Windows 11 updates Microsoft moved toward integrating the Snipping Tool into that flow — by defaulting the key to launch the Snipping Tool’s capture overlay — which broke longstanding expectations for some users and for many third‑party capture apps.
Historically, users could restore the old behavior via a per‑user toggle in Settings (Accessibility → Keyboard → Use the Print screen key to open Snipping Tool) or by changing a registry value under HKCU. But those options are per‑user and sometimes inconsistent across builds and editions of Windows 11. The newly introduced Group Policy consolidates control at the machine level, making behavior uniform for all users on a device — and making it manageable in enterprise environments.
At a glance, what changed:

• A new Group Policy named Make Print Screen key yieldable appears in recent preview builds.
• The policy location in the Local Group Policy Editor is: Computer Configuration → Administrative Templates → Windows Components → File Explorer.
• Policy states:
• Not Configured (default in previews): Windows follows its current default; third‑party apps may be able to intercept PrtScn.
• Enabled: Explicitly allows applications to intercept and override the Print Screen key.
• Disabled: Forces legacy behavior and blocks applications from hijacking PrtScn.
• A reboot/sign‑out is typically required for the change to take full effect.

---

Why this matters: practical use cases and user impact​

For power users and creatives​

Many advanced screenshot workflows rely on the Print Screen key being captured by a specific third‑party tool. Apps like ShareX, Greenshot, Snagit, and Lightshot offer automation, upload hooks, advanced annotation, OCR, timed captures, multi‑monitor handling, and integration into developer or documentation pipelines. Locking PrtScn to Snipping Tool by default forced users to reassign hotkeys, add steps to their workflow, or entirely switch how they capture. The new policy restores an easy option to let third‑party apps handle the key again — with a machine‑level switch if you want it.

For help desks and support teams​

Predictable capture behavior matters when supporting remote users or documenting issues. If the Print Screen key behaves differently by user or machine, instructions become error‑prone. Administrators can enforce a uniform behavior across a pilot OU or entire fleet to keep support scripts and documentation consistent.

For managed and regulated environments​

Organizations with strict data‑loss prevention (DLP) or compliance controls will be cautious. If third‑party apps can intercept Print Screen, an application could capture sensitive content and upload it externally. Conversely, stopping apps from intercepting PrtScn can be a small but meaningful control that reduces accidental or unauthorized capture by unapproved software.

---

Where the control lives: Group Policy, registry, and Settings​

Group Policy (machine scope)​

The new policy is found in Group Policy Editor:

• Open gpedit.msc
• Navigate: Computer Configuration → Administrative Templates → Windows Components → File Explorer
• Look for Make Print Screen key yieldable
• Options: Not Configured / Enabled / Disabled

Notes:

• This policy appears in preview builds and requires Administrative Templates (ADMX) that include the new setting; ADMX/ADML files need to be updated in your Central Store for domain‑level management.
• The policy applies at machine scope: it overrides per‑user toggles and registry values when enforced.

Per‑user toggle (Settings)​

Older Windows 11 builds exposed a Settings toggle:

• Settings → Accessibility → Keyboard → Use the Print screen key to open Snipping Tool
  This is convenient for single users but inconsistent in enterprise deployments and may not be visible in all builds/editions.

Registry (per user)​

A known registry value controls the per‑user behavior:

• Hive: HKEY_CURRENT_USER\Control Panel\Keyboard
• Value: PrintScreenKeyForSnippingEnabled (REG_DWORD)
• 1 = Snipping Tool intercepts PrtScn
• 0 = legacy behavior / Snipping Tool disabled as PrtScn handler

Caveat: registry changes are per‑user and will not override a machine policy set via Group Policy if the new Group Policy is enforced.

---

How third‑party apps intercept the key (technical primer)​

To understand why this policy exists and how apps get priority, it helps to know the two common approaches applications use:

• RegisterHotKey API: Applications can register a global hotkey with the OS so that when the specific virtual key combination is pressed, the app receives the event. When an app registers PrtScn as a global hotkey it can claim the key before the shell’s Snipping Tool handler — if the OS allows it.
• Low‑level keyboard hooks: Apps can install a system or thread‑level keyboard hook (SetWindowsHookEx) to intercept and act on key presses before other software sees them. Hooks can be installed by user‑level apps or by device drivers and services with higher privileges.

Both mechanisms are legitimate and widely used by screenshot utilities. The new Group Policy is a higher‑level OS decision point: if the policy prevents yielding, the OS will refuse or block the interception paths that allow third‑party apps to claim PrtScn, restoring the legacy behavior.

---

Actionable guidance: what users, power users, and admins should do​

If you’re an individual power user​

• If a third‑party app should respond to PrtScn and it doesn’t, check Settings → Accessibility → Keyboard for the Print screen toggle and turn it off as needed.
• If the Settings option is absent, verify the registry key under HKCU\Control Panel\Keyboard and set PrintScreenKeyForSnippingEnabled = 0 (then sign out/in).
• Check for software that explicitly claims PrtScn (e.g., ShareX, Lightshot, Logitech/Logi apps, OneDrive auto‑save). Quitting or reconfiguring those apps can resolve conflicts.
• If your machine is joined to a domain or running an enforced Group Policy, ask your IT admin whether the new “Make Print Screen key yieldable” policy has been applied.

If you’re an IT administrator​

• Inventory: Identify apps that depend on PrtScn by surveying users and your software inventory.
• Pilot: Test the new policy in a small OU or pilot group before broad enforcement. Try both Enabled and Disabled to see how major apps behave.
• Update ADMX: Add the ADMX/ADML files from the build that introduced the policy to your Central Store so Group Policy Management will expose the setting.
• Communicate: Let users know about the change and provide instructions for alternative hotkeys or approved workflows if you plan to disable yielding.
• Combine controls: If you disable yielding to prevent data leaks, also use application control, driver installation restrictions, and DLP to reduce other capture vectors.
• Reboot policy: Document that a restart (or at least sign‑in/out) may be required to apply changes cleanly; policy may not take full effect mid‑session.

Step‑by‑step (example for Local Group Policy Editor):

• Run gpedit.msc as an administrator.
• Navigate to Computer Configuration → Administrative Templates → Windows Components → File Explorer.
• Find Make Print Screen key yieldable and set it to Enabled or Disabled per your policy decision.
• Apply the policy, then restart the target device.

---

Security, privacy, and compliance: the tradeoffs​

Security risks of allowing interception​

• Data exfiltration: A malicious or poorly vetted image‑capture tool could capture sensitive information and upload it to external servers.
• Malware stealth: Global hotkeys and hooks can be abused by malware to capture screens or intercept other input.
• Unapproved software: Allowing yielding increases the risk that unauthorized tools will be able to capture and transmit screenshots unnoticed.

Why disabling yielding helps​

• Reduces one attack surface for exfiltration by preventing user‑level apps from easily registering the Print Screen key.
• Simplifies auditing: If the OS controls capture behavior, it’s easier to reason about what can and cannot be captured on a managed endpoint.

But there are drawbacks​

• Productivity impact: Power users and certain workflows rely on third‑party tools. Disabling yielding may break automation and increase support tickets.
• Not a silver bullet: The Group Policy controls a specific interception path. Other capture vectors (screen recording APIs, remote access tools, drivers, kernel components) remain possible and should be mitigated by layered controls.

Recommendation for security‑minded administrators:

• Use the new policy as one element in a defense‑in‑depth strategy.
• Combine it with application allowlisting, controlled software installation processes, and DLP/EDR monitoring of suspicious upload activity.
• If you disable yielding, publish alternative capture workflows and approved tools for users with legitimate needs.

---

Troubleshooting common conflicts​

• If PrtScn doesn’t behave as expected, check these items in order:
• Is the device governed by Group Policy? Run gpresult or check the Local Group Policy Editor for the new policy setting.
• Does the per‑user Settings toggle exist? If present, compare its state to the registry and policy.
• Are third‑party utilities running that may claim the key? Temporarily terminate ShareX, Greenshot, OneDrive, Logitech/Logi software, and OEM keyboard tools to isolate the conflict.
• Registry: Inspect HKCU\Control Panel\Keyboard\PrintScreenKeyForSnippingEnabled for per‑user overrides.
• ADMX Central Store: If managing through domain GPOs, ensure you’ve updated ADMX files; missing ADMX will hide the policy in GPMC.
• Reboot: A complete restart often clears previously registered global hotkeys and ensures the Group Policy takes effect.

Real‑world notes:

• Some OEM software (keyboard utilities, mouse suites) or cloud storage clients (OneDrive) can register their own handlers or change behavior; those apps can sometimes appear to “steal” PrtScn even when Settings and registry say otherwise.
• If users report that ShareX or a similar app stopped reacting to PrtScn after an update, rebind the hotkey inside the app and test again — many apps allow rebinding and will re‑register on restart.

---

The bigger picture: why Microsoft added this control​

This Group Policy closes a gap between per‑user toggles and enterprise manageability. Per‑user settings are great for individuals, but enterprise admins need deterministic machine‑level controls that can be enforced at scale. By adding Make Print Screen key yieldable to the Administrative Templates, Microsoft gives organizations a clear policy knob:

• Standardize behavior across machines.
• Provide a single place for IT to apply a capture policy rather than relying on scattered registry edits or per‑user settings.
• Offer a reversible, supported management approach as the OS continues to evolve how it integrates capture workflows.

It also acknowledges the reality that users and third‑party developers rely on the Print Screen key in many ways, so rather than force a single model, Microsoft is making the choice explicit and manageable.

---

What to expect next​

• This policy is currently visible in preview builds; Microsoft often moves preview features into broader releases after testing and feedback. There is no guaranteed timeline for when — or if — it will reach every supported channel.
• The Settings UI may or may not re‑expose a simple toggle that maps cleanly to the Group Policy decision; for now, IT teams should rely on the Group Policy when managing fleets.
• Watch for updated ADMX templates from Microsoft tied to feature releases; admins will need these to manage policy centrally in Active Directory environments.
• Vendors of popular screenshot tools will likely update their documentation to describe how their product behaves under the new policy and to advise users on migration steps for hotkey rebinds.

---

Conclusion: a sensible, manageable improvement with tradeoffs​

Giving administrators a machine‑level switch to decide whether the Print Screen key can be intercepted is a practical, long‑overdue move. It resolves a messy intersection of per‑user toggles, registry hacks, and application conflicts by offering a supported GPO that maps directly to the real operational choices organizations and power users face.
That said, this control is not a substitute for a layered security posture. Allowing third‑party apps to intercept PrtScn increases convenience and productivity for many users, but it also raises a modest risk vector that must be weighed against business needs. Administrators should pilot the setting, update ADMX templates, document approved capture workflows, and combine this policy with app control and DLP to manage risk.
For users who live in screenshot‑heavy workflows, the result is simple and positive: you can get your Print Screen key back, or keep it locked down — whichever fits your needs. For admins, it’s a new lever that reduces uncertainty and support overhead. As with many Windows controls, the ideal outcome is balance: make advanced capture workflows possible, but do so under clear policy, monitoring, and communication so productivity and security move forward together.

---

Source: PCWorld Windows 11 will let you rebind the Print Screen key soon