I have a large program developed in fortran. When I try to run two instances simultaneously either as a single user or through two different user accounts on the same machine, only one instance will runn while the other will report "The system cannot execute the specified program.." without any other notification.
Did anyone have a similar problem?
Are you asking us to guess what you are doing? Asking Windows to use the same I/O buffers for both programs e.g. by having both write to stdout rather than taking care that they don't compete for a single output destination?
Thank you very much. The two instances of the program are run by two different users on teh same machine. They are run from two different folders and both reading and writting is in completely separate folders. Other fortran programs run simultaneously without any problem in ths configuration.
I have even tried to rename the program and recompile it with different name to be run by two different users but the results is the same. It allocates large arrays though... However these are much smaller than the memmory available.
I hope this helps? Please let me know which info would be useful so that somebody can advice....
Thank you again.
I "Googled" the message and there are many reports of the error, though none I saw due to running the same program simultaneously on the same PC. The most common reason for this error is failure to find the versions of the Microsoft Visual C++ libraries as specified in the executable's manifest. Links: 1 2 3 A secondary reason is that the executable has a property that it was downloaded and Windows has blocked it, but this seems unlikely to be relevant here. Link.
The Windows Event Viewer likely has more information, though it can be a baffling thing to dig into.
Now you will see only the SideBySide errors. See if there is an event at about the time you encountered the problem and, if it mentions your application, see what it says. Don't be alarmed by other entries here - they tend to be harmless.
I am going to make a guess based on my reading. The executable was built as a Debug configuration and won't run unless the user environment is set up for doing Visual Studio development. If you built as a Debug configuration, try building as Release and running the Release build instead.
Thank you very much for your very useful comments. I am compiling Release Win32 configuration. Tried x64 but it doe snot make any difference. I also tried the to find any event in the SidebySide and it did not report this event.
I think this may be due to missing of some libraries... So I will try to cehck that and if you can think of any other reason why that can happen, I would be most thankful for your thoughts.
Usually if libraries are missing you get a more informative message. You may want to go back to the event viewer and this time filter by application name.
Another possibility is to use Process Monitor and to get a log from successful app execution and a separate log from failing app execution.
A big problem with Process Monitor is that it produces a huge amount of information, so it can be hard to find out exactly what happened. But if anything failed (e.g., missing DLL, missing Registry key), the failing error codes and corresponding messages will be in the log... if you can find them.
Looking at the Event Log may be an easier first step, before using Process Monitor.
Dear Steve and Eugene, most useful suggestions, thank you. Despite I could not find much on event monitor or Process Monitor, I narrowed this down. The program runs OK with multiple instances on the PC which has installed Vsial studio. But on the machine without VS it does not run in parallel. Single instance works well. So, I think I need to continue digging into which libraries are missing. Thank you both for your help so far.
Another possible solution - what happens if you build the executables using static libraries instead of DLL's? Can two versions then run simultaneously? I suspect this is the case, because I have a program that divides a large datafile into 4 chunks and then shells four copies of itself to process the chuncks in parallel, and I have never experienced this problem.
(I know that someone will say why not make the program itself parallel, but it is a complex legacy program developed over 35 years, and attempting to parallelize it is just too much work that no-one will give me the time to do!)