I'm using a Windows 7 64-bit machine. I downloaded the express version of VC++ and the Windows SDK. I need to compile my code in a 64-bit compiler. When compiling, I get the following error:
"CL.exe" exited with code -1073741515
What does this error mean?
The value -1073741515 is 0xC0000135 in hex, which basically means "some dll not found". (http://www.qtcentre.org/threads/57083-1073741515-problem)
I found a very useful & generic guide to convert these cl.exe exit codes to human meaningful messages here:
Visual Studio 2010 C native compilation problem
To summarize:
convert the negative decimal exit code to a hexadecimal number (you can use the Windows built in calculator in the Programmer mode for this)
take the last 8 hexadecimal digits and search them in the table on the Microsoft NT status codes web page
One way I produced this return code with the full version of Visual Studio is to run the vcvarsall.bat script once for 32-bit and later for 64-bit. In this case, start a fresh command prompt instead.
The question here specifically refers to the Express edition. Express only supports compiling 32-bit executables, even on 64-bit Windows.
This error code is mostly due to missing dlls that are required by your program. There can be two solutions.
Locate the primary dlls that are required by your program. In my case specifically, I pasted SDL.dll in the binary directory.
After step 1, I still got the error saying packet.dll not found. So I installed WinPcap the main source of packet.dll
This is the procedure that I followed to resolve this error. Thanks
Related
UPDATE*
I made a excell addin (.xll file), with some math functions, compiled in c++, and it works normally in my computer. Well, when i try send to other person, isnt work. Excel's show a message like the file is corrupted, and when we try open it, open a sheet with some codes/words/symbols
I've tried to find a solution, but to no avail. But I found out what's the really problem.
After install Visual Studio (full version) in this machine wasn't working, the xll addin works!
So, I think I have a program, feature, component that I installed together with the visual studio (full version) that made the program run. I tried the SDK but was unsuccessful.
Could you help me please? I attached 3 images, one with the addin working and 2 with erros.
PS: i tried compiling version 32 bits and x64, for both excells, and happens in both excels (32 & 64 bits)
erro 1
erro 2
working
A colleague ask me to uptdate with the results of -dumpbin /dependents Addin.xll
Follow bellow:
File Type: DLL
Image has the following dependencies:
KERNEL32.dll
USER32.dll
MSVCP140D.dll
VCRUNTIME140_1D.dll
VCRUNTIME140D.dll
ucrtbased.dll
Summary
1000 .00cfg
3000 .data
4000 .idata
1000 .msvcjmc
A000 .pdata
29000 .rdata
2000 .reloc
1000 .rsrc
70000 .text
32000 .textbss
1000 .tls
1) Make sure what you send out to other persons are release builds, not debug ones.
2) Users who do not have the VC++ runtimes installed already will need to install the appropriate x86 (32-bit) or x64 (64-bit) redistributables from The latest supported Visual C++ downloads page (where the bitness depends on which x86 vs. x64 version of the XLL you send them, not on the bitness of their Windows installation).
MSVCP140D.dll
VCRUNTIME140_1D.dll
VCRUNTIME140D.dll
ucrtbased.dll
The 'D' suffix in those DLL names stands for "Debug". Those are the debug C/C++ runtime DLLs, which are used by the Configuration = Debug builds, and are installed as part of the Visual Studio setup. They are to be used during development, but not otherwise deployed, per Determining Which DLLs to Redistribute:
Debug versions of applications and the various Visual C++ debug DLLs are not redistributable.
During installation I get "The feature you are trying to use is on a network resource that is unavailable" and prompt to specify some path to vc_runtimeMinimum_x64.msi. After providing some path to required file I get error states that this file doesn't match required version Minimum Runtime 14.14.26405.
I finally found the solution reading this question: Install vcredist_x64 with VS2017 installer project
I realized that specific VC_Redist.x64.exe files could be downloaded by links like https://aka.ms/vs/15/release/26405.00/VC_Redist.x64.exe, where 26405.00 is exactly the version I was required to fix. Note, that you need version from error text after clicking OK, not from window title.
And the last point is that this exe must be executed from cmd with argument /repair to help me with this issue. Regular execution by double click made no effect.
I found the solution elsewhere. It said to
Fix problems that block programs from being installed or removed
https://support.microsoft.com/en-us/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
download troubleshooter button on the link.
Run it - choose option - have problem with installing - it lists programs - choose the missing / problematic visual c++ runtimes in the list
it will run and get fixed.
Repeat for each visual c++ you having problems with. I ran the program multiple times.
I have to thank this comment section for helping me with this problem, since I have not been able to work more efficently with my school, since I din't know what and if a single file somewhere deep down in the computer had to be deleted for this program to work.
I'm having trouble in running a program with CGAL and Boost library on Visual Studio 16. It shows a message saying the 'ALL_BUILD' path is not available, hence it is unable to start the program. What should I do?
ALL_BUILD is a convenience target that builds all targets. It is not an executable. Select another target in the solution, like a test or an example, to run.
When I compile my code in visual studio c++ 2008 I get the following error:
fatal error LNK1104: cannot open file 'C:\Users\...\Documents\Visual Studio
2008\Projects\...\Debug\....exe
I just copied my code from another project in visual studio C++ and pasted it in this project again in VS C++. Can it cause this error?
This can happen because, for example, the executable is currently executing or opened by another program, or because you don't have the right permissions for that directory.
open TASK MANAGER and see if the process of the .exe is running in background even after closing it. if yes, then kill the process and then try to run it again.
This can happen if you have turned on preprocessor output, e.g. in Properties | C/C++ | Preprocessor | Preprocess to a File == YES. Creating a preprocessor output file (of file type .i) is mutually exclusive to creating an object file (of time .obj).
In my case it was caused by the "Incremental Linking" option of the projects (Visual Studio 2015). Maybe because the files were also dependencies of other projects from the same solution, not sure...
I had the same problem (I don't say that this is exactly your case, but still) and it was quite strange because when I changed the code a bit everything worked normally... And I just found out that my antivirus blocked the .exe file as a possible threat (idk, mb it didn't like how I worked with memory by my C++ program). So, the source of LNK1104 can also be the antivirus.
I have a C++ Visual Studio project which I'm trying to compile for x86 and x64 architecture. I've googled and found a lot information how to do it and it seems to work, but it left me deeply confused about what is going on behind the curtains.
Apperently, the only difference in the settings is a switch in the linker command line flags (to be precise, it's the /MACHINE flag).
If that's the case however, then the object files of the compilation must be platform independent - which is somehow the exact opposite of what I always assumed it to be, since object files are supposed to be sequences of machine code which in turn should be platform dependent.
So, my question is: which part(s) of the build process does not behave the way I thought it would?
Thanks for your time and wisdom!
Michael
When compiling for 32-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\cl.exe. When compiling for 64-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\amd64\cl.exe. The first compiler produces 32-bit object files, the second produces 64-bit object files. This can be seen by running dumpbin.exe on the object files to see their specified architecture.
The compiler invocation remains the same (more or less) -- what changes is the executable $PATH that is set before building. By pointing the PATH to the 32-bit or 64-bit directory, it sneakily changes the whole set of programs that is run to build your project. You can see this by looking at the Project Properties > Configuration Properties > VC++ Directories > Executable Directories, and clicking on "Edit". In the "Inherited Values" box you'll see the path for the current Configuration and Platform.