How to debug an exe with multiple dlls using breakpoints - c#

I have a myapp.exe that after some complicated logic is run by another program. I wanted to debug the issues with myapp.exe just like visual studio preferably using breakpoints. What is the way to achieve this? The exe is a console application and is run on the spot. It's not a running process so I cant attach a debugger.
The expected behavior I would want is:
Do magic and set breakpoints for that exe and dlls
Call the exe from the other program
Visual studio hits the breakpoint and I can debug what is going on

Just use System.Diagnostics.Debugger.Launch() where you want to attach the debugger. You can place it just before your desired breakpoint location. Windows will ask you what debugger do you want to attach.
Another way is to check the System.Diagnostics.Debugger.IsAttached property and wait for the debugger like this (polling):
while (!Debugger.IsAttached)
{
Thread.Sleep(500);
}
The application will loop until you attach the debugger (in visual studio via attach to process command, Ctrl+alt+P ).
Again, just place a break point after or even in the loop and you're done.
This is a well know way used to debug a windows service application and can be useful also for your intent.

Related

Attach VS debugger to executable file instead of running instance

I'm trying to attach the VS debugger to one of my own applications that is running from its installation directory in Release configuration.
When the app runs, it immediately shows a MessageBox saying that the app was launched with invalid command line arguments. These arguments have been passed to the app by the shell when an associated file (*.MyAppFileExtension) is double clicked.
The installer configures the shell to send these command lines.
Now something has gone wrong and I cannot seem to set a breakpoint after attaching the VS debugger to an instance of my app. It allows setting a breakpoint at the call to MessageBox.Show but by the time I attach, the call has already been executed. No breakpoints are settable after this point.
The error says the breakpoint failed to bind.
The question is, is it possible to debug the release version without going to the trouble of compiling and installing the Debug version?
Also, is it possible for the VS debugger to launch the executable itself so that valid breakpoints may be hit?
EDIT: In case it is relevant, the call to MessageBox.Show is the last line of code. Is that why breakpoints are not settable at the closing braces that follow?
If you can modify the code, the easiest way to handle this would be to add Debugger.Launch(); (or Debugger.Break() to break right away) at the start of your Main function. This will allow you to attach a debugger as soon as the application starts.
Launching a debugging session with given command-line arguments is also possible, and quite simple - just open your project properties, go to the Debug tab, and add whatever command-line arguments you need. You can even select a different executable to launch (handy for DLLs).
If you really need to debug the installed application you would need to first build the debug version and install that in order to be able to attach and use breakpoints. The release version lacks the debugging symbols necessary to hook into the code. If the fact that the app is installed is not relevant to what you want to test, you can set command line parameters in the project's settings and set breakpoints as normal, and then just run the app in debug mode from VS.
you just need to add one line of code before executing other code.
System.Diagnostics.Debugger.Launch();
probably you just need to add on very first line of Main function.

How to debug .NET console application from Visual Studio 2013

I've created a .NET 4.5 console application (an .exe file) with c# that processes some data in various files. The whole thing runs in less than one second. I have a problem with a testing version of the .exe that I'd like to step through in the Visual Studio 2013 debugger using particular input files (the filenames are passed as command line arguments). I can't do an "Attach to process..." since the process has completed too quickly to attach to it. How do I debug in this case.
Note that I'm from the python world, and the python equivalent of what I'm trying to do is python -m pdb pdb_script.py.
Thanks for any advice!
Right click on your project and go to "properties".
Then select the "debugging" tab on the left-hand side.
There's a box where you can input the desired command line arguments for use when running in debug mode.
EDIT: If you're asking how to start the debugger, then add some breakpoints to your code, then right click on the project in your solution and pick Debug > Start New Instance.
Alternatively you can right click and choose "Set as Startup Project", after which you can start debugging with F5 or the "Start" button at the top of the UI.
Add the following line in your code:
System.Diagnostics.Debugger.Break();
This will allow you to debug your application before it ends.
In Visual Studio, you can add commandline arguments before starting a debugging session by right-clicking your project, selecting properties and then going down to the debug tab.
Then you can start it in Visual Studio with f5
If that's too much trouble (because you are going to change the arguments a lot), you could do something like adding a Console.ReadLine to your program at the beginning that will give you a change to attach a debugger. You could even have an extra command line argument for debugging that will only pause for you to attach the debugger if you pass that argument.

How do I debug an executable that is called by a batch file within that context?

