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.
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 am currenlty trying to debug a service, but don't have the code located on the server, since there is alot and moving is not easy.
we are currently having issue with one server, and the only way I can debug the issue is by using dotpeek to decompile the .dlls and shown here #IgalTabachnik
Problem with this is the last step, my breakpoint gives an error and says that sourcecode is not availbale? which i don't get? ... it should be available through dotpeek?
Another things that might be an issue, is that I am debugging a schdule task, and I am not able to attach to a process while starting at the same time.
If you're having problems with dotPeek + symbol server, I do recommend using dnSpy. To do that you need to:
Open dnSpy as an administrator (dnspy-x86.exe or dnspy.exe depending on the target platform)
Load .exe file that contains the code of the service into dnSpy via File->Open
Navigate to the code where you want to put your breakpoint and set it there.
Go to Debug-Attach to process. Since you run dnSpy as an Administrator you should see your service on the list.
Select and attach to the process
Trigger the breakpoint.
debug
dnSpy generates it's own source code and has debugging capabilities so you can do everything in it. Its debugging experience is similar to Visual Studio's but it is not as reach as you can get in VS. Still, it can do its job.
I am using VS2015 and have a C# / ASP.NET webforms project which is working well. However, now I am needing to add new syntax and test it, so I opened it and set a few breakpoints, but the code is not stopping on the breakpoints! I opened both webconfig and Webconfig and they both have debug=true I also tried to re-build my project from the build menu and this did not solve it either. So what else should I do to get debugging working?
EDIT
and yes I am set to debug configuration, see image
Make sure that in addition to setting debug in Web.config that you've selected the DEBUG configuration for the project in Visual Studio. Look for the dropdown box in the toolbar that has Release vs. Debug. If it wasn't in Debug, rebuild all after that and confirm you still have zero errors.
Then make sure you are attaching the debugger. If your web project is the default, then the little green arrow next to the debug/release dropdown will launch a web browser on your site and (critically) attach the debugger. As long as you keep that browser instance running, the debugger will stay attached and you'll hit breakpoints even when someone else and/or another browser hits your site.
Finally, be aware that without some special tricks, it is very hard to hit breakpoints in Global.asax:Application_OnStart because this code runs before the debugger has a chance to attach. You can add trace statements in there and then view them after the fact though.
Posting this since it seems to have been the answer
I usually see this happen when the IDE is running from an old copy of the assembly. For instance, if you had two branches of the same project open and built... sometimes your changes aren't caught as being changes so you end up running on an old build. I'd shut down every other instance of VS, clean the current instance then shut that instance down. Make sure IISExpress is also shut down (check the tray). Then start it back up and try again
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.
Pls don't mark it as duplicate .. bcoz I have seen all the solutions but nothing is working for my case..
I have two machines devMachine and serverMachine
in devMachine I am developing application with Visual Studio and Now I have a simple Console Application..my need is I need to run this Console Application in serverMachine and debug from devMachine via Remote Debugging.
As told in Microsoft document, I have installed Remote Debugging tool in serverMachine and set the Authentication mode as Native (No Authentication) and run the Console Application in serverMachine.
Now , I have attached the remote process in devMachine's Visual Studio. All are working fine
But only problem is breakpoint is not hitting in Visual Studio
Note: I have placed required .pdb file in serverMachine and set that .pdb file path in devMachine's Visual Studio (Tools->Option->Debugging->Symbols).
Can anyone help me to resolve this issue?
What does the error message on the breakpoints say (if you hover over the breakpoint) - that it's different from the source? --> You can try disabling (from Tools/Options/Debugging) - Enable source file to exactly match the original version
What does the Modules window say - do the PDB's appear as loaded? if not, have you tried loading them manually (from the Modules window, right click the PDB and load)? - Is there an error message if it fails?
--> you might be in a case where the source files in the local machine are different from the ones on the remote one. Try copying everything over and see if that works (PDBs would be in the same folder as the EXE)
There are two reasons for the remote debugger to not hit the breakpoint
Wrong symbols.
Using the wrong .Net framework while debugging ( you can select on the "attach to process" window in visual studio).
Don't attach and just set remote debugging on. Copy all the project files to the identically placed and named folder in the server during post-build.
I had an issue with Visual Studio not breaking at my breakpoints although it looked like everything was setup correctly for the remote debugger on an IIS machine. I searched everywhere for an answer. The issue finally presented itself when I tried to manually attach the VS debug to a process (VS menu --> Debug --> Attach to process...) For some reason, there were multiple processes for the same application pool (there should only be one process, not sure where the others came from) I logged into my IIS server and killed all the processes for my application pool and then restarted the IIS application. When I saw there was only one process for the app pool (as I expected), I tried debugging in Visual Studio and it attached to the correct process. It turns out that when there were multiple processes for the same application pool, it attached to the "wrong" one.
Looking at your screen shot, could it be simply because the break points are in the "main" function which could already have finished before you can attach the debugger?
Suggestion:
Maybe put some artificial wait/delay code of say 20 secs in "main" above the first break point to give yourself enough time to attach to the process before "main" completes.