I have a program (32-bit .exe written in C++) that runs fine in the Debug directory of my project development tree but when I move it to another folder on my PC it crashes. I want to run it in the debugger from the new location to debug it. How do I start my .exe in the debugger at some arbitrary location on my PC?
I'm running Visual Studio 2013.
I want to set a breakpoint at the first executable line and step from there, just like I would if it was in the normal Debug path.
You could always add this somewhere in your app, which will open a prompt to attach a debugger when the app is run.
#if DEBUG
if (!System.Diagnostics.Debugger.IsAttached)
Debugger.Launch();
Debugger.Break();
#endif
In Visual Studio 2013, go to project properties, select the Debug configuration and go to Debugging. Enter the command, command line arguments and working directory.
Here's a screenshot of how it looks like:
Be sure to not move the PDBs. The EXE contains a reference to the PDBs and if the PDBs are not in the original place, Visual Studio cannot find them.
If you have already moved the PDBs, set up the symbol path accordingly in Tools | Options | Debugging.
The dialog looks like this:
Related
We have a legacy Visual Studio 2003.NET C++ DLL project. Still works with VS2003 on Windows 10 but we're looking to migrate to VS2019.
In VS2003 when you debug (F5), the box Executable for Debugging Session pops up. In the Executable file name box you select Browse... and navigate to the .EXE which will consume your DLL. Great!
But how to do the same in VS2019? Whenever I debug, Visual Studio thinks I'm using the Local Windows Debugger and I get the error "[PATH][PROJECT].dll is not a valid Win32 application". The Debug > Attach to Process... option is not right either because my target executable is not running yet.
If I'm understanding the problem correctly, I think you want to select the Debugging section of your DLL project's property pages. There you can choose which debugger to use and you can even set the executable you want to launch.
I'm attempting to run a program built with a CMake-generated solution file under Visual Studio 2017's debugger in order to debug a problem. However, whenever I try selecting Start Debugging or Start Without Debugging I get the following error popup.
Unable to start program
'E:\build\someprogram\build\x64\Debug\ALL_BUILD
Access is denied.
At first glance the problem sounded like the one described here. However, that bug was allegedly fixed in VS 2017 15.5, and I currently use 15.6.7. And the location of the compiled executable isn't on a RAM disk or network drive, but on a physical drive. And the error happens when running without a debugger also.
Also I wondered about whether or not the executable was not properly configured, since it looks like the error is related to the ALL_BUILD target, but in my CMakeLists.txt I have this declaration:
add_executable(someproject ${SOURCE_FILES})
I would think that would add the executable to run. It also appears as a subproject in the Solution Explorer.
The compiled .exe runs outside of Visual Studio fine, although it crashes, which I'm trying to debug. Strangely, I cannot enter the Visual Studio debugger from the Abort/Retry/Ignore dialogue that appears after the crash by clicking Retry like it instructs; the window for choosing the Visual Studio version never appears.
It does not seem to be a permissions issue since I manually adjusted the permission of all the build directories with all permissions, with no changes. I'm also running Visual Studio with administrator privileges, and it makes no difference. Additionally I replicated the build process on an entirely different machine (Windows 10, as opposed to Windows 7) and the exact same error occurs, so I'm suspecting it's a CMake issue.
You need to set a different project as startup project (right click on your target executable project "someproject" and select "Set as StartUp Project" from the context menu). ALL_BUILD is a symbolic target and is not connected to an executable.
I am using Visual Studio 2013. I use a single start up project. There are more than 8 projects in the solution. Here is what I used to do when I was on Visual Studio 2010;
I would Build the solution. Then run it from its .exe file in /bin/Debug, then on Visual Studio, I would Attach to Process and it would start debugging and it would always hit the breakpoints as long as the source code and the .exe are not different.
This is the same thing that I do on Visual Studio 2013. I put the breakpoints in a file in my startup project. I build the solution (it says it successfully builded on the output window), or I Start Without Debugging, then attach to process, it says "The breakpoint will not currently be hit. The source code is different from the original version" Then I stop debugging, and without building again, I run the .exe again, attach it, then the breakpoints start hitting. Why do I have to close my .exe and then start it again? I use attach to process a lot and this 'must do twice to hit' is really annoying. I haven't change any configuration or anything. What am I doing wrong? I swear I don't change the source code. Not even a single space. It says "Build succeeded" when I attach it.
I have a similar issue. (on a webproject)
my temp solution:
right click the web project
Select Property Pages
Under Build --> Change the Target Framework to something else than the one selected (Apply the new framework)
Then Change back to your desired framework and Debug
Want to debug an executable under debugger. How to do it in visual studio.
Windbg has an option of open executable. But I find this is missing in VS 2010.
The question is not exactly same as
Debug exe in visual studio 2010
as I am not really interested in image file execution to debug a start up.
Rather want to just debug the exe under debugger, once it is broken, want to
set some break points and understand the flow of execution.
Albeit image file execution is a workaround for this.
I am not sure if this question is naive; But this is a very straight line use case scenario, I find missing in MS VS 2010.
You did not specify it in the question, but I assume you do not have the source code. Just use File/Open Project/Solution, select EXE file and Open it. Then select Debug/Start debugging. The other option is to run the EXE first and then Select Debug/Attach to process.
If what your asking is how do you attach VS to the exe you want to run then you can follow these steps:
Run the executable
In VS navigate to Debug -> Attached to Process
Find your process created by running your executable and click "attach".
However, if the executable you are trying to run fails almost immediately or runs quickly and exits then you could try the following steps:
Set a debug point at the start of the code
Switch your build to Debug and run the application.
If your application is running in Debug, but failing when you execute the exe then you could try these steps to see if the your app will give more information in a console window or other.
Make sure your build is set to Release.
Navigate to Debug -> Start Without Debugging
If you have the source code, you can use Debugger.Launch();
You put it anywhere in your code, build the .exe and then once it gets launched (by Process.Start for example) and reaches Debugger.Launch();, a window will be asking you how you want to attach to the process.
Typically, you'll attach to some Visual Studio instance and it'll automatically pause the debugger where Debugger.Launch(); has been placed.
You can then open the project's files (File -> Open -> File...) and place breakpoints wherever you want.
I have created a minidump using win32 api
[DllImport("DbgHelp.dll", SetLastError = true)]
private static extern bool MiniDumpWriteDump(
dmp file is successfully created.
i am trying to open this *.dmp file in another visual studio instance to locate the place of the crash,
in visual studio --> FILE--> open project the dmp file option is not available.
i had choose all files in file open menu, and opened the dmp file. but i can't debug,
any idea why my dump file option in visual studio is disabled.
i know i can use windbg, and other tools, it will be easy for me to use visual studio as it is available for me.
I'm not 100% sure. But, I think even if you get it open in VisualStudio, VS doesn't support half the commands that WinDbg does for analysing a dmp. So, I'd just stick to WinDbg. WinDbg is a free download... so that's available to you too. It's not the easiest to use, I always have to open the help to find the commands I want, but it does do a good job.
Download here for 32bit:
http://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx
It sounds like you are opening the dump correctly.
Here is what is says in the Visual Studio Help files:
"To open a dump file
On the File menu, click Open, and then click Project.
In the Open Project dialog box, locate and select the dump file.
It will usually have a .dmp extension.
Click OK.
To find the binaries for debugging a crash dump, Visual Studio 2005 looks in the symbol search paths. To make sure Visual Studio 2005 finds the binaries, you can add a symbol search path in the Options dialog box or from the Modules window. For more information, see How to: Specify a Symbol Path."
You yourself say,
"...and opened the dmp file. but i can't debug"
So you are opening the dump file OK in Visual Studio, but what do you mean, "I can't debug?"
If you can't see your source code, that's because Visual Studio doesn't know where it is. Follow the instructions to set up the symbol search path.
If you can't step thru your code, that's because you can't do that with a minidump. The process that produced the minidump is gone, and it can't be executed further.
If you can't examine the call stack or contents of variables, that's because Visual Studio can't find the .pdb file with the debug info.