I'm running into a tricky little problem. I have a compiled C# executable that is called with arguments in a batch file. I would like to run this executable through the VS2012 debugger, however I am unsure of how to attach the debugger to the executable as it is run from the batch script.
I am not able to set the batch script as the project's debug startup file (only .exes), and the only process I can find that is associated with the batch file is cmd.exe, which does not allow for debugging. I have added a pause to the beginning of the batch script so ideally the process should be running and I should be able to attach it, but I can't find anything of the expected name.
Anyone know how to do this? It seems like a pretty straightforward problem but I can't quite figure out how to get it into the debugger.
Or simply add a Debugger.Launch() at the start of your code:
System.Diagnostics.Debugger.Launch();
It will prompt you with all available VS debuggers, choose the one your are currently using.
See link for more information: http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.launch(v=vs.110).aspx
Add this line:
System.Diagnostics.Debug.Fail("stopping!");
to a good place in your code. Run your app. Hit "Retry" and you should be prompted for a debugger. Choose
Visual Studio.
Edit:
jp.gauthier's solution to use System.Diagnostics.Debugger.Launch(); is much cleaner. Upvote his instead. :)
Two things here: You cannot debug the batch script using the VS debugger. So when your exe returns the result is picked up by the script but you can't single-step trough that. To debug a batch script, flood it with pause commands and leave echo on to see what's going on.
To attach to your exe when it is started from the script, there are a couple of possibilities. One is (temporarily) modifying the exe to wait at startup a certain time (a few seconds or so) so you have time to attach the debugger. There's even a Win32 function to check whether a debugger is attached, if you want to. I remember having seen a possibility using the registry to automatically launch a process with the debugger, but I can't recall the exact procedure now.
Edit: Here's a topic describing the idea in short (answer 1).
Windows provides a way to start a debugger for any executable by setting the Registry value Image File Execution Options (MSDN on archive.org). The article describes exactly what you need: starting Visual Studio as the debugger.
Create the key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<Yourapp>.exe.
Create a String called Debugger
Set the value to devenv /debugexe
Don't forget to remove it when done.

What does it mean to attach to process in Visual Studio 2010?

I have seen this option under the debug menu, but I don't completely understand what it means. Could somebody explain it to me? Thank you in advance.
When you Attach to a Process, you're causing the debugger to attach to the process and allow you to set breakpoints within code that you have not started from a debugger. This is very useful in the situation of trying to debug things that have an automatic spawning process (such as .NET code that runs under IIS).
Instead of pressing F5 to start an instance of your app (or pressing the green "go" button), you can attach the debugger to an already running program. While you /can/ attach to an instance of Notepad, since Notepad is not a .net application and you don't have the .pdb debugging symbols for notepad, it won't do much good.
To attach to an already running instance of your program (or an internet explorer instance that is running your code)...
compile non-optimized
compile "Full" debugging symbols (the
default for the DEBUG configuration)
make sure the .pdb file is in
the same directory as the .dll or .exe (or you can find them manually)
make sure the code is in the same path as when it was compiled (or
you have to find it manually)
I don't know what the official documentation says, but this is how I use it.
If you are working in a project that runs continuously, say a web site deployed in IIS or a windows service and you have the solution with the code of the running program open in VS, you can attach to the process and debug it as if you had launched it hitting F5, set breakpoints, etc. It also allows to attach to a process running in a remote machine if it is properly configured, which turns out to be useful if you are debugging a process in a staging server or something like that.
You just need to make sure that the code you are editing is the one used to compile the binary.
You can attach the debugger to a running process and start debugging it where its at. Mostly useful only if you have the debugging information for the executable.
I tend to use it if my program hits an exception and I'm not already debugging it. I can attach and then view the variables and call stack.
That means to attach a debugger (i.e visual studio's integrated debugger) to the process so you can pause it and inspect variables at runtime. This happens when you hit F5 automatically, or can be done manually using the debug menu.

Debugging in multi-project under one solution in vs 2010

I have multiple projects in one solution. Project A (the starting project) starts Project B using Process.Start.
All the debugging methods work fine in project A, however after A starts B, not only do breakpoints not work, but also the output from calls to System.Diagnostics.Debug.WriteLine is not displayed.
Does anyone know how to debug in this situation?
In this scenario you have 2 processes running and you need to attach Visual Studio to both of them. Visual Studio supports attaching to multiple processes and getting it to do so is the same as attaching to a single process. Once the second process is launched do the following
Tools -> Attach to Process
Select the process
Hit Attach
The new process which is created at runtime will not have the debugger attached hence breakpoints and debug.writeline won't work.
You might be able to select "Debug" menu then "Attach to process" from within Visual Studio once the new process is running.
You are debugging the process that Project A is working and because you are starting a second process for Project B you have not attached your debugger to that process. So you need to attach to the second process.
You could add an call to System.Diagnostics.Debugger.Launch(); in the Main from Project B. So every time you start Project B it will ask you if you want to attach a Debugger.

Categories