slow windows desktop keyboard shortcuts

Question

I've got a couple of shortcuts on my desktop and on some of them I've configured the "Shortcut key" to a keyboard combination. For example I have a shortcut pointing to d:\documents\todo.txt and I've set Shift + Alt + T. This naturally opens up using notepad.

Double-clicking on the icon always opens up the text file immediately. Using the keyboard shortcut though is sometimes very (5-10 seconds) slow. Note that during that time CPU utilization does not rise.

This happens to all my machines (both old and new ultra fast boxes) in Windows XP (various versions) and Windows 7.

There are tons of questions about this but no solution.

Is there an explanation and solution to this problem?

Edit: The behavior is not consistent. I have 30 desktop shortcut and 5 of them have keyboard shortcuts assigned. I'm not interested in software alternatives for this Windows functionality. I want to know what the problem is and how to solve it.

Edit 2023: I have upgraded to Windows 10 and it is still happening.

Answer 1

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

1. Start Windows, then before opening any other programs try a shortcut key. Do you experience a delay? If so, go to step 3.
2. Launch any other programs you typically run. Do you experience a delay? If not, wait until you do.
3. One by one, stop each interactive program; cycle through them with Alt-Tab to be sure you've got them all. After stopping each one, see whether the shortcut delay has gone away.
4. Still have a delay? Do the same thing with the icons in the taskbar's notification area (aka the "system tray"): right click and exit, checking for the shortcut delay after each one. You might need to expand the notification area to see all of those icons.

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:

• Calculator
• Store

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:

1. Kill them manually with the task manager whenever you notice them.
2. As discussed in harrymc's answer to this related superuser question, turn off specific background apps at Settings > Privacy > Background Apps. Not all apps can be turned off in this way.
3. As discussed in Helen's answer to the same superuser question as above, disable Superfetch.

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.

Answer 2

If you're on Windows 10, try killing "Application Frame Host" (ApplicationFrameHost.exe). This made the delay disappear on my system.

Note that if you kill this process, it will close any modern (UWP = Universal Windows Platform) apps you have running.

Answer 3

My personal experience was that there was a program that was delaying Windows' handling of the hotkey. For myself it was Steam, for Andreas it was Akamai.

To diagnose which application is responsible simply close an application and try your hotkey again. Once you figure out who the culprit is, decide whether it's a service that you can deal with not running at all times.

I know this is a fairly old question, but after not finding an answer I stumbled upon the solution and felt the need to share it with the community.

Answer 4

The problem might have some to do with how Windows finds these shortcuts. Any reasonable person might expect that they store the shortcut data in the registry, the registry resides in RAM, and they put everything else in there. :-)

Instead the key shortcuts for .LNK and .URL are inside the shortcut itself.

