Reply To: The process cannot access the file because it is being used by another process

[Jerry Lerman]

Are you having this error and do you also have Windows HyperV enabled?

I noticed similar problems with other programs that bind particular ports to localhost. They intermittently would not start, claiming the port was in use, but there was no evidence that anything was using the port. In the case of Axcrypt, running “netstat -bano | findstr 53414” in an Admin CMD window returned no hits, meaning it isn’t being used. It’s just not usable by anyone.

What I found is that the ports are not in use but are non-persistently reserved by HyperV. Programs return the wrong error message but it may be the error that they are getting. Apparently HyperV, and this is idiotic design, at some point will reserve a ton or port ranges for its own use. And because it reserves them, you can’t use them any longer.

To find out if this is the case for you, in an ADMIN CMD window, run this command:
netsh interface ipv4 show excludedportrange protocol=tcp

If you find that 53414 is within one of the many reserved port ranges, then you have the reason that AxCrypt won’t start. HyperV reserved the port for itself.

I’m not an expert on this but I fixed this by beating HyperV at its own game. While it reserves these port ranges non-persistently, I reserved port 53414 (and the others I had issues with) as persistent reservations for my Windows account. By doing this, HyperV can no longer reserve it for itself.

It’s a race to fix. You need to reboot which releases the HyperV reserved ranges. Then as quickly as possible when Windows comes up, open an Admin CMD window and run this command:

netsh int ipv4 add excludedportrange protocol=tcp startport=53414 numberofports=1 store=persistent

If you get back “ok” then you won and you are all set going forward. If you are told that the port is in use then you lost the race and the HyperV already reserved it and you need to try again.

After you successfully run the command and have the port reserved for your Windows account, rerun “netsh interface ipv4 show excludedportrange protocol=tcp” and you’ll see that range 53414 is reserved with an “*” meaning it’s yours forever. The problem should now be resolved. At least this resolved my issue with AxCrypt and about 5 other programs that I run that bind a particular port to localhost.