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:
;... 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:
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.
... 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.