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.
Related
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.
I have created a small program in C# WinForms that runs fine when I start it in Visual Studio 2017. But when I build the solution and double click the .exe, nothing happens, no screen appears, even the task manager doesn't see it. No errors. It's like it doesn't do anything! My only guess is that I built it wrong because I used Nuget to install newtonsofts JSON.NET in the solution. Do I need to do anything differently or should just building the solution work?
[solved]
today i learned the difference between the bin and obj folder, thanks to everyone for helping
Based on your comment:
it is in the obj/debug folder of the project
It sounds like you're running the wrong .exe. The obj folder is used for temporary/misc. files from the build process (see What is obj folder generated for?).
Instead, you want to run the exe within bin\Debug, if "Debug" is the configuration you're building for. You can see which configuration at the top of VS.
Like others have also mentioned, make sure that Newtonsoft.Json.dll is being copied to that output directory as well. Programs and their dependencies need to be together, generally speaking. Otherwise, your exe will not know where to find the JSON code it needs to function.
99% of the time, you should pretend the obj directory isn't even there.
If that still isn't pointing you in the right direction, run the app from a command window. Any exception should get printed to it and the window will remain open for you to examine (and this has the benefit of not needing any additional logging or exception handling code to see this error).
For example, I wrote up a bad application that get a NullReferenceException in a method called Test that is called from Main. As you can see, the stacktrace is easily visible, even though my app has crashed (credit to ColinM for bringing this up originally).
I believe that there's a problem with the startup module. Follow the steps below
Open your Solution in visual studio
Double click on properties
Select output type to Windows Application
Make sure to set the startup object as follows
I hope it helps
I think there is only one reason
There is a command line argument predefined in Visual Studio. Your application uses this argument to be executed, without it, it closes itself too quickly and you even can't see your application opened.
Right click on your project in VS -> Properties -> Debug and see if there is a value in command line arguments
exe and their supporting files should be in the bin folder. Do not copy only exe from bin folder and try to run it. It is a good idea to write some exception code to get the detail.
For future reference, yet another reason (that I have experienced) can be
System.Diagnostics.Debug.Assert();
statements. In my case, the program executed normally when started from VS but when I run it by clicking its .exe (created in the Debug Mode) then it hung/freezed. No exceptions, no printed logs. Frustrating. Then I checked the Windows Event Viewer (Our true friend). It explicitly displayed the problem and the culprit was a Debug.Assert() statement.
The lesson learned again: Check
Windows Event Viewer > Windows Logs > Application
especially when your app hangs/freezes/deadlocks or when no app logs are available.
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.
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.
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.