executable file produced by ifort/visual studio becomes locked after executing once and cannot be re

[lamsonsh]

The executable file produced by ifort/visual studio becomes locked after executing once and cannot be replaced, removed, deleted, renamed.   It seems to occur on windows when the exe file is executed in debug mode inside visual studio.   Generally happens on network disks (consistently) but has at least at times I observed this on a local windows D disk drive.  Observed by multiple users, multiple VS projects,  and multiple disk systems with different technologies.  Has been a problem for almost a year with no resolution.   Would love to hear if there are similar experiences out there and any path to fixing the issue.

Microsoft Visual Studio Professional 2019
Version 16.7.6
VisualStudio.16.Release/16.7.6+30611.23
Microsoft .NET Framework
Version 4.8.04084

Installed Version: Professional

Visual C++ 2019 00435-30012-93613-AA688
Microsoft Visual C++ 2019

Intel® Inspector 2020 603904
Intel® Inspector 2020, (build 603904), Copyright © 2009-2019 Intel Corporation. All rights reserved.

Intel® Parallel Studio XE 2020 Composer Edition for C++ Windows* Package ID: w_comp_lib_2020.0.166
Intel® Parallel Studio XE 2020 Composer Edition for C++ Windows* Integration for Microsoft* Visual Studio* 2019, Version 19.1.0.16, Copyright © 2002-2019 Intel Corporation. All rights reserved.
* Other names and brands may be claimed as the property of others.

Intel® Parallel Studio XE 2020 Composer Edition for Fortran Windows* Package ID: w_comp_lib_2020.0.166
Intel® Parallel Studio XE 2020 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2019, Version 19.1.0055.16, Copyright © 2002-2019 Intel Corporation. All rights reserved.
* Other names and brands may be claimed as the property of others.

Intel® VTune™ Profiler 2020 605129
Intel® VTune™ Profiler 2020, (build 605129), Copyright © 2009-2019 Intel Corporation. All rights reserved.

[Steve_Lionel]

This is a Microsoft debugger issue that has persisted over the years. It is not unique to Fortran. The only solution I know is to exit Visual Studio and restart it. There are reports of it in this forum going back a long time.

[lamsonsh]

Thanks, I don't really think its ifort, but neither exiting VS nor rebooting the computer will clear the exe file locking.   What is so odd is out of all the users at our site, there is just our team that has this experience.  We do know now of another group which has seen this and there is a suspicion it is related to virus checking SW.   Could upgrading from VS 2015 to 2019 possibly be a factor?

[Steve_Lionel]

I've only seen this relate to the debugger, and it has been on and off for a decade. You could try using the File Locksmith feature of Microsoft PowerToys to reveal which process has the EXE locked. That it survives a reboot, though, I've never seen and can't imagine what might do that, though your suggestion of antivirus software could be relevant.

[andrew_4619]

I use lockhunter to unlock files and in fact there are some project build files that I automatically unlock as a pre-build task because I got so fed up of manually fixing it. 

[lamsonsh]

We have not found any locked files per se with file locking tools, but another developer has found that unmounting and remounting the network disk drive from windows will cure the locked exe file, with a message from windows along the lines of:

C:\>net use /d p:

There are open files and/or incomplete directory searches pending on the connection to p:.

Is it OK to continue disconnecting and force them closed? (Y/N) [N]: y

p: was deleted successfully.

We can reproduce the exe file locking in Debug or Release mode and executing the exe file either inside VS2019 or outside from a command prompt.   I don't know what it means that the executable file appears to be "open" after completion of its execution.  The locking does not happen on local drives, only network drives.   

I guess I am just passing this along if anyone else has a similar issue, or if this means anything to someone!

[andrew_4619]

As I said it is not that the file is actually open it is that the file system of the OS thinks it is open. I can fully appreciate closing the file system resets the problem that totally makes sense. As I said when I have had these problems "lockhunter" has always been able to fix it for me.