Is it possible to automate the "Attach to Process" tool?

[Marc_G_]

Hello,

I am using Intel Composer XE 2013 under MVS 2010. I have built a Solution with CMake in Debug mode. The solution is made up of several Fortran projects (say, app1.exe, app2.exe, ...). CMake also creates a VC++ project, RUN_TESTS, which mainly calls a .bat script (that I wrote by myself) where the applications are run in some predefined order (for instance, app1 is run, then app2, then app3, ...). When RUN_TESTS is launched, the calculations are correctly performed in each application and everything works fine. The problem comes when I want to attach the debugger to an application. For instance, let's consider that some breakpoints are added to the source code in app1. The procedure I am using is as follows: (1) Launch RUN_TESTS; (2) Go to  Debug > Attach to Process; (3) Select "app1.exe" from the list of the running processes and Attach. The symbols are loaded and the first breakpoint is correctly hit, thus allowing a debugging process. But what if app1 is running too fast? The debugger cannot be attached to it (app1 is no more displayed in the list of the running processes)... Is it possible to automate in some way the attachment process? I could consider the option of slowing down the application (by adding some loop at the beginning of the code), but this solution is not really satisfactory.

Thank you very much for your suggestions.

    Marc

[andrew_4619]

launch the app1.exe as a visual studio debug session from the bat file.

see http://msdn.microsoft.com/en-us/library/xee0c8y7.aspx

[Les_Neilson]

A colleague recently sent me the following. It may help.

"In the past I have found it useful to use macros that attach to the running executable but that wasn't possible after VS macros were dropped in 2012.

However, I have found a useful VS extension called ReAttach that is a useful time-saver.

http://visualstudiogallery.msdn.microsoft.com/8cccc206-b9de-42ef-8f5a-160ad0f017ae

It provides a button on the toolbar that does the same job as the macro I had, although it won't be looking for any specific program like the macro. If you are working with multiple executables you'll probably have to select which one. I think the button starts the last one attached to and the dropdown provides a choice of previous ones. Either way though, it is a lot better than using the standard attach to process dialog.

If you install it, to get it set up just attach to your executable the old way then stop debugging. After that you will see that the button is live and you can re-attach with one click."

Les

[Marc_G_]

app4619 wrote:

launch the app1.exe as a visual studio debug session from the bat file.

see http://msdn.microsoft.com/en-us/library/xee0c8y7.aspx

Thanks for your fast answer.

However, this solution does not seem to be what I'm looking for.

First, the .bat file must be modified, which, in my case, is not acceptable (indeed, I would have to modify many .bat files). Anyway, as you suggested, I tried to launch the application as a VS debug session from the .bat file (I used the following command: devenv /debugexe app1.exe). I may be wrong, but it seems that this command creates a new solution in MVS (app1.sln) which just includes the executable, without the source code. So it is not possible to use the traditional debugging tools (breakpoints, etc.).

I was rather looking for a way to automatically attach the debugger as soon as the application starts.

  Marc

[Marc_G_]

Les Neilson wrote:

A colleague recently sent me the following. It may help.

"In the past I have found it useful to use macros that attach to the running executable but that wasn't possible after VS macros were dropped in 2012.

However, I have found a useful VS extension called ReAttach that is a useful time-saver.

http://visualstudiogallery.msdn.microsoft.com/8cccc206-b9de-42ef-8f5a-160ad0f017ae

It provides a button on the toolbar that does the same job as the macro I had, although it won't be looking for any specific program like the macro. If you are working with multiple executables you'll probably have to select which one. I think the button starts the last one attached to and the dropdown provides a choice of previous ones. Either way though, it is a lot better than using the standard attach to process dialog.

If you install it, to get it set up just attach to your executable the old way then stop debugging. After that you will see that the button is live and you can re-attach with one click."

Les

Thanks for your answer.

This tool is indeed very useful. However, you must first be able to attach to the application the old way (i.e. with the classical "Attach to Process"). In my case, this is not possible because the application is running too fast (it is no more in the list of the running processes when I try to attach it).

  Marc

[Andrew_Smith]

If your exe has a console you can use the pause statement. Press enter after attached. Otherwise use some kind of timed delay loop to give you enough time to attach

[Marc_G_]

Andrew Smith wrote:

If your exe has a console you can use the pause statement. Press enter after attached. Otherwise use some kind of timed delay loop to give you enough time to attach

Thanks.

Yes, this is actually what I'm doing as a workaround. However, I would like to avoid modifying the code. Maybe I am too demanding...

[andrew_4619]

Perhaps:

http://msdn.microsoft.com/en-us/library/jj919165.aspx#BKMK_Start_multiple_processes_in_a_VS_solution__attach_to_a_process__automatically_start_a_process_in_the_debugger

[Andrew_Smith]

Some applications can not be started by Visual Studio and therefore attaching is the only option.

[onkelhotte]

As Les pointed out, ReAttach is a good program.

But it needs some time to attach. So if you want to check the first lines of your code, you´ll need to get creative like a pause statement or something like that.

Markus

[Marc_G_]

app4619 wrote:

Perhaps:

http://msdn.microsoft.com/en-us/library/jj919165.aspx#BKMK_Start_multipl...

Thank you. I've just tried the procedure described to launch the debugger automatically. The good point is that the debugger can indeed be attached to a fast running process (the breakpoints are correctly hit). There are two bad points however (sorry, I'm never satisfied...). First, it seems that you can only mention a generic application name in the registry ("app1.exe"), so that the debugger will try to attach whatever application is run (I have many different Solutions including an "app1.exe"). Second, the application called from the .bat file is followed by a "<" redirection operator (the command I'm using is similar to: %ComSpec% /C app1.exe < input_file.txt): unfortunately, this operator is no more active when the debugger opens.

Do you know if it is possible to define a specific application (for instance: d:\full\path\to\specific\project\bin\debug\app1.exe) as a key in the registry? This would allow to restrict the attachment process to a specific application.

Thanks again for your help.

[andrew_4619]

 you won't like this either....

You can set a registry key from a batch file using reg add "HKEY......