I'm using GNU Emacs 24.3 on Windows 7 and normally I don't have any problems with speed/responsiveness.

I'm launching Emacs with runemacs.exe

However, when I am travelling and try to connect to my company network via VPN (or just working offline without a connection to the company network), Emacs often becomes incredibly slow — it might take many minutes to open a buffer and it just does not respond to keyboard commands.

(I'm still highly interested in a solution) All relevant text and configuration files are saved in my user directory C:\Users\myusername.domainname\Documents which is located on the local hard disk (so should not need accessing remote servers), but I wonder if Windows 7 might try to sync those files with a server

I'm also using the "offline files" feature for other directories and I wonder if this could have an effect on my problem.

The problem occurs not only when VPN is used, but also when the computer is just offline and not connected to the company network.

  • 1
    Since "The problem occurs not only when VPN is used, but also when the computer is just offline and not connected to the company network" it's not clear that the VPN has anything to do with the problem. May 30, 2015 at 20:54
  • How about using the most recent public release of Emacs instead of 24.3? Is there a reason to try and troubleshoot an older version of Emacs when a newer stable release is readily available?
    – lawlist
    May 31, 2015 at 11:34
  • @lawlist: thanks, I think I'm currently using Emacs 24.5, I'll check that tomorrow when I'm back at the computer. Anyway, shouldn't it be possible in every stable Emacs release to work in any network setting without problems? May 31, 2015 at 18:55
  • 1
    Why would Emacs be making DNS requests? Why would slowness be due to DNS requests rather than some other kind of network access? Jul 28, 2016 at 20:56
  • 1
    lists.gnu.org/archive/html/bug-gnu-emacs/2012-10/msg00230.html offers some hints and (setq w32-get-true-file-attributes nil) might help. Feb 29, 2020 at 16:01

3 Answers 3


The reason of this problem can be using of the recentf mode. You need to disable cleaning up unavailable files using following command in your ~/.emacs (or ~/.emacs.d/init.el if you are using it):

(setq recentf-auto-cleanup 'never)
  • thanks a lot - that looks promising, but I do not use recentf mode and could not find such an option in my .emacs or init.el Sep 15, 2015 at 22:14
  • 1
    I'm having the same problem as OP, and this did nothing to help me.
    – PaulB
    Nov 20, 2015 at 15:21
  • I can't think of any reason whatsoever recentf would have any impact. It's simply a list of recent files. They are not restored or checked,
    – RichieHH
    Feb 29, 2020 at 18:49
  • A very large recentf file can indeed introduce intermittent latency, but this does not seem to be the problem as described by OP.
    – InHarmsWay
    Mar 2, 2020 at 10:49

I had the same problem, and it seems like it is being caused by the windows netlogon service. The simplest solution is to turn it off when outside your company network, by running the following command in the command line:

net stop netlogon

When you are back on the company network, start it again using

net start netlogon
  • net stop netlogon This solved my issue with emacs 27.1 under Cygwin with VPN connection to employer.
    – FalkH.
    Jan 5, 2021 at 13:56

Quite a few possible reasons, two off the top of my head (had these troubles in the past.)

  1. You may have a remote folder mapped in Windows, and when off the local network it may slow you down a lot (getting off the VPN doesn't quite help, actually it may make matters worse since Windows will keep trying to reach it stopped only by timeouts.) More recent versions of Windows seem to deal a bit better with it, but still. Try to run net use * /delete in a command prompt and see if it helps.

  2. Check if you are using tramp (I doubt it since you are on Windows, but I am using Windows too along with Linux and I do use tramp so it's not totally out of question.) If so, try to run tramp-cleanup-all-connections when off the network.

If all this or anything else people suggest here doesn't help you may need to run deeper troubleshooting. The best tool I've found for it is Sysinternals' Process Monitor (https://technet.microsoft.com/en-us/sysinternals/bb896645). It's a complex beast to deal with, and it requires at least basic understanding of Windows operating system, but it is capable of taking guesswork totally out of the process and zeroing down on the offender.

  • net use * showed me nothing. But it turned out my current directory did contain a symbolic link to a remote directory. Only procmon got me the clue I needed to figure it out, as this answer suggested.
    – Ron Burk
    Jun 6, 2020 at 23:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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