I have an application that occasionally requires you to restart it after changing preferences. I do this by calling:
System.Diagnostics.Process.Start(Application.ResourceAssembly.Location);
That's great for the released version, but it's really annoying when I'm debugging and it relaunches the program outside the debugger whenever I need to change the preferences.
After some research, I've tried attaching to the debugger from code, but the very code I'm trying to run is running in the debugger already, and the application will be killed shortly. So I wrote an external program that can be called after relaunching the application (and freeing up the debugger) that supposedly attaches it to the debugger. Unfortunately this doesn't really do the job either. It appears to get attached to the debugger, but it doesn't actually let me do any debugging. It just craps out with an error if I try to pause execution.
Any ideas?
After more research, I realized all I wanted to do was programmatically hit the Restart button. I found this:
EnvDTE.DTE dte = (EnvDTE.DTE)System.Runtime.InteropServices.Marshal.GetActiveObject("VisualStudio.DTE.10.0");
dte.ExecuteCommand("Debug.Restart");
Works great!
You may not be able to debug with your code if you are using a Process object and its Attach method from the EnvDTE namespace rather than the Process2 object and its Attach2 method from the EnvDTE80 namespace. The following snippet should work:
foreach (Process2 process in Dte.Debugger.LocalProcesses) {
if (process.ProcessID == processId) {
process.Attach2();
Dte.Debugger.CurrentProcess = process;
}
}
May also be of interest here: the Visual Studio team has released a Visual Studio extension that allows automatically attaching child processes to the current debugger: Introducing the Child Process Debugging Power Tool.
It is available on the Gallery for Visual Studio 2013 and above.
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.
We are migrating a gigantic solution to .NET Core. It builds and works in Windows and we can debug using Visual Studio without problems.
In macOS, however, we can run it, but still not build it due to some issues.
In the meantime I was trying to think of a way to debug code on Mac. Why doesn't this work?
Add this to one of my DLL files
// Start of my application
System.Diagnostics.Debugger.Launch()
// The rest of my application
Compile that DLL file and use it, alongside the PDB file, to generate my new application.
Navigate to that part of the code in Mac
Nothing happens. Unlike in Windows where that code allows me to attach a debugger.
How can I properly debug a part of my .NET Core code?
Yes, you can!
Install Visual Studio Code and then, instead of running "dotnet run" in the Terminal as always, you can start your API by pressing F5 (make sure you are not running in the terminal at the same time!)
Make sure you put a breakpoint in a place where you are going to use, and then hit an endpoint (for example, Postman).
I have installed the plugin "C#" from Microsoft, but I don't know if that helps...
Alternatively, you can try Visual Studio for Mac, but I found that this works in Visual Studio Code and I prefer it!
On Windows, you have an opportunity to hook up a debugger when the process hits a 'first chance exception'. The default debugger is specified in the registry, and you can find more information in - Configuring Automatic Debugging.
I don’t think that is possible in Mac OS X. Have a look at How does one automatically attach a debugger to a process at process start on OS X?
Also, I tried your code on macOS:
using System;
namespace DebugConsole
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Calling Debugger.Launch");
Console.ReadKey();
System.Diagnostics.Debugger.Launch();
Console.WriteLine("Continuing...");
Console.ReadKey();
Console.WriteLine("Hello, World!");
}
}
}
This builds successfully, but when System.Diagnostics.Debugger.Launch() is hit, on macOS the process does not hit the debugger. On a Windows machine it does. In short, this code should not be the reason why your code does not build on macOS.
Update:
Use Visual Studio Code to open your code. Visual Studio Code asks you to add file launch.json for the debugging configuration.
It will also download the .NET debugging extension which is required for obvious reasons.
You can launch your console application from here, but if you want to launch the process for some reason in the background and then hook up to it then you can do that as well. On the top you will see the menu next to the 'RUN' menu - this has two options. 'Dotnet core launch' will launch the process through Visual Studio Code and attach to it. 'Dotnet core attach' will attach to already running process.
If you select the 'attach' option, it asks you for the process to be attached. Refer to the screenshot below -
Please note that you will have to put a breakpoint in the IDE. As mentioned above, the debugger does not enter debug mode based on the Debugger.Launch() function call.
When launching a program from Visual Studio 2012 in debug mode (using the "Play" button), my application fails at a certain line of code. For the sake of being specific, the error I'm receiving is:
Method Open threw an exception. Could not create a service object instance, or could not get its IDispatch interface.
However, when I run the application by simply launching the EXE by clicking on the file name, I do not encounter this error.
Additionally interesting is the fact that I can add the following statement to my code (causing the debugger to attach AFTER launch) and I do not receive the exception I mentioned above.
if(!Debugger.IsAttached) {
Debugger.Launch();
}
So, in short: When Visual Studio launches my program, there is SOMETHING different about the processes permissions / rights, app domain, or other factor that is changing its ability to operate "normally". I know that the parent process of my application when launched from Visual Studio is the devenv.exe process, could that have anything to do with it?
Some troubleshooting I've done:
I have disabled the Visual Studio Hosting Process to eliminate that from being a potential issue.
I've inspected the process in each different testing scenario listed above in Sys Internals' Process Explorer. I've compared permissions, session, user name the application was launched under, and many other things to attempt to find a reason why the application would function differently. All comparisons come up identical with the exception of the parent process (explorer.exe when launched manually and devenv.exe when launched through Visual Studio)
Any ideas?
Update:
I did another test and selected Debug -> Start Without Debugging, which DID NOT produce the error specified, but still launched the program with its parent process being devenv.exe which rules out that as being a potential issue. So its something to do with the debugger being attached right from the start of the program.
While debugging through the code, I am getting following error.
A debugger is attached to w3wp.exe but not configured to debug this unhandled exception. To debug this exception, detach the current
debugger.
I tried the fix from the following link, but it won't work for me.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/373e738f-1bc7-4dcb-88b4-ee8e78d72dc1/an-unhandled-exception-was-raised-from-microsoft-net-framework-v-10-11-or-20-but-the-current?forum=vsdebug
It works fine when I use Visual Studio 2012, but it fails when using Visual Studio 2013. I tried repairing Visual Studio 2013, but It never worked.
Do anybody know the fix for it?
Thanks.
Try This
Go to Project Properties
Debug
Change Debug type to Mixed(managed and native) from managed only for both Application and Background process.
You may be encountering this issue if you have native C code (unmanaged) and C# (managed) code in the same project.
Changing the debug type to mixed makes debugging significantly slow.
I've just had this issue and it was solved by enabling 32 bit applications on the website's App Pool, as detailed here (thanks Colm!):
http://colmprunty1.azurewebsites.net/a-debugger-is-attached-to-w3wp-exe/
Sounds like maybe you have just in time debugging turned on. Your program throws and exception that your current debugger is not configured to handle and perhaps the system is launching the just in time debugger. This is a registry setting but can also be controlled via options in Visual Studio.
http://msdn.microsoft.com/en-us/library/k8kf6y2a(v=vs.85).aspx
To disable Just-In-Time debugging by editing the registry
On the Start menu, search for and run regedit.exe
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, delete the following registry keys also:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
Had the same problem. Got this message all the time I wanted to start my app in debug-mode.
Turned out the problem was, that I still had appverifier (http://msdn.microsoft.com/de-de/library/windows/hardware/ff538115(v=vs.85).aspx) linked to my app. Once unlinked everything went back to normal and I could debug normally.
Not sure if anything to do with your problem. Just saying :)
Are you able to modify the source code so that it thows a meaningful exception?
Also try to recompile the source with VS 2013 and check if the debugger runs fine this time.
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.