I have an executable that is built with MSBuild and CMake, because I want to stay out of Visual Studio unless I am debugging. I have a callback in which I can't tell if it is working correctly or not, so I want to debug it. The problem is if you open an exe with devenv, it just appears to open the entry point of the application, it doesn't actually load the source code that would let me set a breakpoint on the callback, and since it is a callback, all my applications main function does is register the callback, so I have no way of breaking on an event with the callback I want to debug.
I know I could do hacky things like put the callback code in main.cpp and set the breakpoint there, or I could just debug the solution that CMake generates, but what I want to know is if there is a way to just simply debug the application to where I can open all source files associated with the executable without opening the solution, just the executable? The reason I want to do it this way is mainly for speed, a dummy solution runs significantly quicker on my machine than a full on solution, and it allows me to work in a text editor that is much faster than Visual Studio.
The WinDbg tool is that path I could know if you don't use the VS IDE as the debugging tool, it can help you to debug/load source code or others.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff556911(v=vs.85).aspx
Related
I'm currently working on a large project with a lot of potential bugs and glitches. I enlisted a few of my friends to help me test the program to find potential bugs but a lot of them aren't very tech savvy and have no idea how visual studio works.
Is there a way I can compile my project so it could run as a stand alone executable? I tried building it and getting the vcxproj file but I still have no idea how to make that a click to run type of program. Any help?
As far as I'm concerned, there is no way to "publish" C++ code.
I suggest you could refer to the link: https://social.msdn.microsoft.com/Forums/en-US/6998eadb-36fb-4a97-bba5-0de49d533732/how-can-i-publish-a-visual-c-project-?forum=vsclassdesigner
If you want to make a stand alone .exe file. I suggest you could try to use "Release" to build a stand alone .exe file. Check the .exe program Configuration Manager, ensure your set Release for your .exe program. (open your .exe program under Solution Explorer, right-click solution and select Configuration Manager).
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.).
We have matlab .m files which have been compiled to a DLL using mcc. This is used by a C++ GUI application which we debug in Visual Studio. When we reach the call to our matlab function, all we can do is step over it. How can we debug, at a source code level, the .m code?
I figured it would be easy to add some 'print' statements, which in matlab are actually called 'disp', and watch stuff scroll by in VS's output window. But we see nothing. Not even from printf() in the C++ source, or when running our app directly from a command line instead of in VS. From Google and S.O., we learn that nothing sent to stdout ever shows up anywhere. (This question is relevant: Visual Studio 2012 C++ Standard Output but didn't work for us.)
I tried msgbox('blah blah') in the .m scripts, and rebuilt the DLL. Nothing came up. I'm not sure if this should work but our matlab code didn't execute, or if msgbox isn't expected to work in this situation, like stdout.
We'd be happy with print-based debugging. Breakpoints and other techniques would be nice, but not necessary at this time.
We use Matlab R2016b on Win7, Visual Studio 2015. We have the .m source used to make the DLL, and we have the source for the GUI app using the DLL.
Several items:
When you call the initialization routine of your dll, call the
generated 'WithHandlers' version: YourDllInitWithHandlers( **,
**). The '**' are placeholders for functions accepting the matlab disp/warn/error messages, that you can route to stdout,
OutputDebugString or log as you wish.
Did you possibly initialize the mcr from your code with the -nojvm option? If so, messageboxes won't be displayed.
You can't step into the .m sources of compiled libraries. Two options we use are: (a) save the inputs to your compiled-m code as mat files, then load and debug at your leisure at Matlab. (b) Toggle between calling into a compiled-dll and calling into Matlab-Engine. This API-set allows you to launch, control, and call into a fully interactive matlab desktop. You could set breakpoints and step as you would in a regular matlab session. This requires some more setup code, but is very convenient for debugging.
I'm having a weird problem with Visual Studio. Whenever I change my code and build, even though I get the notification that the built was successful (and if any, it also shows errors in code and doesn't build) the executable is actually the previous build. This is getting really annoying and frustrating.
If I put a breakpoint on the new lines, the breakpoint gets disabled and it says
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: preprocessor
directive or compiler/linker optimization
If I put a breakpoint on old lines of code, it stops processing but shows me this message
The source is different from when the module was built. Would you like
the debugger to use it anyway?
I never had this problem before and the source code in on my laptop's hard drive. It saves right away. The only way to get around this to Clean the entire solution manually every time, instead of basically pressing F5.
Thanks everyone for their suggestions. My mistake was that I defined the classes inside .cpp files, this somehow caused the linker to do weird (caching probably) stuff and link the old objects. I renamed the file to .h and everything's working as expected.
Perhaps your code is not built, or is built in a way you don't expect.
You might check by inserting a #error foobar preprocessor directive somewhere. If no error shows when building, you know you are in trouble!
But I never used Visual Studio (I'm only using Linux) so I cannot help more.
It might be that you have set main project some other project and building that.
make your project that you want to work on as "Main Project " by set main project available in menu bar.
I think you are using source files from another project (ex: if you are using a dll say, my.dll (which was built using some source files say, mycpp.cpp ); in your current project).
When you debugged into the file (mycpp.cpp), maybe you modified it.
Hence you need to rebuild the dll (my.dll) first in the project in which you created my.dll .
Or
Maybe you have opened a instance of mycpp.cpp in a window & debugging in another window.
you should rebuild the dll.
If you are not using files from another project, then I cant guess the cause...but still I would recommend using rebuild rather than clean & build.
please clarify your Question a bit.
#David expecting a reply from you...
I was looking for an answer to this issue since I was also stuck with it. A colleague of mine just gave me a solution that works. Yes, it seems really stupid, but it did the trick for me.
Our solution has many projects. He told me to select the project that I wish to break into and set it as the startup project (right-click on the project name and pick "Set as startup project"). I was desperate, so I tried. To my amazement, it works.
Since I have this window opened, I thought I'd share it in case someone else is stuck with the problem.
I faced the same problem. But reason was not as yours.
Then I just restarted the visual studio and it ran as expected.
I have a program that runs fantastically when run from inside Visual Studio 2010 Express but when built and taken out, it has problems. I have set up the external test environment the same as when it is run from within Visual Studio so that shouldn't be the problem. I want to attach it to the .exe to see where the crash is but I don't have the non-Express versions.
Any suggestions? Why would a program crash outside of the the VSC++ 2010 Express environment but run perfectly inside.
I would post code but it's a huge project, not a line that would cause an error.
Thank you so much for your time.
It's very difficult to know for certain without knowing what the crash is, but a couple of common issues that may cause this:
Environment variables not the same. Perhaps you are relying on something in vcvars32.bat in your test environment.
The PATH environment variable is not the same and your picking up some bad or incompatible DLL.
Your code is somehow dependant on the current working directory being the one when run from Visual Studio.
Wikipedia to the rescue?
Time can also be a factor in heisenbugs. Executing a program under control of a debugger can change the execution timing of the program as compared to normal execution. Time-sensitive bugs such as race conditions may not reproduce when the program is slowed down by single-stepping source lines in the debugger. This is particularly true when the behavior involves interaction with an entity not under the control of a debugger, such as when debugging network packet processing between two machines and only one is under debugger control.
Also, note that User32.dll slightly changes its behavior when under a debugger, in order to make debugging easier for you. That shouldn't change anything, though.
You could debug this using the freely available Debugger Tools for Windows. There's plenty of documentation and quick start guides available, especially the chm included in the install. In your case, you may want to try the following:
Make sure you have the PDBs for your app available somewhere on a share.
Attach to the running instance of the app: windbg -p <PID>. Note that you can also start the program under the context of the debugger by doing windbg -g foo.exe.
Repro the crash.
Change the symbol path to your symbols and the Microsoft public symbol server to get proper symbols for components: .sympath x:\YourPathToPDBs; SRV*x:\symbols*http://msdl.microsoft.com/download/symbols
Tell the debugger to reload symbols using your path: .reload
Get a callstack by hitting k in the debugger.
That's the barebones you need to figure out where it's crashing. You can then go deeper and try to analyze exactly why it's crashing by looking at the debugger chm or other resources on MSDN or Tess's blog. One useful command is dv to dump local variables for a particular frame. If the callstack doesn't give line numbers, type .lines and then hit k or kb.
You could surround all code in your Main function with a try catch block. When you catch an excepcion, write to a log file the stack trace.
Then run your exe and check the log file to know where your program is crashing.
PS: Don't forget to place the *.pdb file together with the exe file, otherwise you won't be able to get the stacktrace information.
I realise this question is a couple of years old, but I have been experiencing the same thing and came upon a possible culprit (the actual culprit in my case), which may help others who have this issue.
One important difference when running an application within Visual Studio and running it outside is the Current Working Directory ("CWD").
A typical directory structure for a Visual C++ Solution/Project is along these lines:
Solution <- the location of your solution file
Debug <- where the Debug executables end up
Release <- where the Release executables end up
Project <- the location of your project file
Debug <- where Debug intermediate files end up
Release <- where Release intermediate files end up
When you execute the application from within Studio, either with "Start Debugging" or "Start Without Debugging", the default CWD is the Project directory, so in this case Solution\Project.
However, when you execute outside by simply double-clicking the application, the CWD is the application directory (Solution\Debug for example).
If you are attempting to open a file from the current directory (which is what happens when you do std::ifstream ifstr("myfile.txt")), whether it succeeds depends on where you were when you started the application.