I have written a program that spawns a handful of processes.
By default, Visual Studio does not debug the new processes -- only the original process that created the new ones.
Is there a way to automatically, in code, connect Visual Studio up to the processes when they are created?
From: debugging a process spawned with CreateProcess in Visual Studio
You can temporarily put in a call to DebugBreak() somewhere in the
startup code of your child process. This will cause Windows to prompt
you if you want to debug that process.
EDIT:
Since both projects are in the same solution, configure VS for multi-project debugging:
(VS2010)
Context-click the solution node in Solution Explorer
Choose Set Startup Projects...
On the dialog select Multiple startup projects radio button
In the Project grid change the Action for all the projects you wish to debug to Start
This still provides a prompt, but does attach the debugger:
if (!Debugger.IsAttached && DebuggerFlagSet()) Debugger.Launch();
and then in the parent process
if(Debugger.IsAttached)
SetDebuggerFlag()
You'll need a mechanism for the debugger flag such as a file on disk/reg key/mutex etc.
The debugger being launched won't be the same as the initial instance.
To do this, you'll have to write a VS Add-in or a VS Package, because you'll want to sit in the background and wait for child processes to load.
Here's a general recipe of what you'll want to do:
Get the ID of the debuggee process (ie, uint processID = DTE.Debugger.CurrentProcess.ProcessID)
Add reference to System.Management and use a ManagementEventWatcher to listen for new processes creation as described in this thread. Your query should be "SELECT ProcessID FROM Win32_ProcessStartTrace WHERE ParentProcessID = " + processID
When a new child process loads, find it by its processID in DTE.Debugger.LocalProcesses, then call .Attach() on it.
Related
I would like to know how vsjitdebugger.exe can cause a particular running instance of Visual Studio to be used to debug a process.
Background: currently vsjitdebugger.exe is set as the executable run whenever there is a "debug break" - i.e. in C# System.Diagnostics.Debugger.Launch();. Whenever this happens I see a dialog with a list of available debuggers - this includes all running instances of Visual Studio.
My question is how vsjitdebugger.exe activates a particular running instance of Visual Studio. Please note that I am particularly interested in existing running instances of VS and not in starting a new instance.
Maybe you can attach the process to vs debugger through VS sdk.
public static void Attach(DTE dte)
{
EnvDTE.Processes processes = dte.Debugger.LocalProcesses;
foreach(EnvDTE.Process proc in processes)
if(proc.Name.IndexOf("Target.exe") != -1)
proc.Attach();
}
The document: Process Interface
I am experiencing a weird behaviour from Visual Studio 2013. I've got a C# program which writes to the standard output, let's say
using System;
using System.Threading;
namespace CsSandbox
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello world!");
Thread.Sleep(10000);
}
}
}
In the Debug tab of the project's properties I have redirected the output to a file, like this:
If I open the file within those 10s when my application is still running, the file does contain "Hello world!". However, as soon as the program exits, the file is cleared. This does not happen when I run the program from the command line.
Is there a rationale why Visual Studio does it? Is there a way to bypass this behaviour?
I believe this is due to the way Visual Studio hosts your application, in order to reduce startup time when debugging.
What happens is that your application (Program.exe) will actually be hosted in another process (Program.vshost.exe), which is started with the same command line arguments. When your application ends, this process is immediately restarted. You should be able to see this within Task Manager - look in the details tab so you can see the PID of the processes, and run your app - you'll see one Program.vshost.exe instance which ends when your app finishes, and another one come up immediately. That's then overwriting your output file.
One fix for this is to give your application a command line argument for the file to write to - and open that file within your Main method. You won't get there until you start running the app again.
Another option would be to simply stop using the hosting process - in the Debug part of your project properties, at the bottom you should see a checkbox for "Enable the Visual Studio hosting process". Uncheck this and I think your problem will go away - but it'll take longer to start debugging.
See this blog post for more information about the hosting process.
I got a break point on the first line of Application_Start(), but Visual Studio wont break on it.
Visual Studio have attached itself to the IIS working process:
Auto-attach to process '[2092] w3wp.exe' on machine 'SRD00510' succeeded.
My breakpoint in the home controller do work.
update
I've tried:
iisreset
restarted visual studio
Rebooted.
Tried to reinstall aspnet (aspnet_regiis -i)
Reading your question, I assume you are using IIS for debugging, not Visual Studio Development Server.
In this case, debugging application start is tricky, because it is only called once when the application pool is started or recycled. When Visual Studio attaches to the process, Application_Start has already been running.
The trick is to make the application pool recycle without killing the process you are attached to.
Do the following:
In Visual Studio (must be run as Administrator) set your breakpoint in
global.asax.cs and start debugging as usual (F5). The page opens in
your web browser, but the breakpoint isn't hit.
Now the trick: With a text editor, open web.config from where it is
served by IIS, change it (e.g. enter a blank line somewhere) and
save it. In contrast to recycling the application pool in IIS, this
lets the application pool recycle (and thus running through
Application_Start in global.asax.cs the next time the web site is
called) without killing the process you are attached to.
In your web browser, reload the page. The breakpoint should be hit now!
That works for me (IIS 7.5, VS2015).
Place this line in your Application_Start().
Debugger.Break();
This will present you with a dialog which will allow you to select a debugger. You might need to restart the application pool.
Application_Start() only runs once, when the application starts. A few things that restart the application are:
web.config changes
recycling the worker process - you can do this in IIS Manager or by running iisreset at the command line.
My solution is to switch to using the 'Visual Studio Development Server' to deal with the application class (Global.asax) issues. When done I switch back to IIS.
I assume you're loading the application by clicking the "debug" button in Visual Studio? That's what I'm doing (in VS 2012) and seeing similar problems. Pressing that button the first time starts the application and correctly hits the breakpoint. But it seems like after I stop debugging the application itself keeps going. So, future attempts to debug just attach to the existing process.
There's a "restart" button next to the "stop debugging" button, so I'd assume clicking that at least would change things.
The debugging app does not show up in IIS manager, so I can't stop it there. Likewise, iisreset doesn't catch it either.
Only thing I've figured out so far is to change a line of code, thereby forcing visual studio to trigger a build and then it kills the existing proc and starts over. Kind of annoying if I just want to step through there multiple times.
I don't consider this a suitable "answer", but it might be a helpful workaround for you until somebody does come in with a real answer.
I've got around this problem before by doing this:
Run a clean on my solution (Right click the solution node and click clean)
Close solution
File -> Exit on visual studio
If you have multiple instances of visual studio running then exit out of all instances. Ensure "devenv.exe" is not listed in the processes in task manager
Delete the user options file (.suo), usually in the same directory as your solution (.sln) file
Recycle IIS worker process or if using the development server, kill that process
Now open your solution and give it a shot. (keep your fingers crossed :))
Whenever you run an application for the first time, or say start an application, there is an ASP.Net Development Server - Port [port number] that starts,
Application_Start() runs once in the course of an application.
If you want the break point to be reached , you have to stop the ASP.Net Development Server Port and run your application again.
if [2092] w3wp.exe is a service that you made, try this :
stop service -> rebuild service project -> start rebuilt service -> try to debug
If using IISEXPRESS is not an option, as #David Perlman mentions, I would go for a Logger. Log4Net or NLog are both good. It's good to have a logger in the longrun, for instance in production environments.
namespace DataService
{
using NLog;
public class Global : System.Web.HttpApplication
{
private Logger log;
protected void Application_Start(object sender, EventArgs e)
{
LogManager.LoadConfiguration("nlog.config");
log = LogManager.GetCurrentClassLogger();
log.Error($"Read this line in the log specified in nlog.config");
}
When running a process under the debugger, I would like to start a child process in the same debugger.
Currently, I use
Process.Start("sample.exe");
I want it to be something like this:
if (Debugger.IsAttached)
// start "sample.exe" in the same debugging session
else
Process.Start("sample.exe");
I could pass a flag to the child process that instructs it to call Debugger.Launch(), but that won't catch start up errors, and it results in a debugging session where some features are not enabled (such as edit and continue, etc). It's preferable to have the debugger launch the process directly.
You should attach debugger to process you are starting. This could be done:
Manually from Visual Studio after starting "sample.exe" select it menu Debug > Attach to process..
Programmatically attach debugger inside "sample.exe"
Attaching to a Process using VS.NET Automation Model
UPDATE: You can setup windows environment to attach debugger every time "sample.exe" starts: Launch the Debugger Automatically (you will need to call Debugger.Break anyway)
Some external tool maybe
Here is code for "sample.exe" to attach debugger:
if (!Debugger.IsAttached)
Debugger.Launch();
Debugger.Break();
You should pass some parameter to "sample.exe" to verify if you need to attach debugger.
Process.Start("sample.exe", "Debug=true");
you can change the properties of your solution to start multiple apps.
an explanation is here Run Multiple projects
The MSDN article is here MSDN Article on running multiple projects
Assuming that sample.exe would be the host for code you want to debug, you can use project properties -> debug settings - choose action as an external program and provide path to sample.exe. The VS will start this executable and attach the debugger to it.
Visual Studio Debugger Team created an extension that does that automagically:
https://marketplace.visualstudio.com/items?itemName=vsdbgplat.MicrosoftChildProcessDebuggingPowerTool
Under my solution I have 2 projects Project A console application , Project B Winforms Window.
How I can From Project B to start new process with console application from Project A ?
I tried to making it via
Process note = new Process();
note.StartInfo.FileName = "note.exe";
note.StartInfo.Arguments = "123";
note.Start();
But in that way i cant debug both processes from one vs instance . Any idea ?
Thanks
If the only reason that you want to start the two projects is that you want to be able to debug both of them you can also configure your solution to have multiple startup projects:
Solution -> Properties -> Set Startup Projects...
If you are going to start the other project as a separate project anyway, you could use
Debug -> Attach to Process
to attach to the newly started process. Then you will also be able to debug both processes in Visual Studio. Attaching the debugger can also be achieved programmatically. In project A you can add the following code to the Main method:
#if DEBUG
System.Diagnostics.Debugger.Launch();
#endif
In the dialog that will then pop up you can select the already running instance of Visual Studio.
Another option is to start the Startup Project via F5 (or Debug > Start Debugging) and the second one by right-clicking the project and going Debug > Start New Instance.
You can start debugger in the application launched by the following statement
System.Diagnostics.Debugger.Break()
then you can choose the visual studio instance and start debugging.