← Back to Blog

Troubleshooting | Aug 5, 2026 | 8 min read

Win+V Stopped Working After a Language Pack? How to Fix It

By Mohit Sehrawat

Win+V Stopped Working After a Language Pack? How to Fix It — Edge Drop Guide

Win+V opens the Windows clipboard history pane — until it does not. A common and confusing cause is that a recently installed input method, language pack, or keyboard remapper has registered Win+V for itself. The OS clipboard is still healthy; the shortcut never reaches it. This guide walks through how language packs and Input Method Editors (IMEs) interact with global shortcuts, which remappers are the usual suspects, and how to recover Win+V without uninstalling the language you actually need.

For the broader nine-fix playbook when Win+V is unresponsive, see Win+V not working on Windows 11: 9 fixes. For a sanity check that the OS clipboard itself is fine before chasing shortcut conflicts, see how to test whether the OS clipboard itself is healthy. If items are arriving but not being saved, see Win+V Says 'Nothing Here'? How to Fix Clipboard History on Windows 11; if a recent Insider build broke things, see corrupt clipboard cache after Insider builds.

What "Win+V is stolen" looks like

The symptom is consistent across machines. The user presses Win+V and one of these happens:

  • Nothing. No pane, no toast, no error.
  • A different app's window opens (a language bar, an IME pad, a remapper's overlay).
  • The clipboard history pane opens, then immediately loses focus to a floating candidate window.
  • Win+V works in some apps but not in others (typical when an IME only grabs the shortcut while active).

The Windows clipboard history is still running. Pressing Win+V in a fresh Notepad window with all IMEs disabled will usually open it. That is the first clue that the shortcut, not the clipboard, is the problem.

How IMEs and language packs touch global shortcuts

A Windows language pack by itself does not usually capture Win+V. The conflict almost always comes from the IME that ships with a non-Latin input language — Chinese (Pinyin, Zhengma, Wubi), Japanese (Microsoft IME, Google IME), Korean (Microsoft IME), or a third-party IME like Sogou, Baidu, or ATOK. These IMEs run a candidate window that listens for shortcut chords, and some of them register Win+V or Win+H for their own purposes (paste-as-text, voice input toggle, or handwriting pad).

The mechanism is the same one that powers every global hotkey in Windows: RegisterHotKey. When an IME process starts, it can register a global hotkey that takes priority over the shell's Win+V handler. The Explorer shell — which owns the clipboard history flyout — never sees the keystroke.

Language packs also install a "text services" framework (ctfmon.exe) that runs at logon and can change which IME is active per window. If you switch to a Japanese window and press Win+V, the Japanese IME may consume the shortcut before Explorer does.

Common IMEs known to grab Win+V

This is not an exhaustive list, and behaviour changes between versions. As of mid-2026, the IMEs most commonly reported to intercept Win+V are:

  • Microsoft Pinyin (MSPY) — has at times mapped Win+V to a "paste as plain text" candidate action. Recent builds have moved this to Ctrl+Shift+V, but older builds still conflict.
  • Microsoft Japanese IME — the IME pad toggle has been reported to capture Win+V in some Windows 11 builds.
  • Sogou Pinyin — registers several Win+key chords for its own shortcuts; Win+V has been among them on and off.
  • Google Japanese Input — historical conflicts with Win+V for the handwriting pad.
  • ATOK — long-running reports of Win+V conflicts; usually configurable in ATOK's environment settings.

If a recent Windows update coincided with a new language install, the IME is a stronger suspect than the language pack itself.

Power-user remappers: a separate category

IMEs are one source of shortcut theft. The other is keyboard remappers — tools that the user installed on purpose. The most common:

  • PowerToys Keyboard Manager — Microsoft's own remapper, which can remap Win+V to anything, including to nothing if the user misconfigures it.
  • AutoHotkey — scripts running in the background can register #v:: hotkeys that intercept Win+V before Explorer sees it.
  • SharpKeys — writes to the registry Scancode Map; less likely to swallow Win+V specifically, but worth ruling out.
  • Key Tweak, MapKeyboard, and similar — same registry-scan approach as SharpKeys.
  • Keyboard firmware (QMK, VIA) — if the keyboard itself is sending a different keycode when you press Win+V, no software on the PC will see Win+V at all.

A remapper conflict is easier to detect than an IME conflict because the user usually remembers installing it.

Step 1: confirm the OS clipboard is healthy

Before chasing shortcut conflicts, isolate the problem. Open Notepad, copy a line of plain text, and press Win+V. If the pane opens, the OS clipboard is fine and the issue is app-specific. If it does not, try a second test:

  • Open Settings → System → Clipboard and confirm Clipboard history is On.
  • In Notepad, press Ctrl+C, then Ctrl+V. If paste works but Win+V does not, the clipboard service is healthy and the shortcut is the problem.

For the full diagnostic, see how to test whether the OS clipboard itself is healthy. The point of this step is to avoid resetting the clipboard cache when the only thing wrong is a hotkey conflict.

Step 2: switch to a clean input language

