Execution error with a C++ application deployed with InstallShield (windows) - c++

Question

I have a simple C++ program (command line with Boost libraries) that I developed under Visual Studio Community 2013. I want to deploy it on other Windows computers, so I am testing InstallShield LE in Visual to do so (I am new with InstallShield). I added an InstallShield project in the current solution and I managed to create a setup.exe.
When I test it on another computer, setup seems OK but when I try the application, I have weird error:
MyProgramm.exe --help
Sends correct result (but it is not really interesting).
MyProgramm.exe -i InputDirectory -o OutputDirectory
Fails with a Windows displaying this message:
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.
What did I miss?
I built Release configuration only. How can I be sure that I have checked all the merge modules or InstallShield prerequisite ?

Answer 1

You will have to identify what is going wrong. Typically the symptom you describe indicates that an exception caused the process to terminate. One common source of such exceptions is misuse of an invalid pointer.
But why does it work on one computer and not another? Depending on the code it could be random incidental things. But as long as this repeats every time, it's more likely to be environmental. This could mean a missing data file, a missing registry key, a missing service, or a missing .dll dependency.
Because you can run the program at least one way, you know it's not a static dependency. If it were, you'd get a message about an inability to load some file or one of its dependencies. But instead in some execution paths you see a crash. So if it's a dependency, it's what InstallShield calls a dynamic dependency. I'm not personally a big fan of it (I'd much rather be told exactly what might be required), but there is a dynamic dependency scanning wizard that can help identify such files and include them into the project.
That will only help if the problem stems from something like this:
HMODULE hMod = ::LoadLibrary(TEXT("SomeFunky.dll"));
SOMEPROC proc = (SOMEPROC)::GetProcAddress(hMod, "SomeFunkyProc");
int result = proc(some, args);
Or maybe from a COM-related variant of that that looks something like this:
CComPtr<ISomeFace> spSomeFace;
HRESULT hr = spSomeFace.CoCreateInstance(CLSID_SomeFace);
hr = spSomeFace->SomeMethod(some, args);
The common problem here is that neither of these blocks of code verifies the function it's calling is safe to call. In the first case, proc (or even hMod) could be null; in the second, spSomeFace might not have been successfully created an instance. While the code can (and should) prevent these scenarios from crashing, fixing the crash will not get your application to actually do what it's supposed to, and you'll still have to fix the reason that the procedure, dll, or instance could not be initialized as desired.
It's also possible that you're missing a data file or registry key that at some point is being used in an incorrect fashion. For example, the code may assume a data file exists, build a pointer from data it reads, and fail to work correctly because the file wasn't available and thus the buffer it read into was never actually initialized.
So in short, to solve this, if it's not a dependency scenario that the dynamic dependency scanner can assist with, you may have to debug the code in question. You could try tools like Process Monitor and look for errors that involve your application shortly before the crash. If you have source and symbols, you could try running the program under WinDbg to figure out exactly what was crashing, and then try to figure out why it does so in one environment but not another. But from just the information you've already provided, there's nobody that can tell you the answer.