23

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.

Lee Mac
  • 937

6 Answers6

34

Just upgraded to Windows 1903 and hit this myself, seems Microsoft decided to assign the keyboard shortcut for the new Office App to Win+Ctrl+Alt+Shift!

Changing the open command for this to rundll32 resolved the issue for me. Using an elevated cmd, run the following command:

    REG ADD HKCU\Software\Classes\ms-officeapp\Shell\Open\Command /t REG_SZ /d rundll32
jfrmilner
  • 2,197
9

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:

^+!#d::
Send {blind}{vk07}
;... perform other tasks here as needed ...
return

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:

#^!Shift::
#^+Alt::
#!+Ctrl::
^!+LWin::
^!+RWin::
Send {Blind}{vk07}
return

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 on Windows 10 and earlier by Ctrl+Shift-right-clicking on the taskbar and selecting "Exit Explorer". Alternatively, Explorer can be terminated via Task Manager.
  • 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.

Lexikos
  • 300
1

I've found a solution that disables all of the shortcuts entirely.

https://www.howtogeek.com/445318/how-to-remap-the-office-key-on-your-keyboard/

#include <windows.h>
#include <stdio.h>
#include <thread>
#include <chrono>
#include <iostream>

int main(int argc, wchar_t* argv[])
{
    //Build Array Of Keys To Unregister
    //These map to W, T, Y, O, P, D, L, X, N, and Space, respectively.
    UINT offendingKeys[10] = { 0x57, 0x54, 0x59, 0x4F, 0x50, 0x44, 0x4C, 0x58, 0x4E, 0x20 };

    //Kill Explorer
    system("taskkill /IM explorer.exe /F");

    //Register hotkey
    for (int i = 0; i < 10; i++) {
        RegisterHotKey(NULL, i, 0x1 + 0x2 + 0x4 + 0x8 | MOD_NOREPEAT, offendingKeys[i]);
    }

    //Restart Explorer
    system("start C:/Windows/explorer.exe");

    /* Sleep for a few seconds to make sure Explorer has time to
       attempt to register the Office hotkeys, and get blocked by 
       our hotkeys */
    std::this_thread::sleep_for(std::chrono::milliseconds(4000));

    //deregister hotkeys by ID
    for (int i = 0; i < 10; i++) {
        UnregisterHotKey(NULL, i);
    }

    return 1;
}

Basically, Explorer is closed, then the program registers each hotkey. When Explorer restarts, it gets blocked by our hotkeys. The program deregisters the hotkeys and then exits, returning the keyboard to a usable state.

You'll need jfrmilner's registry tweak active for this to work:

REG ADD HKCU\Software\Classes\ms-officeapp\Shell\Open\Command /t REG_SZ /d rundll32

In my testing, I could not override hotkeys registered by Explorer while it was running, even running the script as administrator, so Explorer must be restarted which is a minor annoyance. If anyone knows of a way to override Explorer's hotkeys directly, let me know.

Anthony H
  • 101
0

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.

Albin
  • 11,950
0

You can use hyperenable.

Disclaimer: I'm the author.

midrare
  • 445
0

Disable ALL global Office keyboard shortcuts

Here is a tested, working version (as of July 2024) of the How To Geek solution for Windows 11 (likely also 10) —as their version halts with errors when trying to compile the source code— plus the required steps to actually end up with an executable file, which are insufficiently described.

#include <windows.h>
#include <stdio.h>
#include <thread>
#include <chrono>
#include <iostream>

// Fix for linker errors "unresolved external symbol" #pragma comment (lib, "User32.lib")

int main(int argc, wchar_t* argv[]) { //Build Array Of Keys To Unregister //These map to W, T, Y, O, P, D, L, X, N, and Space, respectively. UINT offendingKeys[10] = { 0x57, 0x54, 0x59, 0x4F, 0x50, 0x44, 0x4C, 0x58, 0x4E, 0x20 };

//Kill Explorer
system(&quot;taskkill /IM explorer.exe /F&quot;);

//Register hotkey
for (int i = 0; i &lt; 10; i++) {
    RegisterHotKey(NULL, i, 0x1 + 0x2 + 0x4 + 0x8 | MOD_NOREPEAT, offendingKeys[i]);
}

//Restart Explorer
system(&quot;start C:/Windows/explorer.exe&quot;);

/* Sleep for a few seconds to make sure Explorer has time to
   attempt to register the Office hotkeys, and get blocked by 
   our hotkeys */
std::this_thread::sleep_for(std::chrono::milliseconds(4000));

//deregister hotkeys by ID
for (int i = 0; i &lt; 10; i++) {
    UnregisterHotKey(NULL, i);
}

return 1;

}

Steps to compile a binary

(assuming Windows 11)

  1. Save the above source code in a file, named e.g. disable_office_key_combos.cpp
  2. Install Visual Studio Build Tools, with at a bare minimum these "Individual components":
    • Windows 11 SDK (latest version)
    • C++ CMake tools for Windows
    • MSVC C++ x64 build tools (latest)
  3. Open the Developer Command Prompt for VS 2022 (shortcut should be in your Start Menu)
  4. Change directory to where your cpp file is, e.g.: cd c:\Users\yourname\Desktop
  5. Run cl /EHsc disable_office_key_combos.cpp

Done, you should now have a new file disable_office_key_combos.exe of about 96 KB.

Usage

  1. Add (a shortcut to) our program to the Startup folder (Win+X, Run, shell:startup)

  2. Add @jfrmilner's registry tweak to your registry (paste in Run):

    REG ADD HKCU\Software\Classes\ms-officeapp\Shell\Open\Command /t REG_SZ /d rundll32

How does it work?

As Windows Explorer registers the Office hotkeys at its startup, those hotkeys cannot be re-/unassigned, not even by a process that runs with elevated privilege.

That's where our program comes in: Explorer is closed, then our program registers each Office hotkey. When Explorer restarts, it tries, but only once, to register the Office hotkeys, and can't, due to our program keeping those hotkeys in use at that time. After Explorer's failed attempt, the program then deregisters the hotkeys and quits, resulting in the Office hotkeys having been freed.

If this program is run at login, the screen might flicker once due to Explorer restarting, after that, it is stopped and not taking up any resources, unlike the AutoHotKey solution which needs to be running constantly.

Tanuki
  • 93