I'm using VS2015 C++. My program is quite large. I can compile it, run it, and exit. The problem is when I change something quickly and try to compile it just after exiting, it will tell me that it can't write to the executable. It seems to me that the program is taking longer to unload than it should..... Why?

I am handling my memory correctly (I'm sure), but why would it take that long to completely exit?

It's only a problem if I make a quick change and compile-- like I needed a negative number, but originally put in a positive by mistake.

Let me be more specific in the sequence of events:

(I run this in "release")

I make changes to my code and compile.

I run the program to see if the changes did what I expected (sometimes it's not what I expected).

I exit the program and it dumps out to the compiler normally.

I make more changes.

I go to compile and that's when it tells me it can't write to the .exe

After a while (less than a minute), I can try to compile again and it works normally.

I suppose it's possible that I am not deallocating memory, but I use "vector <>" for most of the stuff I do and I clear them before exit.

Posting my code would be a huge file, so no, I won't be posting that. Not to mention, I'm wanting to publish this game.

Could it be an antivirus thing?

mhagain, I'll try that when I get home. it may be the problem.

I had this happen recently in an game I was writing in VS 2015. I was getting strange crashes in the middle of a procedural generation algorithm using std::stack. I was accessing memory in a way that caused the program to crash. Most of the time I could stop debugging and the program would exit fine. However, there would be random times where VS would get stuck doing something and not allow the program to shut down, even under Task Manager, forcing me to close and restart VS.

I do not have a solution, as mine involved finding and fixing the memory access bug and this is something in how VS starts and runs applications. I would hazard a guess that you're writing to memory somewhere you shouldn't and VS is having trouble as a result, but that is just a guess.

Let me be more specific in the sequence of events:

(I run this in "release")

I make changes to my code and compile.

I run the program to see if the changes did what I expected (sometimes it's not what I expected).

I exit the program and it dumps out to the compiler normally.

I make more changes.

I go to compile and that's when it tells me it can't write to the .exe <---

After a while (less than a minute), I can try to compile again and it works normally.

I suppose it's possible that I am not deallocating memory, but I use "vector <>" for most of the stuff I do and I clear them before exit.

That is a VERY different problem.

There are two common problems that trigger Visual Studio complaining that it cannot open the executable.

The first common cause is that it is trying to embed an application manifest into the executable. You can try turning off the feature in the project's manifest tool settings.

Basically this is a race condition, the system already has the file open for writing as it wrote out the file, then as it is finishing up another task tries to open the file to embed the manifest. It is possible for the first task to still have the file open for writing (or for the OS to not have released the file for writing) when the second task tries to open the file. Generally a file can be opened by many readers but only one writer. When it happens, you get the error that writing failed. Turning off the manifest embedding task avoids the error.

The second common cause are similar race conditions with the Visual Studio debug host application. You can turn off Visual Studio Hosting Process in the project's debug settings.

The debug hosting tool works like a bridge between your application and the debugger, but can get into a similar race condition. There are times when the hosting process is helpful, such as when the application uses OS-provided security and trust domains. It can also speed up attaching the debugger by a few seconds. You almost certainly aren't using those features. This can trigger the race condition when you tell the IDE to build and debug -- like the hotkey F5 -- and the build task has not released the file writer when the task host tries to also open the file for writing. Turning off the hosting process avoids the error.

There are other possible causes, of course. A virus scanner is probably not the culprit, because generally they open the file for reading. They also tend to prefer opening a shadow copy for reading so it doesn't interfere with another process writing the file and can still open files when an application claims they are locked, but that is a more advanced topic. It probably is not a virus scanner program, unless it is a particularly bad one.

A backup service like Crashplan will open a file and lock it during the upload. So that's a potential cause.

Is your application or any of the libraries that you are using spawning threads? Sometimes if you close the main thread while there are background threads running you might experience a long pause after shutting down until those threads are cleaned up properly.