locked
remote debugging in Vista RRS feed

  • Question

  • I'm trying to remote debug a simple application compiled with VS2005.  The dev machine is running VS2005 pro, and the vista box has the remote debug tools installed.  I turned off the vista machine's firewall so that would not be an issue.  I started the debugger with:


     "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x86\msvsmon.exe" /timeout:99999 /noauth /anyuser /port:23

    I'm running XP on the dev box (source), logged into one domain, and the vista box is logged into a different domain.  I turned off authentication in msvcmon because of this.  I also tried using the "run as administrator" with msvcmon, to no avail.

    The debugger connects (I get a "user connnected" message in msvcmon on vista) but VS2005 on the XP box says "Unable to start xxx. This operation returned because the timeout period expired".  I can debug other XP boxes fine with the same config, so this must be an issue with Vista.  Once this happens, it seems like the msvcmon process hangs, and you can't re-connect.  End process is the only thing that gets you out.

    I saw some other posts on this problem, but no answers.

    Regards,

    Kurt

     

    Tuesday, September 12, 2006 9:24 PM

Answers

  • Hi Kurt.

    Someone in our group here at Microsoft ran into the same issue.  This is how they resolved it:

    Users of VS for remote debugging may have found themselves blocked on RC2 builds. Msvsmon.exe will run but claim it has to set up the firewall and then it errors out for all the available options. This is a result of by design change in Vista to tighten firewall security. The workaround is to manually enable the firewall settings from an elevated command prompt using this set of commands:

     

    netsh advfirewall firewall add rule name="Microsoft Visual Studio Remote Debugger - UDP 137" dir=in action=allow enable=yes localport=137 protocol=udp

     

    netsh advfirewall firewall add rule name="Microsoft Visual Studio Remote Debugger - UDP 138" dir=in action=allow enable=yes localport=138 protocol=udp

     

    netsh advfirewall firewall add rule name="Microsoft Visual Studio Remote Debugger - TCP 139" dir=in action=allow enable=yes localport=139 protocol=tcp

     

    netsh advfirewall firewall add rule name="Microsoft Visual Studio Remote Debugger - TCP 445" dir=in action=allow enable=yes localport=445 protocol=tcp

     

    When you next run msvsmon, it still prompts you to set firewall settings but this time will not error out when you give it the OK. Subsequent runs then stop asking like normal.

    Let me know if that helps,

    Sam

    Monday, October 16, 2006 5:16 PM

All replies

  • Hi Kurt.

    Someone in our group here at Microsoft ran into the same issue.  This is how they resolved it:

    Users of VS for remote debugging may have found themselves blocked on RC2 builds. Msvsmon.exe will run but claim it has to set up the firewall and then it errors out for all the available options. This is a result of by design change in Vista to tighten firewall security. The workaround is to manually enable the firewall settings from an elevated command prompt using this set of commands:

     

    netsh advfirewall firewall add rule name="Microsoft Visual Studio Remote Debugger - UDP 137" dir=in action=allow enable=yes localport=137 protocol=udp

     

    netsh advfirewall firewall add rule name="Microsoft Visual Studio Remote Debugger - UDP 138" dir=in action=allow enable=yes localport=138 protocol=udp

     

    netsh advfirewall firewall add rule name="Microsoft Visual Studio Remote Debugger - TCP 139" dir=in action=allow enable=yes localport=139 protocol=tcp

     

    netsh advfirewall firewall add rule name="Microsoft Visual Studio Remote Debugger - TCP 445" dir=in action=allow enable=yes localport=445 protocol=tcp

     

    When you next run msvsmon, it still prompts you to set firewall settings but this time will not error out when you give it the OK. Subsequent runs then stop asking like normal.

    Let me know if that helps,

    Sam

    Monday, October 16, 2006 5:16 PM
  • Thanks, that worked for me.
    Friday, November 3, 2006 4:35 PM
  • Worked like a charm - 10x!
    Friday, April 6, 2007 8:28 PM
  • yes.
    It works fine. Thankx.
    Wednesday, March 25, 2009 11:55 AM