none
Debugging multiple programs simultaneously

    Question

  • Good afternoon Gurus.

    I'm having a problem debugging a problem involving the interface between two programs, 'A' and 'B'.    I knew how to do this several years ago, but I've apparently forgotten the technique.  I'm hoping one of you can refresh my memory.

    But first, a bit of background … program 'A' is a large, fairly complex program dealing with data acquisition and analysis.    During the course of that analysis, program 'A' may call upon program 'B' for additional information ...
    (e.g. Process.Start(pathToExecutable, argument).

    Program 'B' is expected to examine the argument and return the appropriate information.

    Program 'B' normally works just fine, and I've been using it for several months without grief. BUT, there's a LOT of initialization which must occur before it can turn a response. It can take ten or fifteen seconds before it returns a response. That seems FOREVER to the average user, so I've tried to break it up into three operational modes:

    'StandAlone' in which the Program 'B' is running by itself, accepting input from a user Form, rather than an argument.

    'Initialization' in which I'm attempting to do Program 'B's initialization during the period when Program A is initializing,

    'Consultative', in which Program 'A' is providing an argument defining the item for which additional information is requested.

    The problem is that somewhere along the line, Program 'B' is apparently NOT initialized properly.  If I can get the debugger(s) working together I can see both sides of the problem and fix it quickly.

    Now, I do recall from several years ago that it required two instances of the VS debugger. One 'attached' to a process (in this case, 'B') that is already running. And the other debugger is running the other App (in this case, 'A').

    Is that still do-able in VS2017 (last time I used this technique was with Win7 and VS2010).

    thanks for your help with this.

    Sunday, October 7, 2018 11:35 PM

Answers

  • VS is solution based. You can debug multiple projects in the same solution at the same time if needed. If they reside in different solutions then you need run multiple VS instances because, again, VS loads 1 solution at a time.

    To run multiple projects each time you start the debugger then right click your solution in Solution Explorer and select Set Startup Projects. Then check the one's you want to start up. This is most useful when they will run in parallel. If you want to start just one but later want to start another then you can right-click any (executable) project in Solution Explorer while debugging and select Debug\Start New Instance to start another process.

    The problem you have here is that it isn't going to work for your case. You are using Process.Start to start a separate process so the debugger that you may have started wouldn't be for that process. There are a couple of workarounds. The first option is to let your app start the second instance. Then go to the Debug\Attach to Process option and attach the debugger. This works great if the process runs for a while and you want to hook into it. If the process is failing to start or you want to debug what is going on while it is initializing then this won't work. In that case you'd probably want to put a Debug.Assert or Debugger.Break statement into the process's entry point so you get a chance to break into it with the debugger. You'd remove this when you're done.

    A better alternative, in my opinion, is to simply debug program B instead of program A. Since you mentioned that program A calls program B then you can basically make that same call within the debugger. Set program B as startup. In the project's debugger options specify the command line arguments you expect program A to send to program B. Then debug program B directly. 

    As for the interaction between programs A and B you might need to do something more complex then simply passing arguments and relying on initialization timing. There are any # of IPC mechanisms available that may work better. Then again maybe your apps just need to be reworked to make them reusable. As an example suppose program A needs some functionality from program B. Program B has this functionality but does other things as well. Depending upon the app complexity it may make sense to move the shared logic into a separate assembly that both A and B can simply reference directly. This eliminates the IPC difficulties. Of course if both A and B need to work together on the shared data then this would be harder to do. Yet another option would be to introduce a service (perhaps WCF self hosted or .NET Core API) that both apps can rely on. 


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Lincoln_MA Monday, October 8, 2018 10:32 PM
    Monday, October 8, 2018 3:50 PM
    Moderator

All replies


  • Is that still do-able in VS2017 (last time I used this technique was with Win7 and VS2010).


    Some possibly relevant docs:

    Debug Multiple Processes
    https://docs.microsoft.com/en-us/visualstudio/debugger/debug-multiple-processes?view=vs-2017

    Attach to running processes with the Visual Studio debugger
    https://docs.microsoft.com/en-us/visualstudio/debugger/attach-to-running-processes-with-the-visual-studio-debugger?view=vs-2017

    - Wayne

    Sunday, October 7, 2018 11:42 PM
  • GREAT!

    Thanks Wayne.    I'll check it out right now.

    Monday, October 8, 2018 12:11 AM
  • VS is solution based. You can debug multiple projects in the same solution at the same time if needed. If they reside in different solutions then you need run multiple VS instances because, again, VS loads 1 solution at a time.

    To run multiple projects each time you start the debugger then right click your solution in Solution Explorer and select Set Startup Projects. Then check the one's you want to start up. This is most useful when they will run in parallel. If you want to start just one but later want to start another then you can right-click any (executable) project in Solution Explorer while debugging and select Debug\Start New Instance to start another process.

    The problem you have here is that it isn't going to work for your case. You are using Process.Start to start a separate process so the debugger that you may have started wouldn't be for that process. There are a couple of workarounds. The first option is to let your app start the second instance. Then go to the Debug\Attach to Process option and attach the debugger. This works great if the process runs for a while and you want to hook into it. If the process is failing to start or you want to debug what is going on while it is initializing then this won't work. In that case you'd probably want to put a Debug.Assert or Debugger.Break statement into the process's entry point so you get a chance to break into it with the debugger. You'd remove this when you're done.

    A better alternative, in my opinion, is to simply debug program B instead of program A. Since you mentioned that program A calls program B then you can basically make that same call within the debugger. Set program B as startup. In the project's debugger options specify the command line arguments you expect program A to send to program B. Then debug program B directly. 

    As for the interaction between programs A and B you might need to do something more complex then simply passing arguments and relying on initialization timing. There are any # of IPC mechanisms available that may work better. Then again maybe your apps just need to be reworked to make them reusable. As an example suppose program A needs some functionality from program B. Program B has this functionality but does other things as well. Depending upon the app complexity it may make sense to move the shared logic into a separate assembly that both A and B can simply reference directly. This eliminates the IPC difficulties. Of course if both A and B need to work together on the shared data then this would be harder to do. Yet another option would be to introduce a service (perhaps WCF self hosted or .NET Core API) that both apps can rely on. 


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Lincoln_MA Monday, October 8, 2018 10:32 PM
    Monday, October 8, 2018 3:50 PM
    Moderator
  • Thank you, Michael, for an exceptionally well-detailed reply. I have marked it as 'answered'.

    Clearly, I have several options. My plan is to consider and research each, and take The Path of Least Resistance.

    Thanks again.

    -bill-

    Monday, October 8, 2018 10:39 PM