I thought a recent link error was due to having left a resource open, which is causing an 'Access Denied' to my Debug folder and subsequent .exe file. Now, I'm not so sure. I have scoured my code for any unreleased resources upon exit, but haven't found any. I looked in Task Manager and even downloaded a Handle app from MS that shows locked files and who is locking them. The .exe file is not shown in either when this happens. So, I'm not sure what is happening.
It appears that when a new build is done, the .exe file is deleted first (or tried to be). In my case, the LNK1104 error occurs with 'Access Denied'. If I don't do anything else, and just monitor the folder where the .exe file resides, eventually within about 1 minute, the .exe file is deleted and I can rebuild again and run the code. So, apparently, even though Access is Denied, the delete request will be granted after some time. But, once I run the code, the next rebuild after exiting the code causes the same process over again.
I've tried running as administrator, but same thing happens. And, I tried rebooting, but same thing happens.
Any ideas on what I am missing? I'm using VS 2019 - 16.11.13. Thanks.
Many AV's are quite defensive when unknown .exe files appear (like locking it against modification).
Anything you compile yourself is going to fall into that category.
Say for example you do all your development in a directory hierarchy starting at c:\code
You should be able to add an exclusion rule to your AV which says "do not check anything under c:\code"
Thanks. I have that entire folder as an exception in my AV tool. So, that's apparently not it. I will download your ProcessHacker tool and investigate. The MS tool didn't show it locked, but apparently it is for some timeframe.
Nope. ProcessHacker provides the same info as the MS tool does. The .exe appears in memory when being used, and goes away upon exit. But, during the time when the Rebuild produces the 'Access Denied' message, the .exe is not in memory. So, not sure what is holding up the deleting of the .exe file for upwards of 1 minute.
It has been a while since I last used VS2019 regularly, I now use VS2022 for the most part though I still have 2019 installed, and I very rarely get a link error with 2022. When rebuilding if I have a console open from a previous build's run.
I do remember 2019 being a bit twitchier with occasional link errors without a console open, though that was several minor versions ago.
Nope. ProcessHacker provides the same info as the MS tool does. The .exe appears in memory when being used, and goes away upon exit. But, during the time when the Rebuild produces the 'Access Denied' message, the .exe is not in memory. So, not sure what is holding up the deleting of the .exe file for upwards of 1 minute.
You have to use the "Search handles or DLLs" feature in ProcessHacker in order to find other running processes which have an open handle to the EXE file in question and thus prevent that file from being deleted. Also, you should do "Show details for all processes" (i.e. run ProcessHacker with elevated rights) before you start the search, because only then ProcessHacker will be able to scan system processes (services) too.