Suddenly all Cygwin commands I start from the Windows command line have a ~10-20 second lag before they execute, so that Cygwin becomes totally unusable. I already tried to reinstall without success.

Executing the commands from within a Bash shell window, works fine (while starting Bash I see the lag). Removing all entries from my local PATH variable doesn't have an influence. I use Windows 7 x64 and Cygwin x64 v 1.7.34 (0.285/5/3).


Occasionally I work in a Windows domain with thousands of users.

I don't want to do any best-guess approach. I would prefer Cygwin to cache user information on an as-needed basis. It turns out this is easy to do.

Simply run cygserver on login.

To set this up properly, run cygserver-config once only. This will set up cygserver to run as a Windows service with the correct credentials. Do this from an administrator Cygwin window.

$ cygserver-config
Generating /etc/cygserver.conf file

Warning: The following function requires administrator privileges!

Do you want to install cygserver as service?
(Say "no" if it's already installed as service) (yes/no) yes

The service has been installed under LocalSystem account.
To start it, call `net start cygserver' or `cygrunsrv -S cygserver'.

Further configuration options are available by editing the configuration
file /etc/cygserver.conf. Please read the inline information in that
file carefully. The best option for the start is to just leave it alone.

Basic Cygserver configuration finished. Have fun!

What does cygserver do for me?

Have a look at the documentation over at the Cygwin site. Basically it does the user caching stuff, together with ensuring IPC works between all Cygwin processes.

Your mileage may vary of course, but this is now my preferred way of working. I should have done it years ago.

  • This is great! thanks for sharing after so long time.Using this file access through /cygdrive is also much faster now compared to before – 85fce Mar 1 '17 at 9:36
  • /usr/bin/cygserver-config: line 181: cygrunsrv: command not found, C:/cygwin64/bin is on the PATH, running as administrator... – Troyseph Oct 16 '17 at 10:31
  • 1
    @Troyseph Does C:\cygwin64\bin\cygrunsrv.exe exist? Have you erroneously used forward slashes (/) in your %PATH%? Is the cygrunsrv package installed? – bobbogo Oct 16 '17 at 10:45
  • Ah, C:\cygwin64\bin\cygrunsrv.exe doesn't exist, installed the cygrunsrv: NT/W2K service initiator package and all is working. – Troyseph Oct 16 '17 at 12:03
  • run cygserver-config as in the answer, stopped working cygwin at all (process fail to start) – user174962 Mar 8 at 7:25

It seems to be to do with authentication. For me, 40 seconds to get something to execute. After that though, process creation in that process tree seems pretty quick.


So, I

  • Made a cache of my local authentication, and my own Active Directory (AD) credentials

    $ mkpasswd -l -c >/etc/passwd
    $ mkgroup -l -c >/etc/group
  • Told Cygwin just to use these two files

    $ echo 'passwd: files' >/etc/nsswitch.conf
    $ echo 'group: files' >>/etc/nsswitch.conf

I killed all Cygwin processes and started again. Everything now runs nice and fast. I will remove this hack on every Cygwin DLL file update and see how I get on.

This is just a sketch—you will at least want to keep backups!


Deprecated. See my more recent answer to this question for a better (IMHO) solution.

  • worked for me... and didn't have to install a service! – Droj Jun 16 '17 at 16:33
  • @bobbogo Your answer is at the bottom for me. Which answer are you referring to in your edit at the end? Thanks! – jpaugh Mar 16 '18 at 17:59
  • good to know about this, although it can't explain why "All cygwin commands ... have a ~10-20 second lag before they execute". – philwalk Mar 20 '18 at 17:08
  • @philwalk I think it does. The problem is that at start-up Cygwin has to populate its user database. This takes a long time when you are inside a big windoze domain. Not every command suffers this delay, only the first in any process tree. – bobbogo Mar 21 '18 at 11:28

Read the update below, this turned out not to be the issue.

I've been suffering from an extreme version of this problem, although it's intermittent. When the problem exists, all commands take between 20 seconds and in the most extreme cases several minutes. It will occur for several days, and then it will go away for several days. BTW, I have an extremely fast system with lots of DRAM, SSD drives, etc.

I now finally have a candidate theory that might explain things. I just updated Cygwin via setup-x86_64.exe (which I do infrequently) and afterwards things are extremely responsive again (literally 1000s of times faster than before). I'm guessing the rebaseall at the end of the update is what made the difference.

Update: the speedup I saw before was apparently a coincidence; when the problem reappeared a month later, this didn't fix it. It turns out that disabling Windows Defender live protection instantly resolved the slowdown.

  • 1
    disabling Windows Defender live protection instantly resolved the slowdown - known issue – gavenkoa Jan 7 at 22:47

As a footnote, I just found that I had to rebuild the passwd and group files after a Cygwin update. As the slow behaviour was happening again, the autorebase part of the install took several days to complete.

I also did not need to modify the default nsswitch.conf on my (Windows 10) system.

By the way, the slow behaviour also showed itself with the Windows command prompt and portable applications. Some portable applications took several hours to produce a window when started.


This is how this problem manifested for me. For the first, say 20, commands entered at the Cygwin prompt it was fast, but then it abruptly became painfully slow.

I tried the above authentication fix. It didn't work for me.

The Cygwin FAQ reports that Cygwin doesn't like spaces in user or group names. See My Windows logon name has a space in it, will this cause problems?.

My group name had a space in it, so I changed it in the /etc/group file generated in the authentication fix to an underscore. That didn't work either.

Other postings for the same problem have reported it to result for the virus scanner. I replaced my existing virus scanner (System Center Endpoint Protection) with Sophos. That fixed the problem for me.

I hope this helps.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.