it seems that Office has decided to hi-jack the keyboard shortcut CTRL+ALT+SHIFT+WIN+D.

That might not seem like a problem, but I have assigned that keyboard shortcut in AutoHotKey and have been using it for years.

It started opening the Office Hub, and after I uninstalled that, it now opens the Office Hub web page instead.

So, how do I remove/disable this keyboard shortcut?

There are no Office processes running, and I can't find any .lnk files that might have a shortcut assigned in properties.

Any ideas?

I am using the latest Windows Insider Preview (18932) and latest Office with all updates installed.

  • With me this shortcut open up the OneDrive folder. – harrymc Jul 7 at 16:08
  • I have noticed that there is the similar thread from you in TechNet forum. I will continue to pay attention to this issue there. – Herb Gu Jul 8 at 9:29

If you know which program/task "snatches" the keyboard shortcut you should check if the task has higher permissions. For example if it runs with admin rights while AHK is running with regular user rights. In this case you should give AHK admin privileges as well which should solve your problem.

Since no office task is running a different task might be responsible for "shatching" the shortcut, there are a few suggestion here on the site that will help you to find the responsible task.

  • Thanks Albin, I will take a look at the suggestions. AHK is running with admin privileges already, so sadly that didn't help... I also haven't been able to figure out exactly what it is that grabs the shortcut. I thought it was the OfficeHub app, but after uninstalling it, the shortcut is still snatched, but now takes me to the OfficeHub website instead. – Lars Panzerbjrn Jul 8 at 9:46
  • @LarsPanzerbjrn I haven't used AHK in a while, but it might also be as easy as telling AHK to capture the shortcut before any other task. I'm not really sure how the capture is implemented, especially if there is a conflict, I would try to look for this kind of option within AHK first. – Albin Jul 8 at 22:27

AutoHotkey can be used to override most keyboard shortcuts - generally the only exceptions are Ctrl+Alt+Del and Win+L.

One complication in this case is that AutoHotkey does not block the modifier keys, since doing so would interfere with their normal function. For example, the hotkey ^!+#d:: would suppress the D key, but only after the four modifier keys have already been passed through to the OS and the active window. In effect, the operating system's keyboard shortcut recognizer sees only Ctrl+Alt+Shift+Win instead of Ctrl+Alt+Shift+Win+D, so instead of opening OneDrive, it opens the Office app or website.

The same generally applies to the Win and Alt keys, which normally activate the Start menu or a window menu. However, in those cases AutoHotkey automatically "masks" the menu by sending a key (LCtrl by default, but it can be overridden with #MenuMaskKey). After the operating system's keyboard shortcut recognizer sees that Win or Alt is used in combination with another key, it avoids activating the menu when the Win or Alt key is released.

A future update to AutoHotkey might add this masking for ^!+#, but as of v1.1.30.03 it is not done. Masking the shortcut manually is just a case of sending a key.

Disable OneDrive Shortcut (Ctrl+Alt+Shift+Win+D)

The following script for AutoHotkey v1.x disables Ctrl+Alt+Shift+Win+D:

Send {blind}{vk07}
;... perform other tasks here as needed ...

Disable Office Shortcut (Ctrl+Alt+Shift+Win)

Since the main Office shortcut can be activated by combining the modifier keys in any order, suppressing it requires several hotkeys; one for each "suffix" key:

Send {Blind}{vk07}

Other Shortcuts

According to my experimentation on Windows 10 build 18362.10014, the following Ctrl+Alt+Shift+Win shortcuts also exist: Word, Teams, Yammer, Outlook/Mail, PowerPoint, LinkedIn, Excel and OneNote.

Which program snatches the keyboard shortcut?

It is likely that the letter-key shortcuts are handled in the same manner as all other hotkeys registered with RegisterHotkey; that is, they are registered by a program (Explorer in this case), and are deregistered when that program exits or is terminated.

  • One can exit Explorer by Ctrl+Shift-clicking on the taskbar and selecting "Exit Explorer".
  • If Explorer is not running when the script starts, the hotkey ^!+#d:: is typically able to be registered by AutoHotkey - ListHotkeys shows the "reg" method.
  • If Explorer is running when the script starts, the hotkey ^!+#d:: cannot be registered, so AutoHotkey falls back to using the keyboard hook - ListHotkeys shows the "k-hook" method.
  • If Explorer is restarted after the script has registered ^+!#d:: with RegisterHotkey, the built-in hotkey does not work even if AutoHotkey is terminated, until Explorer is restarted. This can be explained by the fact that RegisterHotkey will fail if the hotkey has already been registered by any process.

This can also be observed with the more traditional shortcuts, such as Win+E, but not Win+L, which is likely implemented at a lower level for security reasons.

However, the main Office shortcut (Ctrl+Alt+Shift+Win) does not behave this way, and cannot be disabled by simply defining a hotkey that does nothing. This is likely due to the fact that it activates when a modifier key is released, not when it is pressed.

The Office app does not appear to be responsible for registration of the shortcuts. If the Office app is "uninstalled" via the Settings app, pressing Ctrl+Alt+Shift+Win reinstalls the Office app and then opens it. If the app is completely removed via PowerShell, the shortcut opens the Office website instead.

On my system, the OneDrive shortcut shows an error message (Windows cannot find OneDrive.exe) and then opens the OneDrive website, undoubtedly because I have uninstalled OneDrive.

Admin Privileges

... are not needed for overriding system-defined hotkeys. However, if the active window is running at a higher integrity level than AutoHotkey, hotkeys implemented with the keyboard hook (such as all of the above) will typically not work. This is due to a security feature called User Interface Privilege Isolation, which can be bypassed by Running with UI Access. While running as admin grants admin privileges to the script and any programs that it launches, running with UI Access only permits the script to bypass UIPI.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.