Random application failure when opened from network share with error 0xc0000006

We have an application which runs on Windows 2012 R2 that accesses a fileshare running on 2016 R2, and execute Winscp from there. The application launches it using the service account, and most of the time it works. However, at random, it fails to launch the exe file, causing all the jobs to fail. Once it failed, then all the subsequent opens, either by a user or the application fails, with a network error, as shown here. This is from event viewer.

But it is confirm that there is no network error, as we can navigate through the fileshare, open other files etc.

The workaround is to kill all the existing winscp processes. Once all the other sessions are killed, then it is able to open the file. So I ran procmon when it was failing, and when it is working fine. I compared them using excel, and the output is here. It is shown as NETWORK ERROR, which seems not to be the case.

Even when facing this issue, we are able to open if the exe is located in the local machine.

One interesting thing that I noted is given in this link : However, in out case, it is open using the same account, and we are not logged off. But not sure if it is login in fileshare or the app server. Also, we are not talking about any RDS server. So I am not sure if it is related.

So what I suspect is that there is something that locks the exe file which is causing the error, which explains why it works once we kill all the existing sessions. In that case, what are my options here.

For those are facing this problem, this seems to be an issue with SMBv3. I disabled SMBv3 in the client machine, and forced it to use SMBv1, then removed oplocks as below:

Set-smbclientconfiguration -oplocksdisabled $true

Set-smbclientconfiguration -useopportunisticlocking $false

Its been 10 days since I did this, and I have not faced the problem again. However, using SMBv1 in a production environment is not recommended, so moved my executable to the local machine, and changed the scripts accordingly.