We are developing an open source Visual Studio extension for running tests written with the C++ Google Test framework within VS. Part of the VS API for test adapters is the possibility to run tests with a debugger attached. However, that API does not allow to grab the output of the executing process: It only returns the process id, and afaik, there's no way to access that output if the process is already running.
Thus, we'd like to launch our own process, and attach a debugger to that process on our own (following the approach described in the accepted answer of this question). This works so far, but we have one issue: It seems that attaching a debugger is only possible if the process already runs, resulting in missed breakpoints; the reason seems to be that the breakpoints might already be passed until the debugger is attached. Note that we indeed hit breakpoints, so the approach seems to work in general, but it's not exactly reliable.
Here's the code for launching the process (where command is the executable produced by the Google Test framework):
var processStartInfo = new ProcessStartInfo(command, param)
{
RedirectStandardOutput = true,
RedirectStandardError = false,
UseShellExecute = false,
CreateNoWindow = true,
WorkingDirectory = workingDirectory
};
Process process = new Process { StartInfo = processStartInfo };
process.Start()
DebuggerAttacher.AttachVisualStudioToProcess(vsProcess, vsInstance, process);
And here's the utility method for attaching the debugger:
internal static void AttachVisualStudioToProcess(Process visualStudioProcess, _DTE visualStudioInstance, Process applicationProcess)
{
//Find the process you want the VS instance to attach to...
DTEProcess processToAttachTo = visualStudioInstance.Debugger.LocalProcesses.Cast<DTEProcess>().FirstOrDefault(process => process.ProcessID == applicationProcess.Id);
//AttachDebugger to the process.
if (processToAttachTo != null)
{
processToAttachTo.Attach();
ShowWindow((int)visualStudioProcess.MainWindowHandle, 3);
SetForegroundWindow(visualStudioProcess.MainWindowHandle);
}
else
{
throw new InvalidOperationException("Visual Studio process cannot find specified application '" + applicationProcess.Id + "'");
}
}
Is there any way to attach a debugger in a more reliable manner? For instance, is it possible to launch a process from C# such that the process will wait for, say, 1s before starting to execute the passed command? That would give us enough time to attach the debugger (at least on my machine - I've tested this by adding a 1s wait period at the main() method of the Google Test executable, but that's not an option, since our users would need to change their test code in order to be able to debug it with our extension)... Or is there even a clean way (the described way might obviously fail e.g. on slow machines)?
Update: Let's recap the problem statement: Our users have a C++ solution including tests written with the Google Test framework (which are compiled into an executable to be run e.g. from the command line). We provide a VS extension written in C# (a test adapter) which discovers the executable, runs it with the help of a Process, collects the test results, and displays them within the VS test explorer. Now, if our users click Debug tests, we are starting the process running the C++ executable and then attach a debugger to that process. However, by the time it takes to attach the debugger to the process, the executable has already started running, and some tests have already been executed, resulting in breakpoints within those tests being missed.
Since we do not want to force our users to change their C++ code (e.g. by adding some waiting period at the begin of main() method of the test code, or with one of the approaches referenced by Hans below), we need a different way to attach that debugger. In fact, the VS test framework allows to launch a process with a debugger attached (and that approach does not suffer from our problem - that's what we are doing now), but that approach does not allow grabbing the process' output since all we get is the process id of an already running process (at least I don't know how that can be done in this case - I have done my research on that (so I believe :-) ). Grabbing the output would have some significant benefits to our extension (which I do not list here - let me know in the comments if you are interested), so we are looking for a different way to handle such situations.
So how can we run the executable (including grabbing the executable's output) and immediately attach a debugger to it, such that no breakpoints are missed? Is that possible at all?
You can PInvoke CreateProcess (see example How to call CreateProcess()...) to launch your debuggee using the CREATE_SUSPENDED creation flag (see Creation Flags for more detail) and then PInvoke ResumeThread to continue once your debugger is attached.
You may need to tweak the options to CreateProcess, depending on your specific needs, but that should do it.
Update:
A much better option, since you are writing a VS extension, is to use IVsDebugger4 interface to call LaunchDebugTargets4. The interface is documented and you can find plenty of examples on GitHub (just search for LaunchDebugTargets4). This method will avoid that pesky break in VS once you attach with the native debug engine.
Related
I am working on a "debug dispatcher" C# program that is a debug assistance tool. This is not a new application; it has been a part of this project and invaluable to debugging it for some time. However, it has some limitations, which I have been trying to address to enable a more complete debugging experience.
This debug dispatcher takes the place of a system service that accepts requests to launch applications, and its purpose is to permit an attached debugger to automatically interact with code that would ordinarily be launched in a child process. The child processes are themselves .NET applications.
When this tool was made (years ago), the first thing that was investigated was whether there might be any way to launch a child process with the current debugger already attached to it. None was found, and so instead the tool creates an independent AppDomain within which to launch each process, then loads the application as an assembly and calls its entry method. This is almost working perfectly, but the problem I'm running into is that if those child processes call Environment.GetCommandLineArgs, they get the debug dispatcher tool's command-line instead of the command-line intended to be passed into a child process.
I have been trying to find a way to override Environment.GetCommandLineArgs.
Based on the publicly-available source code, it looks like if my application were .NET Core, there would in fact be an internal method SetCommandLineArgs I could invoke via reflection. The fact that this is internal isn't particularly troubling to me as this tool is specifically a debug assistant; if it happens to break down the road because the implementation changed, so be it. It serves no purpose whatsoever outside of a debugging context and won't ever be on a non-dev machine. But... .NET Core and .NET 5 don't support AppDomains at all, and never will, so that's a non-starter.
I have tried using Ryder to redirect Environment.GetCommandLineArgs to my own implementation, but it doesn't seem to work, even with a .ini file specifying a [.NET Framework Debugging Control] section with AllowOptimize=0. It almost looks as though the JIT has special handling for this specific method, because even though the reference source shows it making an icall into a native method, when I request disassembly of the JIT output in the debugger, it shows no calls at all, simply loading a value directly from an inlined memory address.
I searched for ways to change the current process's command-line at the Win32 level, but that appears to be unmodifiable.
In the context of supporting multiple concurrent applications inside the same process by means of AppDomains (solely for assisting debugging), is there any way to intercept and/or override the return value of Environment.GetCommandLineArgs, so that I can support hosting applications that obtain their command-line arguments exclusively via that method?
Okay, well, I'm not sure what I did that changed it, but at some point redirecting Environment.GetCommandLineArgs using Ryder seemed to go from being unreliable (some calls would redirect, others wouldn't -- in some debug sessions, Ryder seemed to have no effect at all) to reliable (every call gets redirected). Ryder's redirection apparently doesn't automatically apply in all AppDomains, so I have to reinstall it each time I create an AppDomain, after which my experience has been that the process dies a messy death if I try to unload the AppDomain. But, for debug purposes... I think it's adequate.
I got a problem, i have accidentally left "Debugger.Launch();" code in my project, which was needed for the debugging as the application is a Windows Service.
Now, i'am done with the projects, it´s working as intended (Mostly) BUT, every time you start the service, it asks if you want to attach a debugger.
The Service has been packed to a MSI-package, and is more or less ready for delivery. And the guy who handles all the packaging and such is not at the office and none else know how to do it or has the authority to do it.
Enough with the backstory..
Can i in any way disable the debugger code without repackaging the
service? - Or do i have to repackage?
Is there any startup command or something to prevent it to ask for
debugger?
I have been searching alot about this, but the most of the existing questions/posts about this regards "Prebuild" solutions, but i'am looking for a "Postbuild" solution.
[EDIT]
Solution (Some kind of..)
I have still no idea if it is even possible to prevent attaching, but with the research i've done, it seems impossible. Therefore i had to recompile the service.
As many of you that commented suggested i implemented a key in the app.config, and a simple "if-case" around the "Debugger.Launch()", which work perfectly. Now i can simply choose to attach debugger or not.
Tamir Vereds solution worked on my local machine, and i did not even try on the customers server, because of the reason he also stated about base my code on this kind of tweaks.
I will accept this answer, as it partly could fix the initial problem.
Thank you all for answering.
Usually I would recommend recompiling the application and allowing it to be invoked with an argument or configuration cancelling the Debugger.Launch call, but since you don't want to recompile...
As for the documentation of Debugger.Launch() method:
If a debugger is already attached, nothing happens.
You can take advantage of that fact by making another small process that will "debug" your original process.
Since your process is a windows service you might need to use Auto-Debugger-Attach:
Open the registry editor by typing regedit in the cmd.
Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options.
Add a key with your debugged application's .exe's name.
Add a string value to that key with the name Debugger when the value is your new "Debugger process" path.
With your fake debugger attached, the original process will return frm the Debugger.Launch method without invoking another debugger.
Also you might want your fake debugger to deattach itself somehow later on so you can still really debug your application when needed.
Note that this is sort of an tweak and you don't want to base your production code on this kind of stuff.
This code runs as expected on a large number of machines. However on one particular machine, the call to WaitForExit() seems to be ignored, and in fact marks the process as exited.
static void Main(string[] args)
{
Process proc = Process.Start("notepad.exe");
Console.WriteLine(proc.HasExited); //Always False
proc.WaitForExit(); //Blocks on all but one machines
Console.WriteLine(proc.HasExited); //**See comment below
Console.ReadLine();
}
Note that unlike a similar question on SO, the process being called is notepad.exe (for testing reasons), so it is unlikely the fault lies with it - i.e. it is not spawning a second sub-process and closing. Even so, it would not explain why it works on all the other machines.
On the problem machine, the second call to Console.WriteLine(proc.HasExited)) returns true even though notepad is still clearly open, both on the screen and in the task manager.
The machine is running Windows 7 and .NET 4.0.
My question is; what conditions on that particular machine could be causing this? What should I be checking?
Edit - Things I've tried so far / Updates / Possibly relevant info:
Reinstalled .NET.
Closed any processes I don't know in task manager.
Windows has not yet been activated on this machine.
Following advice in the comments, I tried getting the 'existing' process Id using GetProcessesByName but that simply returns an empty array on the problem machine. Therefore, it's hard to say the problem is even with WaitForExit, as the process is not returned by calling GetProcessesByName even before calling WaitForExit.
On the problem machine, the resulting notepad process's ParentID is the ID of the notepad process the code manually starts, or in other words, notepad is spawning a child process and terminating itself.
The problem is that by default Process.StartInfo.UseShellExecute is set to true. With this variable set to true, rather than starting the process yourself, you are asking the shell to start it for you. That can be quite useful- it allows you to do things like "execute" an HTML file (the shell will use the appropriate default application).
Its not so good when you want to track the application after executing it (as you found), because the launching application can sometimes get confused about which instance it should be tracking.
The inner details here of why this happens are probably beyond my capabilities to answer- I do know that when UseShellExecute == true, the framework uses the ShellExecuteEx Windows API, and when it UseShellExecute == false, it uses CreateProcessWithLogonW, but why one leads to trackable processes and the other doesn't I don't know, as they both seem to return the process ID.
EDIT: After a little digging:
This question pointed me to the SEE_MASK_NOCLOSEPROCESS flag, which does indeed seem to be set when using ShellExecute. The documentation for the mask value states:
In some cases, such as when execution is satisfied through a DDE
conversation, no handle will be returned. The calling application is
responsible for closing the handle when it is no longer needed.
So it does suggest that returning the process handle is unreliable. I still have not gotten deep enough to know which particular edge case you might be hitting here though.
A cause could be a virus that replaced notepad.exe to hide itself.
If executed, it spawns notepad and exits (just a guess).
try this code:
var process = Process.Start("notepad.exe");
var process2 = Process.GetProcessById(process.Id);
while (!process2.HasExited)
{
Thread.Sleep(1000);
try
{
process2 = Process.GetProcessById(process.Id);
}
catch (ArgumentException)
{
break;
}
}
MessageBox.Show("done");
After Process.Start() check the process id of notepad.exe with the taskmanager and verify it is the same as process.Id;
Oh, and you really should use the full path to notepad.exe
var notepad = Path.Combine(Environment.GetFolderPath(
Environment.SpecialFolder.Windows), "notepad.exe");
Process.Start(notepad);
I'm working on a program which uses the System.Diagnostics.Debugger.Break() method to allow the user to set a breakpoint from the command-line. This has worked fine for many weeks now. However, when I was working on fixing a unit test today, I tried to use the debug switch from the command-line, and it didn't work.
Here's what I've tried:
I've confirmed that the Debug() method is really being called (by putting a System.Console.WriteLine() after it)
I've confirmed that the build is still in Debug
I've done a clean build
I've restarted Product Studio
A quick Google search didn't reveal anything, and the API documentation for .Net doesn't mention anything about this function not performing correctly. So... any ideas?
I finally figured out what was happening. For some reason, something changed on my machine so that just calling Debugger.Break wasn't sufficient anymore (still don't understand what changed). In any case, I can now cause the debugger to come up by using:
if (Debugger.IsAttached == false) Debugger.Launch();
Extracted from here (MSDN) the following note:
Starting with .NET Framework 4, the runtime no longer exercises tight control of launching the debugger for the Break method, but instead reports an error to the Windows Error Reporting (WER) subsystem. WER provides many settings to customize the problem reporting experience, so a lot of factors will influence the way WER responds to an error such as operating system version, process, session, user, machine and domain. If you're having unexpected results when calling the Break method, check the WER settings on your machine. For more information on how to customize WER, see WER Settings. If you want to ensure the debugger is launched regardless of the WER settings, be sure to call the Launch method instead.
I think it explains the behavior detected.
I was using Debugger.Launch() method and it stopped working suddenly. Using
if (Debugger.IsAttached == false) Debugger.Launch();
as suggested in this answer also did not bring up the debugger.
I tried resetting my Visual Studio settings and it worked!
Are you using VS 2008 SP1? I had a lot of problems around debugging in that release, and all of them were solved by this Microsoft patch.
Breakpoints put in loops or in
recursive functions are not hit in all
processes at each iteration.
Frequently, some processes may pass
through many iterations of a loop,
ignoring the breakpoint, before a
process is stopped.
Breakpoints are hit, but they are not
visible when you debug multiple
processes in the Visual Studio
debugger.
There are a few other debugger-related problems also fixed.
I've been having a hard time getting the output of a "sub-process" (one launched internally by a blackbox process that I'm monitoring via c# System.Diagnostics.Process)
I took the advice given by the answer of my previous post:
here. And there you can find the details of what I've been going through.
At this point, although I'm able to locate the ssh process spawned by process1.exe, that I'm monitoring. I can't redirect the output to my c# program, because it is an "already running process", and wasn't launched directly from C#.
It seems that, all the properties that you set on a System.Diagnostics.Process object, only take effect if you are explicitly launching that process from your c# application; if some other "unmanaged process" has launched the process, setting this redirection has no effect, because the process has already been launched by something that didn't specify the redirection I need.
Is there any way to redirect output of a process that has already been launched (a process launched by a program for which I have no scope to pre-specify redirection before this process is launched)?
Assuming there's no more straightforward solution, you could try to run a piece a code in another process through CreateRemoteThread(), explained here.
Instead of redirecting the output directly from the running process, can you capture the output as it leaves the process A at the intended destination, the pass it into your new process?
Perhaps you can look at this code. I found it when searching for a solution to do the same kind of thing; however, it was not really inter-process.
If that doesn't help you might be able to look at P/Invoking SetStdHandle and GetStdHandle which are supposed to be used when redirecting standard output. I think this is what the code sample linked to does to make the redirection happen.
Note: I just looked at this stuff and didn't actually get it to work properly. (I had a better solution available to me because I had access to the source code outputting to the console)
I've got the same conundrum. It's not an option for me to invoke anything internal in the slave process. It's already running, which code is beyond my control. But I do know it spits out Standard Output, which I want to monitor, process, etc. It's one thing I kick off the process, I can configure the redirection, but in this instance, the process will be launched secondarily to my kicking off the primary slave process. So I do not have that option. I haven't found a way for .NET Process to work under these conditions. Perhaps there is another way, maybe C++ is the way to go here? This would be marginally acceptable, but I would like to approach it from a .NET C# perspective if possible.