I have a console app that I am trying to debug using remote debugger.
Clearly it seems you need to first run the application on the remote server, then attach to process.
My question is, whats the preferred method to catch the code at the start of execution, so it won't run away by the time you've managed to hookup the debugger.
Is there an industry standard best practice way to hook in and pause execution at a certain point till the debugger is attached?
There is a way to launch the remote app from Visual Studio.
Go to the Debug tab in project properties window.
Select Start external program and specify the exe path. (e.g. C:\MyTestApp\MyTestApp.exe)
Check Use remote machine and enter the name of the remote machine.
Detailed explanation here.
I couldn't think of a way to attach to a process in remote machine before the process starts. But , have you considered using Intellitrace to see the events and state of your program?
There is a way to attach a debugger to a Application automatically when the application launches. But I am not sure if it would work on remote debugging.
Similarly the System.Diagnostics.Debugger.Launch() would launch a process and start a Debugger attached to it. Again it doesn't support Remote launching and debugging.
Related
I have a .NET5 solution that is made up of several applications that communicate with each other using named pipes. In particular, there is a central service application (implemented using BackgroundService from Microsoft.Extensions.Hosting) and also an "Agent" that is responsible for launching the main service if it isn't running already, monitoring its status and relaying user commands to it. There are also a number of class libraries shared between the applications.
I've already configured the projects in the solution so they all build to the same output directory and I've set <UseCommonOutputDirectory>true</UseCommonOutputDirectory>.
After I launch the Agent in the debugger, it launches the service.exe using Process.Start() (it is not a Windows service). I can then (manually) attach to that process to debug it, too.
However, I'm wondering if this experience could be made smoother somehow:
Is there a way to set this up so the debugger would automatically attach to the child-process when it launches rather than me having to do it manually?
Is there a way to tell VS that it should also automatically rebuild the service and its dependencies when I launch the agent with F5? I keep forgetting this after making changes to the service...
I am aware that I can set up multiple startup projects so they all launch in the debugger simultaneously and that works for some debugging scenarios but I'm currently looking at a case where I really need the service to be launched by the agent and not separately before.
I have the following setup:
Development machine with VS2015 (can be 2017 if it makes a difference).
Embedded device that runs Windows service in .NET. Device has remote debugging service configured and enabled.
Right now to debug the solution I need to:
Build solution on dev machine.
Log in remotely to device and execute deploy script.
Attach debugger to remote process.
However this is quite a lot of manual steps for every code change. Ideally I would just press F5 and debugger would hit my breakpoints.
I can automate executing deploy script (eg. specify program to start as psexec with arguments), but how do I tell VS which debugger it should use, which host to use, which process?
As the configuration steps is needed while remote debugging, to use script to execute it, you can try the shortcut keys of the corresponding tabs of VS. For example, to open Attach to process window you could use Ctrl + Alt + P, for the process, you could find the Process ID in attach to process window which is same as the PID in Task Manger -> Details.
Every time I want to profile an application with Visual Studio I have to run vsperfclrenv /globalsampleon as recommended here and here (I have it normally switched off because I love the "edit and continue"-feature). The command prompt then states:
Enabling VSPerf Global Profiling. Allows to 'attaching' to managed services.
You need to restart the service to detect the new settings. This may require a reboot of your machine.
So far I haven't found a way to restart the service (as mentioned in the prompt) without rebooting my computer. Is there another way?
EDIT to add some information from the comments:
I am profiling an application that I start from Visual Studio
I use another instance of Visual Studio to profile the application via "attach profiler"
You do not need to run "vsperfclrenv /globalsampleon" and reboot if an application you profile can be launched from command line. In this case you can invoke "vsperfclrenv /sampleon" from command prompt and then launch you application from the same prompt. This will set proper environment for a process being profiled.
However, if your application cannot be launched from command line (e.g. you profile a managed service) then you need to invoke "vsperfclrenv /globalsampleon" and reboot to apply proper environment changes system-wide. A reboot is recommended because without it in some cases the environment changes are not successfully broadcasted system-wide.
You can find more information here and here.
UPD: Specifically, for your scenario please invoke "vsperfclrenv /sampleon" from VS developer prompt, start VS via invoking "devenv" from that prompt and use that VS instance to start an application. So, your application should have necessary environment set. Another VS instance which you use to attach can be run as usual.
I've tried to find an answer to this before posting this question. I've got a windows service running on another machine. I've written the service in C# and the directory from which the service executable runs holds both executable and debug files (.pdb). I'm attempting to remote debug the service for the first time using VS 2012 Remote debugging. I'm able to attach to the service process successfully. However, as this is my first time I'm not sure what I can do next. I've clicked the pause button and that pauses the service on the line ServiceBase.Run(ServicesToRun) which isnt much use to me. The service has a timer which sets off every 30 seconds and will run the code in the timer event.
My question is ... is there a way of stepping through the code using the debugger in such a scenario.
Do I need to have some debug specific code already in my codebase so that when a debugger attaches it will take me to a place in the code from where i can step through the code?
Thanks,
Andrew.
There are several ways to debug your developed remote application or windows service. If you were in your machine(local) that would be simple to debug.
System.Diagnostics.Debugger.Launch();
But as you are in different machine it depends how your both Machines are connected. Which means you have some limitations on debugging remote application/services.
A Quick search gave me the following result that seemed helpful to me for you,
You can use Remote Debugging Monitor that visual studio use for connecting to remote device and debugging. You can have a clear instruction here on How to: Run the Remote Debugging Monitor.
There's another tool which lets you debug remote application's after a proper setup. But it has some limitations or conditions that you must abide by.
Here is the tool named Remote Tool, you can find a detailed setup process from MSDN here on How to: Set Up Remote Debugging.
It has been clearly quoted there about the prerequisites for using this tool. But still I'm rephrasing those again for quick reviewers.
Prerequisites to use Remote Tool for Visual Studio
To debug on a remote device:
The remote device and the Visual Studio computer must be connected over a network or connected directly through an Ethernet cable. Debugging over the internet is not supported.
The remote device must be running the Remote Tools for Visual Studio 2012.
You must be an administrator to install the remote tools on the remote device. To communicate with the remote tools, you must have user access to the remote device.
Feel free to share if you get to a better and working solution.
Thanks for your response. It reminded me to post my solution here for others like me.
The solution is simple (It always is once you know it).
Ensure that you are running the same code on the target machine as you have open in Visual Studio. It has to be the same assembly and version else the debugger will not hit your breakpoints. Ensure you have your breakpoints setup where you want the debugger to break execution. Then attach to the target machine process and wait for the timer to kick in and run the process where you breakpoint is set.
Hope this helps.
Andrew.
The situation:
Working on a virtual machine for SharePoint development. I'd like to debug the sandbox solution that I have received from our contractor. Usually I manually attach to the process by going to the debug menu > Attach to Process... > then selecting the process from the list. This has worked in the past. Attaching to the process stopped working about the time that I reverted from Visual Studio 2012 back to 2010 (older projects had issues in 2010).
The problem:
Visual Studio gives an error, "Unable to attach to the process" when trying to attach to SPUCWorkProcess.exe that I need to debug a SharePoint sandbox solution.
Additional information:
I am able to attach to 2 other VM's are able to attach to the process
without issue (using same credentials).
An admin is able to attach to the process in this VM
Sandbox debugging IS turned on, even been restarted a few times from Central Admin.
Putting System.Diagnostics.Debugger.Launch()
in the code isn't hit/doesn't react
Attach to the process from the
task manager yields the message "Unable to attach to the crashing
process" ULS has a message for SPUCWorkerProcess "LogWMIData: Connect
Server failed: 0x80041003". Also noticed another error with OWSTIMER
"...Drives are running out of free space..." so could this be a
resource issue? the VM only has 4GB memory.
Given these details, I suspect that 1) available resources associated with my credentials are too small 2) something else is already attached to the process and crashing preventing me from attaching to it.
Solution was to provision a new virtual machine. My conclusion was that there is indeed a process running under my id (hence other people could attach to the process on the machine) preventing me from attaching to it again.
I was never able to figure out how to detach any process already attached to it, if there ever was one at all.
Hope this helps anyone else in some way. There appears to be very few solutions for "unable to attach to the process" that doesn't include forgetting to turn on the sandbox debugging.