In this case I do have the source for both the application and the dll.
When both are compiled without /NXCOMPAT, they work together fine. But when I compile both with /NXCOMPAT, I get a segfault deep in kernelspace.
If I compile the dll with /NXCOMPAT, and compile the executable without, it also works fine. (not surprising I suppose, since the DEP settings for the executable get forced on the loaded dll.)
I have previously seen a segfault in MainCRTStartup (Note: not the dll version), after enabling DEP, which was caused by another linker option. However, in this case that other linker option is NOT set, so I know that's not the answer.
Anyone have an idea where I should look for the cause?
Edit: Further strangeness. I've been running this in the debugger in VS 2008 the whole time, but when I tried running it without the debugger attached, the segfault disappears. I find this a very unsatisfactory solution, as I still don't know why it's been doing this.
Edit the 2nd: Also segfaults running in the debugger in VS 2013 Express.
Lacking code, we have to guess by the symptoms. My crystal ball says you're doing things inside LoadLibrary (i.e. inside DllMainCRTStartup) which are banned. And there is a very long list of things which are banned in LoadLibrary, including loading any other DLL.
Note that your global objects are created from DllMainCRTStartup and therefore have to respect the LoadLibrary rules as well.
Related
I tried to run a program I wrote on a remote computer. As I knew there might be a dll problem, I set the runtime library option to /MT, so I can rely on static linking.
However, I still receive the error message on my remote computer, stating that MSCVP140.dll is missing. Isn't this what the /MT flag should take care of?
I even tried to install the redistributable, but no luck. I'm still stuck with the error.
Another thing I tried was placing a MSVCP140.dll I downloaded in the folder, but that way my program is simply crashing on startup. I suspect that the MSCVP140.dll version is not the expected one, so I'm not relying on the validity of this test.
Any ideas?
Try to open your exe with depends.exe and find the dependancies in the machine it crashes. Probably the MSVCP140 might have other dependancies. Copy all dependancy dlls into same folder and give a try.
Someone please punch me for being this stupid... I was compiling on x86 instead of x64 all the time. No surprise the dlls didn't work.
Thanks for the help nevertheless. At least you got me on track to take a closer look at my dlls.
I'm using QtCreator with the visual studio 2015 kit on windows 8.1 to build a program I developed and tested on Linux, on linux it works correctly, but on windows it's just crashing immediately, and I have no idea what to look for.
The only external libraries, aside from QT I'm using are opengl and glew, so I don't think it's those.
Is there anything that's known to work in GNU C++ but crash immediately in MSVC?
Usually this kind of crashes have absolutely nothing to do with your program. It's an external library linking issue. I had this issue recently with the OpenSplice DDS library. I linked to a library that caused a segmentation fault before anything started. I resolved the issue by linking the pre-compiled libraries 1-by-1, and check each if that fixes the program.
What I recommend you to do is: Remove the libraries and resources you're linking to gradually, until your program starts and prints "Hello world" from the first line of main().
Another way to go is, make a new empty program, and link the same resources you're using in your program. This is easier, as it doesn't involve modifying your program.
This is what I would do.
Start by rebuilding the entire solution or project from a clean state. Just in case this is just some weird dependency issue that resulted in something not getting recompiled. Never hurts.
As Neil said in the comments for the question, the crash is possibly coming from a global variable who's constructor runs before main or WinMain. Are you sure you don't have something declared as "static" or at global scope that might have a constructor?
Now do the following:
Open Visual Studio.
From the menu, select File->Open->Project/Solution...
When the file open dialog pops up, select the EXE produced by Qt
Creator. (That's right - you are opening the EXE as a project). This directory is typically one folder level above the Qt project (..\build-yourapp-Desktop_Qt_5_7_0_MSVC2015_32bit-Debug\debug)
Now press the green arrow to start debugging (menu->Debug->Start
Debugging). If all goes well, your program will fail early and
Now chances are high that the program is not going to run at all under Visual Studio because Qt Creator doesn't copy all the Qt*.dll binaries to your build directory. You'll get a bunch of dialogs popping up saying that "The program can't start because Qt5-XYZ.dll can't be found". This is easily fixed by updating your PATH environment in any of the following way to include your Qt5.x.0\5.x\msvc2015\bin folder to your PATH.
You add it from the command linke and then re-launch devenv.exe from the command line.
You can add it globally from Control Panel->System->Advanced. Then restart Visual Studio from the Windows desktop.
With the EXE debug project open from within Visual Studio, just right click on the project name (not parent solution) and a dialog will popup that allows you to edit startup settings. One of which is the Environment.
And that should do it. From there you can start the debugger on your EXE, set breakpoints as needed, and analyze the call stack on crash.
It's really easy: build all the libraries you use, including Qt, with debug information (those can be release builds as long as the PDB files are generated). Then run your application under a debugger (e.g. F5 under Qt Creator), and it will stop at the point of the crash.
The code that runs before main and is known to cause trouble will be the global object initialization: you're likely running into the static initialization order fiasco.
Another cause for the problem could be stackoverflow. In Linux, the stack size by default is usually 8 MB whereas in Windows it's just 1 MB.
Try to link with /STACK:8388608 switch. If it works, you might consider allocating more data on the heap and stay with the default stack size of 1 MB.
This is somewhat an addition to this question (MSVCP140.dll missing).
I am trying to compile a program for a windows machine. Something huge to note here is I do not have the privileges to install software on it, but I may run executables.
Every time I run it on the windows machine in question I get a missing MSVCP140.dll problem. I have followed the solution of the question I have linked (which is static linking) and for some VERY odd reason I am still getting the error (even though I know this enabled the program to run on colleagues computers when they were getting the same error).
Is there anything more I can do that will make the program (for lack of better terms) fully portable? Any more settings I need to change in VS such that it will fully compile the libraries into the executable?
I am going to further stress the fact I have seen the solution to use static linking using the /MT option for compilation and I am still getting missing .dll problems.
I tried copying MSVCP140.dll next to my executable and it did solve the issue, but there is another missing .dll and I cannot incrementally add .dlls until the program starts working. I am happy to bundle all the .dlls with the program if that is the only solution but I would like to know which ones are needed so I don't have to copy my entire system32 folder out of desperation.
Have a go at using dependency walker to figure out what dlls you need, and why you need them. This can be enlightening, and lead to a path of cutting out many dependencies by using alternatives. If you are sure you aren't importing certain functions at consumer runtime (e.g. you are only importing them for debug purposes), then you can choose to delay load them.
I'm working on a pretty tricky problem that I've been on for literally a week now. I've hit a very hard wall and my forehead hurts from banging it so I'm hoping someone can help me out.
I am using Visual Studio 2005 for this project - I have 2008 installed but was running into similar issues when I tried it.
We have an application currently working compiled against OpenCv1.1 and I'm trying to update it to 2.2. When we switch over statically link to the new libs, the application crashes - but only in release mode. So dynamic linking and debug both work fine.
The crash is in std::vector when calling push_back.
I then came up with a sample test application which runs some basic code in opencv which works fine and then took that exact same code and added it to our application. That code fails.
I then gutted the application so it didn't instantiate any code objects except the main gui and 1 class which called that code and it still crashed. However, if I ran that code directly in the main gui, it worked fine.
I then started commenting out huge amounts of the application (in components that should never be instantiated) and eventually I worked my way down down down until...
I have a class that has a method
void Foo()
{
std::vector<int> blah;
blah.begin();
}
If this method is defined in the header, the test code works, but if this code is defined in the cpp file, it crashes. Also, if I use std::vector<double> instead of int, it also works.
I then tried to play with the compiler options and if I have optimizations turned off (/Od) and Inline Function Expansion set to Only __inline (/Ob1) it works even with the code being in the cpp file.
Of course, if we go back to the ungutted application and change those compiler options by themselves, it crashes.
If anyone has any insights on this, please let me know.
Thanks,
Liron
ARGH! Solution figured out.
In our solution we had defined _SECURE_SCL = 0, but in the 3rd party libs we had build, that was undefined (which means = 1). Setting _SECURE_SCL to 0 supposedly reduces runtimes drastically, but it has to be done the same across all included libs otherwise they will treat array sizes differently.
http://msdn.microsoft.com/en-us/library/aa985896%28v=vs.80%29.aspx
That was a fun week.
The STL classes, like vector<>, have a layout mismatch between the release and the debug builds, caused by iterator debugging support. Your problem behaves exactly like the kind of trouble you get into when you link a debug build of a .lib or DLL in the release build of your application and exchange an STL object between them. Heap corruption and access violation exceptions are the result.
Triple check your build settings and ensure that you only ever link the release build of the .libs in your Release build and the debug build of the .libs in your Debug build.
could you try:
void Foo()
{
std::vector<int> blah;
blah.reserve(5);
blah.begin();
}
I am using VS 2008 and get compiler errors sporadically when adding a dll reference to a managed c++ file in my C++ project. I am trying to add a reference to the dll so as to be able to use smart pointers.
ex: #import items.tlb
The problem is that the compiler crashes at sporadic places inside of items.tlh almost as though chunks of bytes where erased of missings , but when i open the file i can't find any reference to the aforementioned errors.
I tried to rebuild the whole project several times, tried on different machine, but although the compiler errors are not consistents and disappear alltogether sometimes , a fresh rebuild sometimes brings back the problem. I was told that the size of the generated .tlh file may be a reason but it doesn't really solve my problem or point me in the right direction.
Did anybody experienced the same symptoms?
Thank you
Whenever I've had this problem, it was caused by linking a Debug build to a Release DLL or a Release build to a Debug DLL.