views:

1170

answers:

6

1.exe doesn't give enough time for me to launch the IDE and attach 1.exe to the debugger to break into.

A: 

I assume you have the source to 1.exe (if you're debugging it), then just insert a statement near the beginning that will cause it to hang around long enough to attach a debugger. ( getch() if you're desperate and it's not interactive. )

After the attach, just skip to the next statement and let it go.

clintp
A: 

You could put in some preprocessor commands for debug builds - just remember to build your release in release mode:

#ifdef DEBUG
Thread.Sleep(10000);
#endif
Greg Hurlman
+3  A: 

I would suggest taking the same approach as with NT services in this case. They will also start and usually not give you enough time to attach the debugger for the start-up routines.

Details are described here: http://www.debuginfo.com/articles/debugstartup.html

In short you add a registry entry for the second exe:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\2.exe Debugger = "c:\progs\msvs\common7\ide\devenv.exe /debugexe" (REG_SZ)

Change the c:\progrs\msms\ to match your settings.

Hope that helps.

AlexDuggleby
A: 

How is 1.exe launched? If you can launch it using CreateProcess(), you can start the process in a suspended state, attach the debugger, then release the new process.

Steve Morgan
A: 

If you are willing to consider a debugger other than Visual Studio, WinDBG can auto-debug child processes (native code only).

crosstalk
A: 

You did not mention what language you are using. But if you using C# or VB.NET you can add Debug.Break() or Stop to trigger the prompt to attach debugger to the process.

Or as mentioned above just use something like Console.Readline() or MessageBox.Show() to pause starting of process untill you can attach debugger to it.

Alex Reitbort