Tests
Shortcut Replacement
I ran some tests and got some interesting and very telling results. I did the test in Windows ME (it was the earliest version of Windows I had a running copy of on hand at the time), and repeated it with XP and then 7. This is what I did, which you can repeat:
- Create a shortcut to the calculator on the desktop, name it
C and assign it an unused hotkey
- Test that the hotkey work
- Create a shortcut to Notepad in the
Links folder, name it N, and assign it a different, unused hotkey
- Confirm that the hotkey does not work
- Delete the shortcut to the calculator from the desktop
- Move the shortcut to Notepad from the
Link folder to the desktop and rename it to C
- Press hotkey that was assigned to the original shortcut to the calcuator
- Note that it runs Notepad
This occurs on Windows ME and XP, but in Windows 7, pressing the either hotkey did nothing at the end.
Internal Hotkey Format
From this, we can assume that when you assign a hotkey to a shortcut, it assigns it to the full path to the shortcut. For example, in the test above, setting the hotkey Alt+⇧Shift+C to the calculator shortcut would cause Windows to register something like this internally:
C A S W K P
- + + - C "C:\…\Foobar\Desktop\C.lnk"
Therefore, if you delete (or move or rename) the shortcut, pressing the key will try to run the shortcut that does not exist. Curiously, if you monitor file-access in Process Explorer, you will not see FILE NOT FOUND errors trying to access the missing shortcut, but if you restore the shortcut, you will see it being accessed again when you press the hotkey.
Automatic Hotkey Managment
Also, that Windows 7 does not run the copied shortcut seems to indicate that Explorer does some sort of hotkey-management whenever shortcuts are moved, renamed, or deleted, but of course, there are limitations to what it can do. (For example, if two shortcuts share a hotkey, deleting the one that has the hotkey will not suddenly re-assign the hotkey to the other one, you need to manually open that shortcut’s Properties dialog and click [OK] to do that.)
Links-folder Redirection
I then considered redirecting the Links folder (figure 1). I tried redirecting it, then copying the moved folder back to the original location. I found that hotkeys did not work for shortcuts in either folder. I then tried stripping the attributes from from the folders and even deleting the desktop.ini files from them under the assumption that Windows treats them specially, but that did not help. I then created a new, regular folder in the user-data folder and to my surprise, hotkeys still wouldn’t work.
Shortcut Hotkeys All Around the File-System
Next, I tried it with a shortcut on a different drive, and still nothing. I tried assigning hotkeys to shortcuts in several different locations in Windows 7, and only the shortcuts that were in the Desktop or Start Menu folders or one of their sub-directories could use hotkeys.
Conclusions
It seems that Explorer’s hotkey function for shortcuts is extremely limited and only works for the Start Menu and desktop. I don’t know if this is a bug or intended because I cannot find any mention of the limitation. Microsoft’s own page on the subject says nothing about it. (Let them know through the feedback form. I clicked [No] and submitted a link to this page.) There’s no reason to believe that this is different in Windows 8 or 8.1 or possibly even future versions (assuming that they retain Explorer at all).
Recommendations
You could (attempt to) report it, but I wouldn’t hold out hope of it being fixed. It would be faster and easier to just store shortcuts that need hotkeys in another folder.
Figure 1: Links-location setting:
Best Answer
The original question deals with Windows 7, but it's happening now for new reasons in Windows 10. Here's a general answer that deals with both situations.
The general problem
There's an excellent explanation of the problem and its cause at the 2012 MSDN post Why is there sometimes a long delay between pressing a hotkey for a shortcut and opening the shortcut?
Executive summary: before launching a program via its shortcut key, Windows first polls all currently running programs and asks "Is this your shortcut key?" If so it switches focus to that window rather than spinning up a new copy of the program.
The problem happens when a window somewhere refuses to answer the question. This can be a program that's generally non-responsive for some reason, though it can also happen for other reasons (see below). Windows waits 3 seconds before muttering "jerk" under its breath and moving on to the next window to ask it the same shortcut question.
Finding unresponsive programs
Now that you know your culprit, you get to decide: is that program worth the delay it causes? For example, Adobe Creative Cloud has sometimes caused problems for me, so I just tell it not to run when Windows starts. I can still use Illustrator etc. without it running.
If you can't live without the program, either live with the shortcut key delay or, as "user 99572 is fine" suggests, try a macro program like AutoHotKey.
Windows 10: Action Center
Windows Action Center can also cause the delay. (This might be a problem in Windows 8 too; I skipped from 7 to 10). Whenever you see this:
it means the Action Center has system notifications for you to review—which also causes the shortcut key delay, even though the Action Center isn't non-responsive per se.
Click the icon and clear the notifications, then the icon will look like this, and Action Center should no longer cause a shortcut key delay:
If a notification comes up repeatedly and you find it unhelpful, right click it and tell Windows to turn off notifications for that application.
BUT... sometimes Action Center can cause problems even if no notifications are waiting. Even with no notifications showing, I've often cleared up this problem simply by opening and closing Action Center. You can do this quickly with the [Windows]-A shortcut key combination.
Windows 10: unresponsive background processes
Sometimes a background process can cause this problem too. Two in particular are:
There might be others culprits as well. The significant thing is that these are foreground applications that, for some reason, appear as background processes even though you might not have actually run them. This problem might happen with other apps, and might be limited to Metro apps (TBD).
You can use some or all of the following techniques to eliminate these processes:
After using techniques #2 and #3, these rogue background processes no longer appear on my computer.
New problem in Windows 10 build 1809 (2/2019): Settings App
This Windows build has introduced a new and pernicious shortcut inhibitor. As soon as you start Windows, go to task manager. You have the problem if you see Settings running as a background task:
If you kill this task, shortcut keys will be fast again, but the Settings app will reappear a while later, re-introducing the problem.
As noted by Cerno in the comments, Windows 10 Enterprise users are able to prevent Settings from running in the background by going to Settings > Privacy > Background Apps. But for Windows Home and Professional users, "Settings" does not appear in the background app list. (If anyone knows of a way to make it appear, please post in the comments.)
July 2020 Update on Settings: After installing Windows 10 Pro v2004 Build 19041.388 (7/2020), my computer became unstable and I had to reinstall Windows. Since doing this, "Settings" now appears as an option in Settings > Privacy > Background Apps. I don't know whether this happened because of installing Build 19041.388 or because of the subsequent reinstall. In any case, disabling Settings as a background app has (finally!) resolved the problem for me.
Other...
This 3-second timeout probably doesn't cause every keyboard shortcut delay.
One one of my laptops, whenever Adobe Creative Commons is running in background I sometimes experience a delay lasting as long as 30 seconds before launching an app. That's 10 times the timeout Window uses before giving up on a non-responsive process, so something else must be going on in this case.