To test whether an IME is stealing the shortcut, switch the active input method to plain US English (or another Latin layout with no IME) and try Win+V again:

  1. Press Win+Space to cycle input languages.
  2. Or: Settings → Time & language → Language & region, look at the "Preferred languages" list, and use the language bar to pick the plain Latin layout.
  3. Open Notepad, press Win+V.

If Win+V now opens the clipboard history, the IME that was active before is the culprit. The fix is to either remap the IME's own shortcut (most IMEs expose this in their settings panel) or to disable that IME's global hotkey registration entirely.

Step 3: check PowerToys Keyboard Manager

PowerToys Keyboard Manager is the friendliest remapper to check because it has a visible UI:

  1. Open PowerToys.
  2. Go to Keyboard Manager → Shortcuts.
  3. Look for any row mapping Win+V (or Win+V) to another action.

If a row exists, delete it and restart PowerToys. Win+V should return to Explorer. If no row exists, PowerToys is not the culprit. PowerToys is documented in Microsoft's official PowerToys docs; the Keyboard Manager page covers shortcut remapping in detail.

Step 4: check AutoHotkey scripts

AutoHotkey scripts can register #v:: globally, which will swallow Win+V system-wide. To find the offending script:

  1. Look for the green "H" AutoHotkey tray icon.
  2. Right-click each running AutoHotkey script and choose Window Spy or Open.
  3. Search the script body for #v::, ~#v::, or #v Up::. Any of these declares a Win+V handler.
  4. Comment out the line or close the script. Test Win+V in Notepad.

If AutoHotkey is the cause, the fix is to remap the script's hotkey to something other than Win+V — or to use the ~ prefix (~#v::) which lets the keystroke pass through to Explorer after the script runs.

Step 5: check the Microsoft IME settings

For the Microsoft Pinyin and Japanese IMEs, the global shortcut settings live in different places per Windows version. The reliable path in Windows 11:

  1. Settings → Time & language → Language & region.
  2. Click the ellipsis next to the language with the IME, choose Language options.
  3. Under "Keyboards", click the IME, choose Keyboard options.
  4. Look for a "Keys" or "Advanced" section listing global shortcuts.

If a global shortcut uses Win+V, change it to Ctrl+Shift+V or disable it. Third-party IMEs (Sogou, Baidu, ATOK, Google Japanese Input) have their own settings panels; the same logic applies — find the global shortcut list and either remap or disable the Win+V binding.

Step 6: disable the IME's text-services framework temporarily

ctfmon.exe is the Windows process that hosts IMEs. Stopping it (via Task Manager → End task, or taskkill /f /im ctfmon.exe from an elevated command prompt) will temporarily disable all IMEs. If Win+V works after ctfmon.exe is stopped, an IME hosted by ctfmon is the culprit.

ctfmon.exe will restart itself at the next input switch, so this is a diagnostic step, not a fix. Do not disable it permanently — IMEs are needed for the languages they support.

Step 7: rebuild the shell shortcut cache

If none of the IME or remapper fixes work, the Explorer shell's shortcut registration may be stale. The cleanest fix is to restart Explorer:

  1. Open Task Manager.
  2. Find Windows Explorer in the Processes list.
  3. Right-click → Restart.

Explorer restarts in a few seconds, re-registers its shortcuts, and Win+V should work again. If a restart of Explorer is not enough, see how to restart the clipboard user service and the Explorer.exe restart to unstick copy-paste guide.

A note on third-party clipboard managers

A third-party clipboard manager (Ditto, CopyQ, ArsClip, or an edge shelf like Edge-Drop) can also be configured to take over Win+V. Most do not steal it by default — Ditto uses Ctrl+`, CopyQ uses its own configurable hotkey, and Edge-Drop uses Alt+C by default. But all three can be configured to use Win+V, and if they are, the manager will swallow the shortcut before Explorer does. Check the manager's hotkey settings.

Running two clipboard tools at once is its own failure mode. For that scenario specifically, see can you run two clipboard tools at once and two clipboard managers fighting each other.

A recovery checklist

When Win+V is being stolen and the cause is not obvious, work through this list in order:

  1. Confirm Clipboard history is On in Settings → System → Clipboard.
  2. Confirm Ctrl+C and Ctrl+V work in Notepad (proves the OS clipboard is healthy).
  3. Switch input language to plain Latin (Win+Space) and retry Win+V.
  4. Open PowerToys Keyboard Manager and check for Win+V remaps.
  5. Check tray icons for AutoHotkey; open each script and search for #v.
  6. Open the IME's keyboard options and look for a Win+V binding.
  7. Restart Explorer from Task Manager.
  8. If still broken, do a clean boot to rule out third-party services.

Most Win+V conflicts are found in steps 3 through 6. Step 8 — a clean boot — is the last diagnostic step before considering a Windows reset, which is almost never the answer for a shortcut conflict. For when a reset might actually be warranted, see when to reset Windows because paste is haunted.

Related reading

Sources

Mohit Sehrawat
Written by Mohit Sehrawat · Author & Software Tester

Mohit Sehrawat is a B.Tech Computer Science Engineering student with a focus on software testing, bug detection, and product quality. He is interested in exploring applications, identifying issues, and improving the overall user experience through thorough testing.

GitHub · LinkedIn

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support

Free · Lightweight · Privacy First
Find us on CodeHype