Bug in Windows 10 Version 2004: GetDoubleClickTime unexpectedly returns 0 when Batch Login is used

I have identified a bug or at least unexpected behavior in the 2004 (May 2020 Update) Version of Windows 10. This behavior was not present in previous versions of Windows 10 and causes problems in some of the software I work on and probably also other software.

The Windows API function “GetDoubleClickTime” is used to query the maximum number of milliseconds between two mouse clicks so that the two clicks are counted as one double click instead.

In Windows 10 Version 2004 this function unexpectedly returns 0 when executed in the context of a batch login, which means for example:

  • Code inside a Windows service
  • Code in applications that are started from a Windows service
  • Server-side code in web applications in IIS
  • Code in applications started from “planned tasks” in Windows with the setting “Run whether user is logged on or not”

In all these cases, there is no user interface. Executed code (in my case it is very old legacy code that doesn’t have a separation between user interface and business rules yet) could still query the value and then fail if 0 is returned unexpectedly. In my case, for example, a third party user interface control is instantiated which fails when trying to set a .net Windows Forms Timer based on the system double click time.

How to reproduce the bug

Using the following simple C# application

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

namespace WindowsFormsApp14

    static class Program
        static extern uint GetDoubleClickTime();
        static void Main()
            // Same result with var doubleClickTime = 
            // System.Windows.Forms.SystemInformation.DoubleClickTime;
            var doubleClickTime = GetDoubleClickTime();

            Trace.WriteLine("DoubleClickTime: " + doubleClickTime);

Use the Microsoft Tool DebugView (with the setting “Capture Global Win32” enabled) to see the output from Trace.WriteLine.

Then create a Task in the Windows Task Scheduler to execute the compiled application. Use the setting “Run whether user is logged on or not”. You will see the output is “DoubleClickTime: 0”.

If you execute the compiled application directly, you will see the correct output “DoubleClickTime: 500” (Or some other value depending on your mouse settings).

In previous Windows 10 versions, a value higher than 0 was returned in both cases.

The same effect can be seen when code runs in a Windows service or in a web application in an IIS application pool. Probably also in other cases whenever code runs in the context of a batch logon.

How to solve the issue

  • Wait for Microsoft to fix the issue in a future update.
  • Advise customers to not install the Windows 10 2004 update or return to the previous Windows 10 version if necessary
  • Patch your code and make sure it can handle the case that GetDoubleClickTime returns 0. If necessary, contact vendors of third-party libraries to patch their libraries.

3 thoughts on “Bug in Windows 10 Version 2004: GetDoubleClickTime unexpectedly returns 0 when Batch Login is used

  1. Hi!

    I faced exactly the very same issue on a Azure DevOps Build Agent. Are you aware if there`s any update from Microsoft end on this matter?

    I even tried to set the value using the following call, without success:
    [DllImport(“user32.dll”, ExactSpelling = true, CharSet = CharSet.Auto)]
    public static extern bool SetDoubleClickTime(int newValue);

    I end up getting the error code ERROR_REQUIRES_INTERACTIVE_WINDOWSTATION(1459):


  2. Hi Pedro.

    Thanks for the feedback. We tried to report this issue to Microsoft using roughly the same text as in this blog. Bad Experience. We were then asked several times by the assigned Microsoft employee to specify details that are already part of the text until we gave up.

    Maybe Microsoft will publish a fix in the future but the safest approach will be to adapt existing code so that it can handle an empty double click time.

  3. Hi NineBerry,

    Thanks for the quick response. My problem is that the code in question is on a Janus legacy component, several years old… But nevermind.

    We have some workarounds such as start it as interactice service or to run using “psexec -s -i”


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.