I want to attach to a process(a.exe) as soon as it is spawned, is it doable with VS? I only know the name of the process. Actually what I want to accomplish is set a breakpoint in c# code, but the code is belonging to another executable which will be launched by current running application(c.exe). The code is inside the initialize period so it is impossible for me to do the attach manually.
-
Can you give us more context? Do you own the process - is it your code? Is that process calling out to your code? – Jaco Pretorius Dec 23 '09 at 07:17
-
Does this answer your question? [How do I attach Visual Studio to a process that is not started yet?](https://stackoverflow.com/questions/8167610/how-do-i-attach-visual-studio-to-a-process-that-is-not-started-yet) – StayOnTarget Jan 26 '22 at 14:08
10 Answers
When I've faced this situation before (and I controlled both processes), I found a decent workaround is to put a call to Debugger.Launch() in the spawning process' entry point. VS will then pop up a dialog box and let you attach to the process.

- 23,245
- 2
- 44
- 44
-
For me, I also had to add rights to my user to the local security policy: see https://stackoverflow.com/a/10277353/6181641 – andrew Oct 12 '22 at 14:38
See the MSDN article, How to: Launch the Debugger Automatically - this would allow one to skip the plethora of busywork clicking confirmation dialog boxes [without turning off UAC or other messing]. The article lists the following steps:
- Start the Registry Editor (regedit).
- In the Registry Editor, open the
HKEY_LOCAL_MACHINE
folder.- Navigate to
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
.- In the Image File Execution Options folder, locate the name of the application you want to debug, such as myapp.exe. If you cannot find the application you want to debug:
a. Right-click the Image File Execution Options folder, and on the shortcut menu, click New Key.
b. Right-click the new key, and on the shortcut menu, click Rename. c. Edit the key name to the name of your application; myapp.exe, in this example.- Right-click the myapp.exe folder, and on the shortcut menu, click New String Value.
- Right-click the new string value, and on the shortcut menu, click Rename.
- Change the name to debugger.
- Right-click the new string value, and on the shortcut menu, click Modify. The Edit String dialog box appears.
- In the Value data box, type vsjitdebugger.exe.
- Click OK.
- From the Registry menu, click Exit.
- The directory containing vsjitdebugger.exe must be in your system path. To add it to the system path, follow these steps:
a. Open the Control Panel in Classic view, and double-click System.
b. Click Advanced System Settings.
c. In System Properties, click the Advanced tab.
d. On the Advanced tab, click Environment Variables.
e. In the Environment Variables dialog box, under System variables, select Path, then click the Edit button.
f. In the Edit System Variable dialog box, add the directory to the Variable value box. Use a semicolon to separate it from other entries in the list.
g. Click OK to close the Edit System Variable dialog box.
h. Click OK to close the Environment Variables dialog box. i. Click OK to close the System Properties dialog box.- Now, use any method to start your application. Visual Studio will start and load the application

- 28,293
- 19
- 112
- 138

- 59,778
- 26
- 187
- 249
-
4I like this answer because it works if your code is built in Release mode with PDBs on. The above Debugger.Launch() method does not work if built in Release mode. – Pretzel Apr 04 '13 at 17:14
-
4I have needed to add also a string value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug called "Auto" with value 1 because without that vsjitdebugger fails on open – user1011138 Mar 26 '19 at 07:55
-
5
-
Another nice Solution is to use the Visual Studio Extension "ReAttach". Can be found here.
If your process is not currently running, ReAttach will ask you to start it and attach to it as soon as it becomes available.

- 264
- 2
- 9
I have been looking for some way to do this when I launch a console application within an acceptance test.
I found this today - https://blogs.msdn.microsoft.com/visualstudioalm/2014/11/24/introducing-the-child-process-debugging-power-tool/
It's an add-on to visual studio, and it works a treat. When I debug an acceptance test (I use resharper test runner) and place a breakpoint within the app that gets launched, I can now debug the app in the same visual studio instance.

- 21,690
- 12
- 62
- 94
-
This is the easiest of all the solutions I've tried here. Installs easily and just works. No code changes required. – Brian White Oct 24 '17 at 20:09
-
1That's exactly what I was looking! It allows to debug child process in the same VS instance. Quick note from docs: `The power tool requires a native debugger. This means if you are debugging .NET code, you must choose to enable mixed mode debugging` – Natan Aug 25 '23 at 22:48
"Entrian Attach" is a Visual Studio add-in that does exactly this - you tell it the name of your executable and it attaches the debugger as the process starts, regardless of how it's started, before any code has run.
(Disclosure: I'm the author. I built Attach because I have this problem all the time!)

- 272,464
- 47
- 358
- 399
-
Didn't work for me... I could see the symbols loading but then the process would continue running and quit. Maybe it's because I was trying to attach to a process which I didn't have in the solution and therefore there was no breakpoint. – Nelson Rothermel Jul 10 '14 at 18:17
-
@NelsonRothermel: I'd like to help, but Stack Overflow isn't the place for Entrian Solutions tech support. :-) Email me (richie@entrian.com) if you'd like me to try to help with your problem - there are some easy things to try. – RichieHindle Jul 10 '14 at 20:29
-
1I ended up getting it working with gflags.exe and the key for me was to break on a certain exception type, so I think your solution would have actually worked if I would have set it up correctly. I won't be needing it now, but it's an interesting add-in I may have a use for in the future. – Nelson Rothermel Jul 11 '14 at 21:59
You can also use gflags.exe util that comes with Windows Debugging tools, all you need to do is open gflags.exe then go to image file enter the process name (a.exe) press tab and check the debugger checkbox, in the TextBox enter the vs path with the option /debugexe (i.e. "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe" /debugexe)
The automatically visual studio will open once the process is running you can add your breakpoints and press Run.

- 5,690
- 6
- 44
- 59
How about this: open project for a.exe
in VS, set the breakpoints etc. Then open Project Properties for a.exe, Debugging tab, and set Command to c.exe
. Then just hit Debug.
Unfortunately I never did this with managed projects, so I can be off the mark here. However, that's how I would do it with unmanaged (C++) projects. I think managed debugger should support it too.

- 17,507
- 3
- 35
- 35
-
1In my situation, the executable I want to debug is launched as part of the start-up of another executable. I would guess that's the driving force behind the question. – Mooing Duck Dec 12 '13 at 23:41
-
Worked for me. Quick and easy for direct cases but possibly not good for more complex ones. – AbstractDissonance Jan 10 '16 at 08:43
If C# code being launched by unmanaged code then make sure you check "Unmanaged code debugging" @Project properties --> debug options..

- 59,778
- 26
- 187
- 249

- 9
- 3
I really liked Entrian Attach as suggested by @RichieHindle, but I also found this free tool that does something similar. It catches all processes started by the debugging process.
Spawned Process Catcher: https://marketplace.visualstudio.com/items?itemName=Brubtsov.SpawnedProcessCatcher

- 6,384
- 4
- 43
- 78
-
1This module wouldn't install on VS 2013, 2015, or 2017. Hasn't been updated since late 2013. – Brian White Oct 24 '17 at 19:20
As of VS 2013 SP2, there's a free tool from Microsoft, which does the same as "Spawned Process Catcher" mentioned before - attaching all processes, which are started by a process already in debugging. Note: I have only tested this with unmanaged C++ (this works flawlessly).

- 1,807
- 1
- 21
- 27