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

[Bart Goossens]

Error during startup – already cleared cache.
Uninstalled and reinstalled Axcrypt. Also the portable version is not working

‘The process cannot access the file because it is being used by another process

Windows version : 21H1 (19043.1237) Enterprise

———– Exception at 2021-09-27 06:44:31Z ———–

System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:53414
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
— End of inner exception stack trace —
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
at AxCrypt.Mono.HttpRequestClient.DoRequestInternal(String method, String content, WebRequest request)
at AxCrypt.Mono.HttpRequestClient.Dispatch(CommandServiceEventArgs command)

[Prabhukumar RModerator]

Hello Bart Goossens,

Please send the complete error report to troubleshoot the issue. Please follow the detailed instructions to take the complete error report: https://www.axcrypt.net/blog/how-to-send-a-complete-error-report .Also, write a mail to support@axcrypt.net.

[Gerald Lerman]

I have the exact same issue and it’s driving me crazy!

[Chavdar M]

Same error with installed and portable app  “the process cannot access the file because it is being used by another process”

Running Win 10 Enterprise 20H2 with latest patches.

WIndows event log shows:

Faulting application name: AxCrypt.exe, version: 2.1.1618.0, time stamp: 0x60b5dcb1
Faulting module name: KERNELBASE.dll, version: 10.0.19041.1202, time stamp: 0xc9db1934
Exception code: 0xe0434352
Fault offset: 0x0000000000034f99
Faulting process id: 0x38d8
Faulting application start time: 0x01d7c876d7f54f7f
Faulting application path: C:\Program Files\AxCrypt\AxCrypt\AxCrypt.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: e99dfb0f-847d-4303-bb1f-06eef107f9b0
Faulting package full name:
Faulting package-relative application ID:

Application: AxCrypt.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ObjectDisposedException
at System.Net.HttpListener.CheckDisposed()
at System.Net.HttpListener.Stop()
at AxCrypt.Mono.HttpRequestServer.DisposeInternal()
at AxCrypt.Core.Ipc.CommandService.Dispose(Boolean)
at AxCrypt.Desktop.Window.Program.Main()

[Gerald Lerman]

Me too. I get the same error when I tried using the portable app. The process cannot access the file because it is being used by another process”. I used every tool to try to find the conflict, but there are no conflicts that I can find. I’m beginning to believe the error message is a lie.

I’m running Win10 Pro with all the latest updates.

This is concerning because I am trusting that I can get back my encrypted files, but now I’m not so sure. This has been happening for a while and I’m beginning to think I might be better off with an alternative since I don’t see much interest from the developers to resolve it and I’m losing confidence that there will be a solution.

[Prabhukumar RModerator]

Hello Gerald Lerman and Chavdar  ,

We have responded to your support email. Please check the same.

“Please avoid sending a same query in different mediums. You may get duplicate response”

[John S]

Same problem here.  Running Windows 11 with latest updates and the latest version of AxCrypt.  Uninstall of AxCrypt, restart, and reinstall did not solve the issue.  Disabling antivirus and firewall also did not resolve the problem.

“AxCrypt failed to start.  All settings cleared.”  “The process cannot access the file because it is being used by another process.”

[Prabhukumar RModerator]

Hello John S,

Please send the complete error report to troubleshoot the issue. Please follow the detailed instructions to take the complete error report: https://www.axcrypt.net/blog/how-to-send-a-complete-error-report .Also, write a mail to support@axcrypt.net.

[John S]

My issue was resolved by downloading and installing all the latest drivers from my computer’s manufacturer, then rebooting.  I’m not sure which specific driver installation did the trick, but I’m up and running.

[John S]

I take it back.  Since getting it to work, it has since stopped.  Support was unable to offer me a valid solution, and since this software doesn’t seem to “play nice” with my Lenovo laptop, I’m just going to stop using AxCrypt.

[Gerald Lerman]

The support guy will tell you it’s Microsoft’s problem and so it’s not their problem. So, sorry, you will never see your files again that you entrusted to AxCrypt, and this matters not at all to them. Where I work this attitude would not be tolerated for a moment. There would be some attitude adjustment put into effect. We’d be looking for a workaround, contacting Microsoft if necessary, finding alternative ways to invoke .net functions, and not stopping until we completely understood what the issue is and found some way to make this work for our customers. But all you get from AxCrypt is that it’s not their problem and frankly, John, they don’t give a damn.

Their suggestion to run the .Net troubleshooter didn’t work, no problems were found, and the advice to uninstall and reinstall .NET is extremely dangerous, especially since it’s not based on any actual knowledge that it will work. You can end up with all sorts of broken programs by uninstalling .Net.

My issue was resolved when I updated the HyperV_Virtual_Switch in Hyper-V but this was purely by luck and happenstance and I don’t feel confident the issue won’t return. I too am looking at alternatives. I will not use a product where I risk losing access to my files over a technical glitch while knowing that the vendor will not make any effort to help recover access to files that I entrusted to them.

[Prabhukumar RModerator]

Hello Gerald Lerman and John S,

Sorry to hear this. Please write an email to our support team support@axcrypt.net. we investigate and try to resolve the issue as soon as possible.

[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.

[Mike]

Just for those who are looking at the “exclude port” solution, it does not work.

What happens is that when you reboot, the port is now excluded and cannot be used. AxCrypt will not bind to this port. Removing the exclusion allows AxCrypt to launch correctly, but it will screw up again in the future if Hyper-V captures this port.

That said, I’ve been running AxCrypt + Hyper-V for years and this is the first time I’ve come across this problem. I expect that the issue is with AxCrypt.

And the question that EVERYONE should be asking is:

WHY DOES AXCRYPT NEED A LOCAL SERVER???

This seems really odd to me.

 

[Author]

Posts