locked
Remote Debugging - Cannot find the specified path RRS feed

  • Question

  • Running VS2008, setup for remote debugging under windows 7 (64-bit host machine) and embedded XP (remote machine).

    I have setup remote debugging.  It appears to be working correctly.  However, when I try to run my application through the debugger on the host machine, it hangs for a long time and then finally ends with "Error while trying to run project: Unable to start program.  The system cannot find the path specified.

    MSVSMON is running correctly on the target machine.

    The debugging monitor shows "OEM-IGTUCC000\UCC_Remote connected" with each attempt to run the debugger.

    Under project properties,

    BUILD->Output Path is set to "U:\Apps\DebugTest", where U is the mapped drive under the same user account as the launched VS2008 IDE session (UCC_REMOTE).

    BUILD->Start Action, Start external program is set to U:\Apps\DebugTest\MyApplication.exe

    BUILD->Start Options, Working Directory IS SET TO U:\Apps\DebugTest\

    BUILD->Start Options, Use remote machine is set to bookb@OEM-IGTUCC000

    The project is cleaned, then rebuilt.  Then, I press F5.

    I can see that I connect according to the Visual Studio Remote Debugging Monitor.  I can also clearly see the application executable is in the execution path.  However, I still get the "cannot find specified path" error.

    Any help would be greatly appreciated.

    Thanks

     

     

    Tuesday, October 12, 2010 10:43 PM

Answers

  • No.  I just realized that the "Working" directory is from the point of view of the remote computer.  So, that needed to be D:\apps\DebugTest.

    However, I still need my output (result of the build) to go out to my remote computer.   If I set my "output directory" to the remote computer, I still can't seem to debug (says working directory does not exist). 

    I found the following setup appears to work.  Please let me know if there is a shorter way.

    BUILD->Output Path is set to d:\apps\DebugTest

    DEBUG->StartAction->Start project selected (got rid of the "start external program").

    DEBUG->Working Directory is set to d:\apps\DebugTest

    BUILD EVENTS->Post Build: 

    1. XCOPY /T /E /Y D:\Apps\DebugTest\*.* U:\Apps\DebugTest\  (Creates the directory in case it's not there already)
    2. XCOPY /E /Y D:\Apps\DebugTest\*.* U:\Apps\DebugTest\  (Copies the contents of the directory)

    BTW, this is a C# application, and each time I hit a break point, it seems to pause the debugger for about 30 seconds.  Press F10 to step over a line...again the debugger chews on it for what seems like an eternity.  This will not be useful to me.  Any thoughts?

    Thanks again.

    • Marked as answer by Mav_2010 Thursday, October 14, 2010 10:02 PM
    Wednesday, October 13, 2010 1:26 AM

All replies

  • I have setup remote debugging.  It appears to be working correctly.  However, when I try to run my application through the debugger on the host machine, it hangs for a long time and then finally ends with "Error while trying to run project: Unable to start program.  The system cannot find the path specified.

    MSVSMON is running correctly on the target machine.

    The debugging monitor shows "OEM-IGTUCC000\UCC_Remote connected" with each attempt to run the debugger.

    Under project properties,

    BUILD->Output Path is set to "U:\Apps\DebugTest", where U is the mapped drive under the same user account as the launched VS2008 IDE session (UCC_REMOTE).
    BUILD->Start Action, Start external program is set to U:\Apps\DebugTest\MyApplication.exe

    Is the U: drive mapping set up on the remote machine (with the user
    account you're running msvsmon as)? If you use the machine with that
    user account, can you access drive U: ?

    Dave

    • Marked as answer by Mav_2010 Thursday, October 14, 2010 10:02 PM
    • Unmarked as answer by Mav_2010 Thursday, October 14, 2010 10:02 PM
    Tuesday, October 12, 2010 11:15 PM
  • No.  I just realized that the "Working" directory is from the point of view of the remote computer.  So, that needed to be D:\apps\DebugTest.

    However, I still need my output (result of the build) to go out to my remote computer.   If I set my "output directory" to the remote computer, I still can't seem to debug (says working directory does not exist). 

    I found the following setup appears to work.  Please let me know if there is a shorter way.

    BUILD->Output Path is set to d:\apps\DebugTest

    DEBUG->StartAction->Start project selected (got rid of the "start external program").

    DEBUG->Working Directory is set to d:\apps\DebugTest

    BUILD EVENTS->Post Build: 

    1. XCOPY /T /E /Y D:\Apps\DebugTest\*.* U:\Apps\DebugTest\  (Creates the directory in case it's not there already)
    2. XCOPY /E /Y D:\Apps\DebugTest\*.* U:\Apps\DebugTest\  (Copies the contents of the directory)

    BTW, this is a C# application, and each time I hit a break point, it seems to pause the debugger for about 30 seconds.  Press F10 to step over a line...again the debugger chews on it for what seems like an eternity.  This will not be useful to me.  Any thoughts?

    Thanks again.

    • Marked as answer by Mav_2010 Thursday, October 14, 2010 10:02 PM
    Wednesday, October 13, 2010 1:26 AM
  • With my new settings, everything is running great now.  The delay I saw seems to only occur in the early part of my application, where it is setting itself up as a WCF endpoint.  I let it run a bit further, and I am not seeing any delay at all.   So...nevermind?  :-)
    Wednesday, October 13, 2010 1:45 AM
  •  

    Glad to see that you got it resolved, by the way, please remember to mark the replies as answers if they help and unmark them if they provide no help. This can be beneficial to other community members reading the thread.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Thursday, October 14, 2010 12:03 AM