When I run on my working machine (win7 VS2010 ultimate sp1)
int main()
{
unsigned i = 5;
i %= 0;
return 0;
}
or
int main()
{
int * ip = 0;
*ip = 4;
return 0;
}
and I get Integer division by zero unhandled exception. When I hit break button, to see the problem, my Call stack contains only msvcrt100d and ntdll and Visual studio breaks me inside file mlock.c on the LeaveCriticalSection( _locktable[locknum].lock ); line.
When I run this code on another machine(win7 VS2010 proff sp1), VS breaks it exactly on the problematic line i %= 0; od *ip = 4.
This mistake was hidden somewhere within my project and I wasn't able to find it till I run it on another machine. How can I fix this behavior? I need to see it on my working machine.
I have a clean installation of Windows 7, clean installation Visual Studio 2010 and VS-SP1.
My project should not be ruined. I generate it using CMake and same project working fine on non-working machine.
Any advice would be greatly appreciated.
Ok, I have found a solution.
In VS go to exceptions settings (ctrl + alt + e) and check Thrown in required Win32 Exceptions.
More info can be found
here and here.
SO related question here.
When you compile a program with VS it creates the EXE file and a PDB file with all the relevant debugging information of the program. Also, the absolute path of the PDB if embedded into the EXE.
When the EXE crashes and you use VS to debug it, it tries to find the corresponding PDB, both in the same folder than the EXE and in the absolute path embedded in the file. If you want it to be able to debug the program, then you must copy the PDB along with the EXE. Note that these two files must come from exactly the same compilation, or else it will not work.
Then, the VS debugger will try to show you the sources of the program, again using the absolute path of the *.c or *.cpp files embedded in the PDB. Obviously, if you want it to stop in the relevant line, you need a copy of the sources! If you copy the sources to the very same path than in the original machine it should work without problems. If not, you have to open the Call stack window, double-click over the main function and it will ask you to browse for the actual sources.
Or maybe your setup is screwed...
Related
I'm trying to get into SDL2 in C++ and I have followed all the steps in a variety of YouTube tutorials. I am using vs2019, and every time I try to run anything I get this error: Failed to locate: "CL.exe". The system cannot find the file specified.
For example, it happens when I try running this code:
#include "SDL.h"
#undef main
#include <iostream>
int main() {
int x = 1;
std::cout << "Hello World!\n";
std::cin.ignore();
return 0;
}
I have followed all of the steps, but nothing seems to work. Similar questions have been asked, but their solutions don't work for me. I'm just running it in the editor. Can anybody help me?
You need to run VCVARSALL.BAT for Visual studio 2019 in the console for making cl.exe available.
Alternatively you can run "Developer Command Prompt for VS 2019" from the Start menu and run cl.exe there (after changing the appropriate working directory to one containing your code).
I am going to post this as a potential answer, pending OP’s clarification to what he means by “running it in the editor”.
MSVS does not install with the C and C++ compiler and libraries unless you specifically ask for them. To install them you must re-run the installer. You will eventually get a screen with a lot of different options on it. It is a tabbed page with “Workloads”, “Individual Components”, and “Language Packs” at the top.
Find and make sure that you select both:
“Universal Windows Platform development”
“Desktop development with C++”
Continue as usual. The installer will update MSVS with the ability to compile C and C++ programs.
You can also read Microsoft’s instructions.
It's basically a Hello, World application with all vanilla settings with the addition of one external library and an init to it. The program takes about 21 seconds to run within Visual Studio using the debugger (F5 or Start Debugging), but runs instantly otherwise. Happens in Release and Debug.
The library is for the Julia programming language. I include it's lib and header directory and simply call jl_init(). Half the stall happens before the line is even hit.
From the command line (cmd to the project dir and type x64\myprogram.exe) or Ctrl+F5 it runs instantly.
From Visual Studio using F5 or hitting "Start Debugging" take about 10 seconds to even reach the jl_init() line which is the very first line of the program. Then another 10 seconds to get through it.
int main(int argc, char** argv)
{
jl_init(); // takes almost 10 seconds to reach this line, before it even runs.
printf("Hello, World!\n"); // takes another 10 seconds to reach this line.
return 0;
}
I'm on VS 2019 v142. Windows 10. The project is on a local SSD. I'm not sure how to tackle this problem. Any ideas?
Edit:
It could be related to loading symbols, but these files are mostly build without symbols though:
'Julia.exe' (Win32): Loaded 'D:\Program Files\Julia-1.6.2\bin\libjulia.dll'. Module was built without symbols.
I'll add that I went into Tools>Options>Debugging>Symbols and selected "Load all modules, unless excluded", then added these dlls into the list of excluded modules. I also unchecked all symbol file location checking in the same dialog. I don't see any indication in the output or the modules debug window that my changes took effect. I also tried disabling ALL symbol loading in Tools>Options>Debugging>Symbols by selecting "Load only specified modules" and specifying no modules. Making these changes didn't help.
I think it's definitely related to dll loading but don't know how.
Edit 2: disabling Tools > Options > Debugging > General “Load debug symbols in external process” made the stall go from 21 seconds to about 12, which indicates it's symbol related.
One of possible issues here is PDB loading.
PDB's are needed to debug libraries, and help debugger resolve callstacks when there are functions from that library in it. In many cases you can debug your app just as well without most of them loaded.
You can disable automatic loading, or set whitelist of modules for which you want to load PDB's following Microsoft documentation: https://learn.microsoft.com/en-us/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2019#symbol-file-locations-and-loading-behavior
I am new to C++ and I am using the free version of Microsoft Visual Studio 2019.
I have written a small code which I use to integrate some differential equations (by using odeint libraries provided by Boost).
After the integration process ends, the time evolutions of the state variables are stored in the matrix mat (I use the Eigen libraries to define it row by row):
MatrixXd mat(t,4);
for (int i = 0; i <= t-1; i++)
{
mat.row(i) << times[i], x_vec[i][0], x_vec[i][1], x_vec[i][2] ;
};
Then I save the content of the matrix in a .txt file:
ofstream file("mat_save.txt");
if (file.is_open())
{ file << mat << '\n'; }
file.close();
However the .txt file is created only if I run the code in Debug mode, while if I only compile it the file is no longer created and no output can be displayed in the Console, since it is only opened when Debug mode is chosen.
Is there a way to make the Console appear and remain open and also to make the .txt file to be successfully saved, simply "compiling" the code avoiding debugging?
If so, I would save lot of time because the debugging is quite slow.
Thanks in advance!!
I'm not sure if by debug you mean running the code in Visual Studio vs compiling and then running the created exe. It Kind of sounds like a relative path issue.
Try using a full path. Or try opening a command prompt, cding to the path with the exe and then running it and check to see if the file is created in the folder you cded to.
You can also try opening the exe in Visual Studio like it was a project. Another thing to try is attaching VS to a running process to debug: http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx
The Windows Powertool "Handle" can display what handles a process is currently using which could be useful in determining if it is writing a file somewhere unexpected: https://learn.microsoft.com/en-us/sysinternals/downloads/handle
I am working on Windows 8 with OpenCV 2.4.13 and MinGW 4.9.
I wrote a simple and small opencv program to check if everything was installed properly. Following is the code:
#include <opencv2/highgui/highgui.hpp>
int main () {
printf("in main\n");
for (int i = 0; i<10; i++) {
printf("here\n");
IplImage * image = cvLoadImage("C:/{...}/test.jpg");
cvReleaseImage(&image);
}
return 0;
}
I compiled it with the following command at the command prompt:
g++ -o test test.cpp -LC:\{...}\opencv\build\x64\vc11\lib -lopencv_core2413 -lopencv_highgui2413 -IC:\{...}\opencv\build\include
{...} is the path to the specified folder/file.
This command runs properly and compilation is successful without any errors. However, when I run it with:
test
in main and one here gets printed after which I get the error message as 'test.exe has stopped working. Windows is looking for a solution.'
What all I have tried:
For installation of OpenCV, ran the downloaded opencv executable file (which extracts all files) and added the system variable OPENCV_DIR and edited the system PATH for location of DLLs (which reside in %OPENCV_DIR%\bin) as per:
http://docs.opencv.org/2.4/doc/tutorials/introduction/windows_install/windows_install.html#installation-by-using-the-pre-built-libraries
Tried adding the required DLLs in the same directory as the .exe.
Tried doing the whole thing from vc12 directory.
After the error message appears, it gives an option of debugging. On pressing that, the Just In Time Debugger opens up and says 'An unhandled win32 exception occurred in test.exe'. I googled this and tried inspecting the registry key as directed here
https://support.microsoft.com/en-us/kb/811191
but it was already properly set. So, there was nothing for me to change in that.
Nothing is working for me at all. Please let me know if any more information is required. I'm desperately looking for a solution to this.
For those who might be encountering the same problem, I compiled the program with OpenCV dynamic (.dll) libraries instead of the .lib files and it ran just fine at runtime for some reason.
I am MFC guy working on visual studio 2010 create some executables using visual studio!! but on linux and mac my executables are not working as usual windows!!.
So i decided to use "MinGW" compiler to create executables.
Note:-Please give me one suggestion is that," is minGW is best compiler for cross plateform working ??or any thing else is there??"
I successfully install WinGW compiler on my C drive and start working with following program..
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello ";
return 0;
}
I compile it using following command,
g++ -static-libgcc -static-libstdc++ Main.cpp
I found one executable in same folder with name a.exe :).Working fine:)
But after some time i decide to modified same program in following manner like,
int main ()
{
return 0;
}
I compile it with same command but when i execute it using command line it show me error "Access is denied so i goto that folder and run same executable as "Run as Administrator" it show me one messagebox with the message windows cannot access the specified device path or file. you may not have appropriate permissions
---EDIT--
follwing code is NOT WORKING:-
int main ()
{
int k;
return 0;
}
but this program WORKING :-
int main()
{
int k;
k = 0;
return 0;
}
If you are getting this access denied error, then the most likely cause is that the executable file is open in another process, probably the linker or debugger. Try installing Process Explorer and hit Ctrl+F and type in the name of your .exe. This should show the processes that the .exe file open. Kill those processes (or if you are still debugging, then end debugging first). You then should be able to build again.
Note that this has nothing to do with Microsoft APIs, as in any case you're using gcc.
EDIT: If there are no processes holding the .exe then it may be that there is some other kind of permission problem. Does the .exe file exist? Can you delete the file and rebuild? Another thing to try is run Process Monitor and filter for the name of the .exe -- that may show a regular permission denied error, or perhaps another error such as a sharing conflict.
Note:-Please give me one suggestion is that," is minGW is best compiler for cross plateform working ??or any thing else is there??"
No. And there's nothing else out there.
Use whatever compiler is available on target platform, ensure your code compiles on all of them.
Avoid platform-specific and compiler-specific code at all costs (use cross-platform frameworks).
I successfully install WinGW
There are many different versions of mingw provided by different sites. If you install compiler from mingw.org using mingw-get, it'll probably work. If you install mingw from some other site, it may or may not work.
I compile it using following command,
Use a build systems. cmake, qmake or something similar.
it show me error "Access is denied
Launch process monitor and see after which system call it terminates. It is also possible that your antivirus software interferes with your program, or maybe there's some stray dll in your path or something like that.
Check the permissions for the entire folder in which the executable resides. Trying to 'Run as Administrator' doesn't have any effect if the folder doesn't allow the permissions.
It doesn't have anything to do with your code. This is an environmental problem, something is pretty messed up about the permissions your user account has for one or more of the directories on your hard disk. The generic diagnostic is that the default working directory for the program does not permit read or list access.
A possible starting point would be to use Explorer and right-click the directory where MinGW is installed. Use the Security tab and ensure that your user account has all permissions enabled. Further narrow it down to trying to run the program from the command prompt, using different directories as the default directory.