4
votes

I have some problems deploying a simulation application to another computer. Up until a few weeks ago it worked fine to just check out the executable and required DLLs to the target machine. However, since recently I cannot start the application any more on the target machine without getting a windows (7) message stating that the application does not work correctly and needs to close. However, if I rename the application to any other name it works correctly. After renaming it back, it won't start again. It seems that the original name, which is "simspray.exe" btw, is somehow the problem.

Does anyone have an idea where the problem might be? (I am really curious despite having the rename workaround)

The application uses some libs, mainly qt 4.8.3, qwt, nvToolsExtension (nvidia), glew.

We have tried the following already: - use a completely fresh PC with newly installed Win7 - depends shows no missing dependencies - no anti-virus program running, windows defender and firewall disabled, no other third party security tools - application does not start from within visual studio either unless renaming the output exe name in the project settings

Thanks for any help.

1
Could this be similar to issue mentioned here? stackoverflow.com/questions/22103044/…Mathiasdm
I suggest looking into the event log (Control Panel + Administrative tools + Events) for some information and posting it here. I dont know of any windows process of that name that might cause failuresVrashabh Irde
Thanks for the ideas. Mathiasdm: This seems not to be applicable, the registry entries mentioned in the solution do not exist for my App. @Slartibartfast:Eventviewer shows Access violations (0xc0000005). However, either the debug stack trace is garbled or it crashes before reaching main.Thomas

1 Answers

0
votes
  1. If you have tried it on a completely fresh install then it can't be anything to do with the platform or environment, it must be something in the source code or build process.
  2. If it worked fine up until a few weeks ago then it must be a bug introduced in the last few weeks. Can you check your source control system for changes made in that time?
  3. Try varying the filename you rename to - do longer or shorter filenames have different results?

Try searching for code that uses the executable name in a stupid way, like this:

char buffer[sizeof(argv[0])+1];
strcpy(buffer, argv[0]);

or this:

int len = strlen("simspray.exe");
char *buffer = malloc(len);
strcpy(buffer, GetCommandLine());

Contrived examples I know, but both of these will buffer overflow yet magically appear to work if you rename the file to something of the right length.