I'm creating Win32 application and I have two projects.
The first one is a static library which contains _tWinMain() function, that is the entry point of a Win32 application.
The other one is an application which links this .lib. That way, the app doesn't have to create its own _tWinMain() function, because it's in the .lib file.
First, I build the static library. Then I build the application. The problem is that when I start debugging (F5), the window shows and then immediately closes (either in Debug or Release configuration). The problem doesn't occur when I start the program without debugging (Ctrl+F5) or just open the .exe file.
Is it possible to debug while having the entry point in a static library?
I think it should be possible. Did you try what happens when you start the application with F11 or F10 instead of F5? It will then start the application, but breaks directly at WinMain.
SOLVED:
I had a small bug in one of my functions (always remember to initialize variables ;) ). _tWinMain() quited because of that. Now everything works fine, with the entry point in static library as described above. Thanks everyone for help and sorry for bothering you :)
Related
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.
The question may apply to any programming language written in Visual Studio, but I am more concerned about C++.
Is there a way to easily determine the application entry point in Visual Studio?
For a relatively small application this could be easy, but for large ones, it will be pretty hard. In my particular case I know that the project which is set as startup is the one which has the entry point, but I was unable to find it, even though the application starts and runs well.
If you want to find what C++ project is executable than search for <ConfigurationType>Application</ConfigurationType> in all your *.vcxproj files.
If you are looking for the entry point function inside this application, than search for main, wmain or WinMain functions.
Also entry point can be redefined with /ENTRY parameter, so you can check Configuration Properties > Linker > Advanced > Entry Point project parameter or search for /ENTRY in your *.vcxproj.
In C++, a fully compiled program can have only one defined main method. If there's more than one, the compiler will complain about "multiple definitions of main" or some other similarly worded message.
So, the simplest option is to do a search for the symbol main (or, if compiling as a Windows Subsystem program, WinMain) and figure out which ones correspond to the "startup" project. There shouldn't be that many, even in a relatively large solution.
When desiring to stop execution at the top of the main/WinMain function while interactively debugging a process on Windows, I typically just use F10/F11 (assuming default C/C++ key bindings in the Visual Studio IDE) to instruct the debugger to single-step (which starts the process, then performs the step, then breaks).
Note this may not always do what you want. If you want to catch global initializations, object constructions, etc, these are already done before reaching main or WinMain. Those require additional debugging and setting breakpoints in CRT-source code for the real global startup code (which eventually calls your main or WinMain). But if you simply want to break-on-main-entry for a program built with debugging symbols, this is likely the easiest way to do it.
Got a big MFC C++ project. Our VS version is 2008. It loads a regular dll (for some optional functionality) and calls exported functions from it. When debug through the MFC app and get to the point where we call the exported function you can't step into the dll function. Is there a way to get debugging inside the dll functions. Even if I've got the dll project included in the C++ solution, it doesn't seem to "see" the dll code.
Edit: We've got a number of extension dlls and debugging into them works just fine. This is a straight dll, no mfc, /clr option set so we can call into some managed code. The class that consumes this dll, loads it, then uses GetProcAddress to find pointers to the exported functions. Here are examples.
typedef void (*FP_OnEditOptions) ();
to prototype the function.
then
m_fpOnEditOptions = (FP_OnEditOptions) GetProcAddress(hInstance, "Direct_Edit_Options");
to get the proc pointer, then
static void OnEditOptions()
{(*m_fpOnEditOptions)();}
to call it.
When debugging, get to the call to it, hit F11, and it calls it, but doesn't step in.
Yes, the dll has debug option, and when the module is loaded, the symbols are loaded from the appropriate pdb file.
Thx,
Andy
Debug + Windows + Modules. Locate the DLL in the list and right-click it. Symbol Load Information tells you where the debugger looked for the .pdb file. Make sure you get it there.
After update: it is very likely that with /clr enabled that you are actually running code that was compiled to IL and just-in-time compiled. Just like managed code. You'll need to switch the debugger to Mixed mode debugging. Project + Properties, Debugging, Debugger Type = Mixed.
Look under Tools->Options->Debugging->General
There are a couple of options which may help - I'm not sure which one exactly you'll need. The 2 obvious ones are:
Disable "Just My Code"
Disable "Step over properties and operators"
You might also try putting a breakpoint inside the function that's being jumped over. That should force the debugger to stop at that code.
This is kind of a stupid question I guess, but I have a library which is included and used in a project, compiled as a .dll. Everything compiles fine. When I reach a function in this library, I get System.AccessViolationException and I cannot enter into it while debugging because it says the symbols are not loaded.
I have looked in the modules window, and I cannot find my .dll
Why?
Thanks.
This may be a managed/unmanaged debugging issue. You won't see unmanaged DLL's if you are doing managed debugging, and vice-versa. The "automatic" option where VS tries to guess what kind of debugging you want doesn't always work.
Try attaching to the process after it is loaded and then specify both managed and unmanaged debugging in the dialog that pops up when you choose the Debug->Attach To Process menu option.
I understand that is not possible to have applications with multiple entry points under Windows.
I have a MFC application and I added code for making it running as a service (main() entry point and other required stuff) but it looks that Windows will always run the WinMain() from MFC instead of my main.
The question is how can I disable the WinMain() from MFC in order to be able to run my own main().
Probably the same problem would apply if you want to run the same application as a console application.
What do I have to change in project properties in order to build it as a console application (main instead of WinMain)?
Is commenting my CWinApp the only solution?
If you look at the linker settings you can change the entry point. This is where you want to be looking.