I'm getting ready to enter Ludum Dare this evening, and I'm getting really frustrated because I'm unable to build my project into a standalone .exe.
I feel like this question has been asked at least 100 times but none of the answers I'm finding are helping me out at all... I don't really understand what static linking is or how to do it, and that doesn't even seem like the solution to my problem; I don't mind if I'm shipping out a bunch of .dll files with my program, I just want the program to run on its own so I can submit it at the end of the competition.
Basically, my visual studio (2010 express) configuration follows exactly LazyFoo's tutorial on setting it up. Everything runs fine on both debug and release configurations when I start the program from visual studio, but when I navigate into the Debug or Release folders of the project and try to run the .exe, the programs break with an error about abort() being called, or they give me the error "X program has stopped working."
I'm including all of my DLLs in the same folder as the executables are being placed, and the game runs perfectly fine from inside VS, but I just can't seem how to figure out how to compile it as a standalone .exe (or even including a folder full of dlls) without it falling apart.
Can someone give me a pretty precise way to get this working? Any help would be great.
If you have an EXE, then your program is compiling. Most likely in debug mode, the program is running using a specific directory as the current working directory (CWD), but when you run it as standalone, the CWD is different.
The CWD affects both the DLL that can be loaded as well as the search of any file that uses a relative path (that is, not starting with a [back]slash). That is probably your problem: textures, graphics, configuration files, fonts...
My advise is to set the CWD in the debugging runs (there is an option for that) to be exactly the same than that of the EXE, that is the default when you run the EXE. Then you will be able to debug your crash.
Related
Basically, I have a Visual Studio project that builds a DLL (a VST audio plugin). Where this type of project scenario has been set up for me in the past, I would be able to build, run, and debug the plugin. Visual studio would automatically launch whichever program I was using to host the plugin. I am trying to achieve the same effect in my current project, but I don't know how to set that up. Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". The DLL still builds, and I can still run it, but I can't debug it from Visual Studio, because I don't know what I need to do in my project settings to make this happen. How can I do this?
MORE INFO:
What I do know is that, in projects where this sucessfully works, there are some modifications made to the Visual Studio project settings under fields marked 'pre-build events' and 'post-build events', so presumably what I want to do is edit these in some way to tell Visual Studio the following: "Hey, before you try and run and debug this DLL, you have to launch another program (my program is called Max.exe), and then you have to wait until that program loads the DLL. Then you can debug! Don't be a stupid computer and try to debug it before it's even loaded in Max.exe..."
What I do not know : EVERYTHING ELSE. This is literally all I know about what I'm trying to do, hense the colourful attempt to talk to a computer in English.
Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". This is unsurprising seeing as the project knows nothing about the environment I want to use to test the DLL, but the problem is that I don't have a clue what Visual Studio needs to know. I really don't know enough about programming to understand the implications of what I'm trying to do either. Yes, I did mention those fields marked pre-build and post-build because I remember them being important, but I don't know exactly what or how to write in those fields, and I also do not know if there will be more things I need to tell Visual Studio before this will work.
Q.E.D I'm not actually sure what pre and post build events are, or how they work. And I barely know the first thing about customizing VS project settings. All I know is how to write audio processing code. I felt the need for this disclaimer because typically my questions are met with angry programmers who think I don't do my own research; they fail to realize I am an audio engineer who skipped programming 101. Yes, how to debug a dll is a common question I'm sure, but answers to those questions tend to assume pre-requisite knowledge that I do not have.
You will want to edit the Command field in your project's Debugging properties. Right-click on your project in the solution explorer and click Properties (it's generally the last item). Open the Debugging page under Configuration Properties. The Command field indicates which executable to launch when debugging.
By default this contains $(TargetPath) which refers to the final binary your project compiles. This is useless for DLLs since DLLs are not executable. Change this to the path of whatever third party application you are writing a plugin for.
With this change, launching with debugging will actually launch the third party application and attach the debugger to it. Once the application loads your plugin, you will be able to debug it normally.
For Visual Studio,
In Solution Explorer, right click on project and select Properties.
In Properties, choose Configuration Properties -> Debugging.
For Command, enter the full path of the executable that will be loading your DLL. Fill in the Command Arguments and Working Directory accordingly.
In addition, you need to make sure that the executable actually loads the DLL you are building. A mistake that a lot make is to launch their executable, and not realize the executable is loading another version of the DLL they are trying to debug. This can happen due to Windows searching for the first DLL that it finds using the DLL searching logic (exe directory, path, etc.).
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.
I'm a developer of Windows desktop software, and from time to time our app crashes. In rare cases I'd like to get a customer to run a debug version of the app to send me a stack trace so I know where it crashed. I followed the instructions in here:
Windows C++ stack trace from a running app
...but while it works on my development machine, it doesn't work on any client machine or those of my colleagues, who don't have Visual Studio installed. So I presume that there's some .dll or something they need before it'll work. They're using the same .exe I'm using, i.e. the one I compiled in VC++ in debug mode.
After some painstaking "message window" debugging, I learnt it's failing in SymGetSymFromAddr64() - this returns FALSE. But when I walk the stack, this always returns FALSE or it returns garbage that doesn't make sense (random unrelated method names), as if it's the PC values which are invalid, not the mapping process. To reiterate, it's a debug mode .exe that produces a perfect symbolic stack trace on my development machine.
I did some research and found some mentions of "dbghelp.dll" and "imagehlp.dll" but I just ended up confused. "dbghelp.dll" ships with all versions of Windows, but with reduced functionality. There's some other things I could install, but it's a little scary to be installing some Windows "WDK" or "debug kits" which might overwrite important system .dll's or do god-knows-what to your computer.
So what I need to know is: "what's the simplest set of instructions I can give to these helper customers e.g. the minimum set of .dll's and where to stick them so that we can get proper symbolic information out of the stack traces when our program crashes?"
The most likely reason for failing to find the symbols is that the .pdb file cannot be found. Even if you generate a .exe in debug mode, the symbols are not in the .exe, they are in the .pdb file. Through a lot of empirical testing, it seems that the process has the pathname of the .pdb hardcoded in it, so if your clients don't have that file at that location, they won't necessarily find it. However, you can supply a "search path" to the SymInitialize() function - a folder or set of folders to use to search for the .pdb file.
In my configuration, I had an exe called "Edval.exe" and a .pdb called "DebugEdval.pdb". The process searches for "DebugEdval.pdb" in the search folders. This corresponds to what you've configured in "Properties > Linker > Debugging > Generate Program Database File".
I've been running and compiling a program on my Windows 7 64-bit machine for several months now, but recently I had to change several VC project settings of the static libs that it uses and now the generated executable file requires me to run it in "Windows XP Compatibility Mode".
Compiled on Windows7 64-bit machine with Visual Studio 2010 SP1
The program I am generating is being built in Win32, debug mode.
The static lib projects specify Target Machine /X86.
When I run the program from the debugger, it start up and runs, however if running via the windows icon, it requires XP compatibility mode.
When trying to start outside of the debugger the EXE shows up in task manager for a second then goes away.
I've tried using Microsoft Application Verifier on it, however I don't know what to look for in the output.
I've been unable to find any details on how to troubleshoot this issue so if anyone has any ways if finding what could be causing this recent Compatibility Mode requirement I'd love to hear how it was fixed.
I have the source/projects/solutions for the majority of the static libs that I link against, as well as the exe file generated, however some of the external dependencies I only have the .lib,.dll, and .h files for. This means I can change (most) of the project settings for the dependencies if neccessary, but I need to know which ones to look for.
Thanks
To be honest, don't be afraid to make another project and copy the code files, even if it's 5 projects. You need to cut the problem in half. If it works with the new projects then it's the project files, if not, it's the code. Making projects isn't that hard really, though I'm sure a source of much consternation and something people avoid. If its the projects you can diff the files and see what happened by process of elimination. If you are really worried, copy the entire solution to another folder; always make backups.
The problem is that you probably won't be able to hoist enough information up to us to get a meaningful answer unless get lucky, and all the answers will be shots in the dark.
So I'm goign to take this question as "this happens, what can I do about it". The strategy above will get you out of it, if this used to work before. This exercise will arm you for the future and will be more productive in the long term. Go look at UAC and manifest files, aka Vista+ difference tht dramatically changes load and run behaviour (Linker Commands, Vista Migration Guide) if you need one thing to look at, but try the above process.
----
Other generic things to try:
1) another machine
2) another install of VS
3) a simple project with one window that does nothing to prove everything else in your tool chain and environment is ok.
4) planting message boxes along the code path with different messages so you know where its crapping out.
5) turing on pdb in release and runnign outside of debugger. If craps out, then try debugging and see if still craps out, but you get to see where.
6) assume that your code is unstable and you were getting lucky when it used to work. (this one is no fun). Many times things work in debug and not in release due to mem layout being different. If your progam is large you can find creative ways to use #if's whatever to elimitate code from running while haivng the whole thing still load. You can find the code that causes the bad behaviour.
7) turn off UAC and error reporting if its on, see if changes.
8) go find the "run without debugging" menu button in Visual Studio, so you don't have to go run it with the icon. That's an accident waiting to happen, and eliminates one more environmental difference. It looks like the run with debugging button, but it's hollow, a plain green triangle. It's under debug menu set. My oppinion is that it has done more harm than good to not have that on the bar by default as its confused many many people to think launching wiht VS means always using the debugger.
and so on....
I am an experienced Visual Studio developer who has recently taken on an OSX 10.6 project (a C++ server project with no UI).
I have been successfully debugging the application using the XCode debugger (setting breakpoints, etc.) for months, including debugging the source code for various static libraries that are linked into the final executable program.
However, tonight I was required to debug (with breakpoints) a DYLIB that is also built from our source code, but that is linked dynamically at runtime with the application (the name of the DYLIB is read from an .ini file by the main application).
Unfortunately, the usual method I use of debugging the application (right-clicking the custom executable and selecting "Debug with Breakpoints"), though it does successfully run the debugger and allow me to debug the application (along with its statically linked libraries), exhibits the following undesired behavior when I attempt to hit a breakpoint in the source code for the DYLIB:
-> The XCode debugger reports that the breakpoint was hit in the sense that I see the function and line number in the status bar at the bottom of the XCode windows (along with an indication that this is a gdb message), and the application halts execution. However, there is no stack trace, no variables, nothing - just a completely empty debugger window. The buttons to to "step over", "step into", etc, are disabled. No editor window appears in the debugger (and hence no visual indication that the debugger has stopped on the line indicated). Opening the file by hand does not reveal the debugger hitting the line.
Unfortunately, this is useless for me as far as my attempts to debug the DYLIB.
I have hunted far and wide tonight researching and attempting to find a way for the XCode debugger to successfully hit breakpoints in a meaningful way in the source code for this dynamically linked DYLIB. I have of course done a number of clean/rebuilds. I have made certain that "load symbols lazily" is unchecked and then cleaned/rebuilt. I have restarted, and I have also deleted the "build" directory and rebuilt. I also deleted the user-specific files in the .xcodeproj package. (Note also that I am of course building and running all code, including the DYLIB code, in Development mode with all optimizations off, and generating debug symbols for all.) However, my attempts have been unsuccessful. Nor can I find so much as a single mention of this problem on internet forums.
Any help in instructing me how to use XCode to successfully debug a DYLIB that is linked to my application would be appreciated.
Thanks,
Dan.
Update -
This problem is resolved. It was my lack of experience with OSX that caused me to fail to see this. Despite the fact that my DYLIB project was part of the same XCode project as the executable that calls it, and despite the fact that the DYLIB was built in the same directory as the executable, at runtime the debugged application was not accessing the DYLIB from this location. Instead, it was accessing it from a (different) install location. I have not as of this moment tracked down where the install location is "cooked" into the application, but by copying the final executable/DYLIB into the expected install location and creating a new custom executable that points to the executable in this location, debugging of both the DYLIB and the executable works.
Thanks,
Dan.