I recently developed a Visual C++ console application which uses inline SSE2 instructions. It works fine on my computer, but when I tried it on another, it returns the following error:
The system cannot execute the specified program
Note that the program worked on the other computer before introducing the SSE2 code.
Any suggestions?
PS: It works when I compile the code on the other computer and run it. I think it has something to do with the manifest from what I've scrounged off the net.
Most likely the use of the SSE2 instructions is requiring a DLL which isn't present on the second system.
Here's a blog entry on how to figure out exactly which one:
How to Debug 'The System cannot Execute the specified program' message
If you've built a debug version , a Release build might work on the other machine.
If not, you need to figure out which Microsoft Visual C++ Redistributable your program requires and install it on the other machine.
Related
It's my first time using Visual Studio 2017. I built a simple program in C++ on my PC. I was curious to see if my program works on another PC. I tried to execute the .exe on the other computer and it gave me this kind of error:
vs(some letters and numbers).dll is missing.
I assume that the .dll in question is part of Visual Studio.
I tried on a third PC, and this time the cmd stops working and becomes unresponsive after I execute my .exe.
I also have this problem when I compile with MinGW using the g++ compile feature in the cmd. When I execute the program compiled with MinGW on another PC, it gives me the same error, but this time it says something like
gw...dll is missing
Is there a way to avoid this error without installing the Visual Studio (or MinGW at this point) on any other PC I want my program to run on?
If you're interested in the code, I can put it here, but I don't think it's the problem here because I have the same issue for every other .exe compiled on my PC.
Here's a picture of the error:
In case of Visual Studio, you need to install Visual C++ Redistributable libraries or provide the libraries that are required by your application with .exe file (I am not sure if it violates license or not though).
In case of MinGW, you need to provide required DLL as well. I guess that you need libgcc_s_dw2-1.dll and libstdc++-6.dll, but you would better check it yourself. And remember about the license.
You may use Dependency Walker to analyse dependencies of your application.
UPDATE (2017-12-12):
I've missed the time you posted the screenshot. As far as I see from it the problem is that you are trying to run debug version of your executable: ucrtbased.dll is the debug version of the ucrtbase library and is only available (from what I know) from Visual Studio distribution. If you want to run your application on the computers that do not have installed Visual Studio, then you should use the Release version of your application.
In order to understand your problem you need to understand the concept of DLL.
Dynamic-link library(DLL) - As described by Microsoft:
A DLL is a library that contains code and data that can be used by
more than one program at the same time. For example, in Windows
operating systems, the Comdlg32 DLL performs common dialog box related
functions. Therefore, each program can use the functionality that is
contained in this DLL to implement an Open dialog box. This helps
promote code reuse and efficient memory usage.
So to put it simply, DLL is basically a bunch of compiled code, which is being linked to your code at load (or even run-time). Now, of course if your system is missing the DLL, your progrem will fail to work. To make things even worse, DLL are sensitive to the compiler that was used. So each DLL might have multiple version, so you will need to right DLL.
Now to the problem itself, the error message are the best way to start. They guide you what DLL are missing, and what is their name. For instance in your case "vs*.dll" is most likely related to Visual C++ runtime redistributable.
Finally, please note you have another consideration to make in addition to make your own system work: Every one that will use your code might face the exact same problem. So if you actually intend to share your .EXE with other people, you will need to understand how to guide them, or even automate their installation process.
I am trying to learn how to successfully compile "Sparse Modeling Software" (SPAMS) in my machine which uses a Windows 8.1 OS and MATLAB R2014b.
The steps I have taken are as followed (some parts might have been unnecessary or missing)
Step 1. Installed "Microsoft Visual C++ 2013 Professional".
Step 2. Installed "Microsoft Windows Software Development Kit (SDK)".
Step 3. Download "spams-matlab-v2.4-svn2014-02-18.tar" from http://spams-devel.gforge.inria.fr/
Step 4. Unzip it in Windows using 7-zip. Only 1 error I received but all he other data were uncompressed. The error is this :
ERROR: Can not set reparse data: C:\Users\Yashar\Desktop\spams-matlab\cpp_library\spams.h
Step5: In MATLAB, I set the compiler:
>> mex -setup C++
message I recieve:
MEX configured to use 'Microsoft Visual C++ 2013 Professional' for C++ language compilation.
Warning: The MATLAB C and Fortran API has changed to support MATLAB
variables with more than 2^32-1 elements. In the near future
you will be required to update your code to utilize the
new API. You can find more information about this at:
http://www.mathworks.com/help/matlab/matlab_external/upgrading- mex-files-to-use-64-bit-api.html.
Step 6. Open compile.m in SPAMS (as recommended) and run it. The error I get looks like this:
compilation of: -I./linalg/ -I./decomp/ -I./prox/ -I./dictLearn/ dictLearn/mex/mexTrainDL.cpp
Error using mex
C:\Users\Yashar\Desktop\spams-matlab\Files not found; check that you are in the
correct current folder, and check the spelling of
'C:\Users\Yashar\Desktop\spams-matlab\Files'.
Error in compile (line 391)
mex(args{:});
Question : What I am doing to me looks pretty standard but I know it takes a while learning how to cope with issues with regard to interfacing codes with MATLAB, etc. Can you please help me with getting around the problems I have and managing to compile SPAMS toolbox in my machine? FYI, I am interested in using mexLasso function in this toolbox.
Hmm. Compiling this toolbox is a bit tricky.
Here is how I do it in Windows 7 + MATLAB 2013a.
Hope it works for you.
(I don't have the issue of unzip)
First, you want to make sure that 'mex' works properly, I have compiled some smaller packages and they worked in general.
Second, change the line
compiler='gcc';
to
compiler='mex';
Third, you can find a lot of lines look like
-I./linalg/ -I./decomp/ -I./prox/ -I./spams/dictLearn/ dictLearn/mex/mexArchetypalAnalysis.cpp
Here 'I./lib_name/' is Linux style path, and you need to change it into something that Windows can understand.
Here is an example:
-I./linalg/ ---> -IC:\Users\XXX\Downloads\SPAMS\linalg
There are totally six pieces that you need to change as following,
-I./linalg/
-I./decomp/
-I./prox/
-I./dictLearn/
-I./dags/
-I./image/
After replacing these strings, just run compile.m, then it should work.
Select 2.5 version the SPAMS software you are running for Windows version. Set the compiler to VS in compile.m and execute the code. This generates the required files. Finally run start_spams.m, which in turn creates the source folders. Now you can run the respective code.
I have written a C++ code that uses some of the Qt static libraries.
I compile the code using MSVS2010 (on Windows 7) and then run the created .exe-file on a second machine.
I have compiled the exact same code on the same machine 2 different times and the .exe code that is generated crashes on the second machine when that machine's (Windows XP) screen saver starts, I have compiled the same code another time (nothing has changed in the code or the compiler or its settings) and the generated .exe-file does work fine.
Has anybody an idea on what can cause this?
Is there a way I can debug this issue?
Could the fact that at different times maybe different other programs are open affect the compilation?
The problem is not with the compilation process (it will always produce the same binary provided you didn't change the sources) but with the execution environment.
There seems to be something on your second machine that makes your program crash intermittently (or it could well be that it has nothing to do with that second machine, and that your program crashes intermittently everywhere). To debug that, you may end up having to install a debugging environment on the second machine and hope the problem arises again, or you could also try to reproduce the crash on your development machine.
I developed a small c++ program in Visual Studio 2012 on Windows7, 64bit (let's call it PC1). On that pc it runs fine!
Since I didn't have a versioning control system like SVN at hand, I copied ALL the project data (the exact folder structure, DLLs, source files, project files...) to a usb stick and moved it to another computer.
On that other engine there's Visual Studio 2010 on Windows7, 64bit (PC2).
So I just changed the platform toolset to v100 as described here.
I successfully compiled the project on PC2 (clean, build) and wanted to run the exe, but the command prompt stayed empty.
I then tried to debug and added a breakpoint at the very first line of main - which wasn't reached, the command prompt was still empty.
Ok, a usb stick is certainly not the most secure solution for data storage, so I gave it another try and moved it again - the problem remains.
Visual Studio's output on PC2 is the same as on PC1, so I couldn't find any anomalies there.
Yeah, there might be many error sources, so where can I start?
And how can I get a more verbose output for troubleshooting?
Or is this even a common phenomenon (perhaps due to different VS versions) and there's an simple way fix it?
This is not a full solution, but at least I'm a tiny step ahead:
In my last comment I wrote:
I took your advices into account and created a brand new project on PC2, VS2010. I exactly followed this guide: http://frozenhamster.wordpress.com/2011/02/11/lapack-on-windows-with-visual-studion-2010/
That didn't work either, so I removed I "out-commented" everything except for a single cout. Voila, that worked!
But as soon as I make use of the desired Armadillo (LAPACK and BLAS), the project compils but does not run.
What's going wrong here?
I don't get any compiler errors!
Im trying to deploy a C++ AMP application to another Windows 7 machine.
I have tried to include the vcamp110.dll in the same folder, and also compiled with /MT do get rid of dependency on msvcp110.dll and msvcr110.dll.
Also tried both x64 and win32 release of the application.
On the computers i have tried it on whitout VS11 installed, the program stops responding.
I tried to do a simple test with the hello world application and i have the same problems there.
The files can be downloaded from here http://www.2shared.com/file/IofZlrJs/amptest.html (source, binary and the dll).
Any suggestions to how this can be fixed?
Deployments like the one you tried are definitely supported – full details here:
http://blogs.msdn.com/b/nativeconcurrency/archive/2012/03/12/deploying-apps-built-with-c-amp.aspx
There are a few things you can do to diagnose the issue you are facing yourself:
The bitness of vcamp110.dll has to match the bitness of your app, so 32bit for one means 32bit for the other.
Ensure that there are no other instances of vcamp110.dll in some central location (e.g. system32)
Attach a debugger and see what DLLs are loaded and what exception gets thrown.
Most important of all, for all your apps, surround your parallel_for_each call with try…catch to see what runtime_exception you are getting. More on C++ AMP exceptions can be found here: http://blogs.msdn.com/b/nativeconcurrency/archive/2012/02/01/c-amp-runtime-exceptions.aspx
For the specific repro you shared, we tried that under the debugger on a clean Windows 7 machine and indeed a rutime_exception is being thrown: “The binary for the parallel_for_each is incompatible with this version of runtime.”, which indicates a mismatched runtime version (either mixing bitness or mixing Developer Preview with Beta or something like that).