As you can see in the picture, after trying to trace down where it was in the registry (it's not), I found the change in the shortcut own data itself.

There are 2 major locations where this data is scanned from, anywhere in all of the Start menu, and via the desktop folder.

When people find that removing some program, or some web program, "fixes" the problem, maybe it has to do with items, or mappings, or some unapproved stuff in the Start menu or the desktop?

After realising the method used, it was easy enough to take the advice of using another method other than windows, to do the same things.

---

The Notepad shortcut method used, is going to add microbes of delay also. A shortcut to a text file itself, that will eventually open a Notepad, will get to go through a fun process. Find the class bounce around in the registry, find the associated program, open that program, and pass in that parameter.

Most program shortcuts can have quoted whole paths "C:\Windows\notepad.exe", instead of using environment variables to eventually locate the program, in the many environment variable paths. Many programs like to stuff their program path into the environment variable path, they have even broken the "search path" there by making the line to long.

Most program shortcuts can also have quoted parameters placed after the quoted program path "d:\documents\todo.txt". This has the computer finding the file direct without searching or guessing, and passing the file to it immediately. (The quotes are only necessary when there are spaces.)

If you want to see speed, try it as "C:\Windows\notepad.exe" "d:\documents\todo.txt" and cut out the middleman. Create the shortcut for the program instead (notepad), and add a parameter for the .TXT file into the program shortcut. OK it's like DOS now. :-) But faster.

To check the environment variables (which is only for specific issues), go to "System", and in the "System Properties", in "Advanced" bring up the "Environment Variables" and look at the mess in the PATH variable.

Answer 5

The culprits for me are the "Movies & TV" and "Photos" app. Once I killed this 2 apps in task manager, my keyboard shortcut launched without the 3 seconds delay. Yes, I have to kill both.

I decided to uninstall both apps since I don't need them. To learn how to uninstall built-in apps, I have followed this page successfully:-

http://www.howtogeek.com/224798/how-to-uninstall-windows-10s-built-in-apps-and-how-to-reinstall-them/

Answer 6

For me (Windows 10 x64) helped disabling SuperFetch feature. This service (called SysMain in Services) is causing start of the Application Frame Host process several times per day and this process is responsible for slow shortcuts.

Answer 7

(Note: depending on your version of Windows, the Service once known as Superfetch is now known as SysMain.)

(I'm using Windows 10 64-bit Pro, version 19041.746.)

After I Disabled the SysMain Service, I had no delays [for a month] when using the keyboard shortcuts that I defined in the Properties dialog for most shortcuts on my desktop.

(For example, I right click the Excel shortcut icon, click Properties, click inside the Shortcut key textbox, and hold down the Ctrl, Alt, and x keys, whereupon Ctrl + Alt + X is pasted into the Shortcut key textbox. So when I press that 3-key combo, Excel opens immediately, with no delay.)

Disabling the SysMain service [once seemed] to be the global solution. Doing so seems to nail down one [of the] Windows components responsible for the delay instead of trying all the one-off "it worked for me"s.

I give credit to @icL7126, whose long-ago Answer is very short and thereby easily overlooked.

I found [some] info here. It suggests changes to the Registry. I wouldn't.

Will disabling SysMain cure your shortcut delay? Maybe not, but try it. You can always enable it again. (I'd hope you'd post failures to this thread.)

My own system performance [had] only been helped by disabling SysMain in that those delays between shortcut keypresses and program loading [had] disappeared for a month ... until ...

EDIT

... the 3-second delay started again last night. Very disappointing. I can no longer say, "Disabling the SysMain service did the trick," but that was the only change I'd made in December. So, now what.

Googling led me back to here so I read all the suggestions above (and elsewhere) and used Task Manager to stop cortana, which seemed insufficient, but I did it anyway to assert my dislike of it. More importantly, I found myself again at the posts by icl7126. I read everything else posted with that name and decided (since others swore by it) to stop the task named ApplicationHost.exe.

At the moment, there's no delay with SysMain still Disabled and with the ApplicationHost.exe task ended, but I expect, as icL7126 mentions, to have to do this several times per day until something better comes along.

Answer 8

I cannot reproduce your problem and do not remember having it on any of my computers. I do not notice any difference to opening a shortcut by clicking. I have only very few of these shortcuts, though, 2 tops.

• Is there a software that listens for hotkeys that is installed on all your rigs? Maybe this causes shortcuts to be recognized slowly? It could be any app with global hotkeys. You'd have to manually close them one by one to see if it makes any difference.
• How many shortcuts do have? 10, 20, 30? If you have many, it could also mean slower reaction time.

To speed things up: You could try using a third party software for managing your shortcuts (like AutoHotkey, PhraseExpress or Clavier+ (all of which are available as aportable app). Hopefully, they will work faster. I am using them anyway and keep them on a flash drive to use on multiple computers.

Answer 9

I had a delay for 2 seconds, starting Notepad using Ctrl+Alt+N that I use to have as its shortcut key. The solution to get rid of the delay was to disable Akamai Netsession client.

To see if this is your problem, you can open Windows Task Manager, and select the "Netsession_win.exe", rightclik and select "End process tree". (There are two Netsession entries, one of them probabli spawning the other - selecting end process tree kills them both).

Now try your shortcut keys again.

If they are quick and nice now, make the change permanent either by uninstalling Akamai NetSession Interface from Add Remove programs in the control panel, or by disabling it in msconfig (so that it doesn't start automatically).

This is how to disable it by opening msconfig:

• Start menu / Run / write "msconfig" / Enter.
• Switch to the "Startup" tab.
• Uncheck the entry with the name "Akamai Netsession Client".

However I'd uninstall it, and only install it again if it is needed. It's just a download agent that some companies use for downloading their software (I believe Microsoft and Adobe has used it).

This was the location of the akamai program:

c:\Users\myname\AppData\Local\Akamai\netsession_win.exe

Hope this will help out.

Best regards, Andreas

Answer 10

As this does not happen in Safe mode, and as I myself have never encountered such a slow-down, some product that you have installed must be causing the problem.

I suggest using Autoruns to turn off startup programs in bunches, until you narrow it down to the one that is causing it.

You could also examine your installed products using Revo Uninstaller Freeware and uninstall products that you don't need any more or that you don't like. Google carefully for products that you don't know.

I would also suggest, for the future, to install some security suite. There are lots of free antivirus products, as well as free anti-adware, and not having some of them is just asking for trouble, same as not locking your door at night.

I am not suggesting that your computer is infected, but that is one possibility for such a weird behavior, so full-scans using several well-known antivirus products would still be a good idea. See How to Clean An Infected Computer.

Answer 11

The reason for this is DDE. I don't know the specific technical details this problem generally boils down to a message queue meltdown.

Some applications are not expecting/able to handle DDE messages on an interrupt basis and so when something they ask for arrives or something is broadcasted to them they don't provide an instant response because they are not waiting on the queue. Things get backed up and everything with a dependency on DDE takes forever. In extreme cases even in command windows sometimes you can see letters you type will be lagged for the same reason.

The only way I know to avoid this problem is to avoid running certain applications over time and by trial and error you will notice when running cause delay. There might be a way to tweak things such as changing timeouts or isolation of DDE broadcast domains or tools to look into DDE but I am clueless on this topic.

Answer 12

I made a simple tool to execute hotkey shortcuts, which bypasses the Windows shell.

You can find it here: https://github.com/rustyx/myhotkey

I use it myself to rapidly start things like cmd.exe and bash.exe.

Answer 13

On a Win10 Pro machine, the culprit was the DropBox client loaded in the system tray. Right click and exit that and the 3 second problem went away.

Unfortunately, on the same PC upgraded to Win11 Pro, with no DropBox client installed, I saw the 3 second delay. I'll post back if I discover this particular offender.

Regards . . .

Answer 14

C# console app to immediately show you which apps are causing problems - an enhanced version, including sorted results and showing file paths, of Bob Mc's code from their 2016 comment link. Further code improvements are welcome.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Diagnostics;
using System.Linq;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading.Tasks;
namespace FindHotKeyDelay
{
    internal static partial class Program
    {
        /// <seealso href="https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-enumwindows" />
        [LibraryImport("user32.dll", SetLastError = true)]
        [return: MarshalAs(UnmanagedType.Bool)]
        private static partial bool EnumWindows(WndEnumProc lpEnumFunc, IntPtr lParam);
    /// &lt;seealso href=&quot;https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-getwindowtextlengthw&quot; /&gt;
    [LibraryImport(&quot;user32.dll&quot;, SetLastError = true)]
    private static partial int GetWindowTextLengthW(IntPtr hWnd);

    /// &lt;seealso href=&quot;https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-getwindowtextw&quot; /&gt;
    [LibraryImport(&quot;user32.dll&quot;, SetLastError = true, StringMarshalling = StringMarshalling.Utf16)]
    private static partial int GetWindowTextW(IntPtr hWnd, [Out] char[] lpString, int nMaxCount);

    /// &lt;seealso href=&quot;https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-getwindowthreadprocessid&quot; /&gt;
    [LibraryImport(&quot;user32.dll&quot;, SetLastError = true)]
    private static partial int GetWindowThreadProcessId(IntPtr handle, out uint processId);

    /// &lt;seealso href=&quot;https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-sendmessagetimeoutw&quot; /&gt;
    [LibraryImport(&quot;User32.dll&quot;, SetLastError = true)]
    private static partial IntPtr SendMessageTimeoutW(
        IntPtr hWnd,
        uint msg,
        UIntPtr wParam,
        IntPtr lParam,
        uint fuFlags,
        uint uTimeout,
        out UIntPtr lpdwResult);

    // EnumWindows callback method signature
    private delegate bool WndEnumProc(IntPtr hWnd, IntPtr lParam);

    private static async Task Main()
    {
        List&lt;Task&lt;(TimeSpan, string)&gt;&gt; hotKeyDelayTasks = new List&lt;Task&lt;(TimeSpan, string)&gt;&gt;();

        EnumWindows(delegate(IntPtr wnd, IntPtr _)
            {
                hotKeyDelayTasks.Add(Task.Run(() =&gt; GetHotKeyDelay(wnd)));
                return true;
            },
            lParam: 0);

        IEnumerable&lt;string&gt; messages = (await Task.WhenAll(hotKeyDelayTasks)).Order()
            .Select(delaysAndMessages =&gt; delaysAndMessages.Item2);

        foreach (string message in messages)
        {
            Console.WriteLine(message);
        }
    }

    private static (TimeSpan delay, string message) GetHotKeyDelay(IntPtr hWnd)
    {
        StringBuilder message = new StringBuilder();

        Stopwatch stopwatch = Stopwatch.StartNew();
        IntPtr sendMessageTimeoutReturnValue = SendMessageTimeoutW(
            hWnd: hWnd,
            msg: 0x0033, // WM_GETHOTKEY
            wParam: 0,
            lParam: 0,
            fuFlags: 2, // SMTO_ABORTIFHUNG
            uTimeout: 3000,
            lpdwResult: out UIntPtr _);
        stopwatch.Stop();

        if (sendMessageTimeoutReturnValue == 0)
        {
            message.Append(&quot;Fail or timeout &quot;);

            if (Marshal.GetLastPInvokeError() != 0)
            {
                WriteLastPInvokeErrorMessage();
            }
        }

        message.Append(stopwatch.Elapsed.ToString(@&quot;s\.ffff\s\ &quot;));

        if (GetWindowThreadProcessId(hWnd, out uint processId) == 0)
        {
            WriteLastPInvokeErrorMessage();
        }

        try // Accessing MainModule can throw access denied
        {
            Process process = Process.GetProcessById(checked((int)processId));
            message.Append(process.MainModule.FileName);
        }
        catch (Win32Exception exception)
        {
            message.Append(exception.Message);
        }

        int windowTextWithTerminatorLength = GetWindowTextLengthW(hWnd) + 1;
        if (windowTextWithTerminatorLength &gt; 1)
        {
            char[] windowText = new char[windowTextWithTerminatorLength];
            if (GetWindowTextW(hWnd, windowText, windowTextWithTerminatorLength) == 0)
            {
                WriteLastPInvokeErrorMessage();
            }

            message.Append($&quot;\t{new string(windowText)}&quot;);
        }
        else
        {
            if (Marshal.GetLastPInvokeError() != 0)
            {
                WriteLastPInvokeErrorMessage();
            }

            message.Append(&quot;\tno window title available&quot;);
        }

        return (stopwatch.Elapsed, message.ToString());
    }

    private static void WriteLastPInvokeErrorMessage()
    {
        Console.WriteLine(Marshal.GetLastPInvokeErrorMessage());
    }
}

}