Thread: renaming executable file causes access violation

On rare occasions, if I change the name of a the executable file after compiling it, it will no longer open.

Most recently, a piece of software was running successfully for over a month, and then would no longer open after being closed.

Recompiling the source on other computers did not produce the error, however, the problem persisted when transferring the malfunctioning exe to other computers.

An executable freshly compiled and moved with it's entire project directory would run when transferred to the computer where the error occurred, but an error would recur if the exe was renamed.

Written using Borland C++ Builder 6, on Win XP. Application is multithreaded.

Any ideas on what is causing this and how do I avoid it?

Does your project include DLLs linking back / using functionality from the main application? In this case the name of the exe file during compile time is mandatory and must not change

i'm not sure how to tell. i can say that the application is statically linked though.

i should also again stress this happens intermittently, and only on very rare occasions. the same application file functioned for almost two months and then suddenly would not reopen.

1. Does the program still have a .exe extension?
2. Why are you renaming it in the first place?
3. Are you running it by double-clicking the .exe file, or are you using a shortcut pointing to it?

1. yes
2. because the project still has a generic title, and the IDE doesn't allow spaces.
3. the exe file itself

i am sure.

An executable freshly compiled and moved with it's entire project directory would run when transferred to the computer where the error occurred, but an error would recur if the exe was renamed.

i.e. it would run on the tool computer when the exe was copied with its entire project directory, but once it was renamed, it would produce the error again. i should have changed the name back to confirm the inverse, but i did not. (you start to go a little crazy after 8 straight hours in the cleanroom)

It seems that once this error starts to happen, it is persistent; however, the onset of the problem happens sporadically.

After renaming and crashing, if you rename it back to what it was, does it start working again?

Is there a way you can run the crashing program in a debugger and find out exactly where it's crashing? Or maybe enable some tracing to log details to a file and see how far that gets?

Originally Posted by cpjust

After renaming and crashing, if you rename it back to what it was, does it start working again?

i'm not sure! i started going bonkers because by the time i had narrowed it down to changing the filename by an excruciating process of elimination, i'd been in the cleanroom for about 8 straight hours and i was just focused on getting our tool running again and getting the hell out of there!

it occurred to me though that i might have seen this once before on my development computer once before several months ago. i'm not 100% sure on that, but just for the sake of argument; let's say i did, and i changed it back to the default name, and the error went away. any clues what that might mean? linking error?