M
Mike Loux
I'm not a huge fan of cross-posts, but I think these are the two most
appropriate spots to put this, so here goes.
I am trying to set up remote debugging from a copy of VS 2005 (SP1 for
Vista) installed on my Vista enterprise box here at work. The target
machine is a Windows Server 2008 VMware machine that I have
successfully remote debugged applications on from my old XP box
(currently in the middle of transitioning between the two), so I know
the permissions are all OK on the remote machine.
When I try and attach to the remote machine from my Vista box, I get
the usual "The Windows Firewall on this machine is currently blocking
remote debugging" message. Telling it to unblock for either subnet or
any computer nets me the equally-usual "Cannot add a port to the
Windows Firewall exception list" message. Nothing new here there is
a ton of documentation on the Web detailing how to manually set the
firewall up to allow this.
So I have manually added exceptions for UDP ports 500 and 4500, as
well as TCP port 135. I have also made sure File and Print Sharing
was excepted and added an exception for devenv.exe, everything that
worked for me on the XP side. Yet I still get the same error when I
try and attach to a remote server.
I have not tried disabling the Firewall (it's locked by a Group Policy
and I am still trying to figure out how to disable it without causing
my PC to explode). I do, however, have UAC disabled, and I am not
sure if that makes a difference or not.
The weird thing is that when I cleared all of the firewall exceptions
manually and then tried to automatically change them via the "unblock
remote debugging" option, I got the usual "cannot add a port" error,
but when I went to the Firewall settings, I found that the ports had,
in fact, been successfully added. That was weird.
Does anybody have any ideas on where to go next? It's frustrating as
hell knowing the remote end (usually the hardest part) is working
fine, but I can't get out of my own box. The on-ramp to the highway
is clear, but I'm locked in my garage, so to speak. Thanks for
anybody's help!
appropriate spots to put this, so here goes.
I am trying to set up remote debugging from a copy of VS 2005 (SP1 for
Vista) installed on my Vista enterprise box here at work. The target
machine is a Windows Server 2008 VMware machine that I have
successfully remote debugged applications on from my old XP box
(currently in the middle of transitioning between the two), so I know
the permissions are all OK on the remote machine.
When I try and attach to the remote machine from my Vista box, I get
the usual "The Windows Firewall on this machine is currently blocking
remote debugging" message. Telling it to unblock for either subnet or
any computer nets me the equally-usual "Cannot add a port to the
Windows Firewall exception list" message. Nothing new here there is
a ton of documentation on the Web detailing how to manually set the
firewall up to allow this.
So I have manually added exceptions for UDP ports 500 and 4500, as
well as TCP port 135. I have also made sure File and Print Sharing
was excepted and added an exception for devenv.exe, everything that
worked for me on the XP side. Yet I still get the same error when I
try and attach to a remote server.
I have not tried disabling the Firewall (it's locked by a Group Policy
and I am still trying to figure out how to disable it without causing
my PC to explode). I do, however, have UAC disabled, and I am not
sure if that makes a difference or not.
The weird thing is that when I cleared all of the firewall exceptions
manually and then tried to automatically change them via the "unblock
remote debugging" option, I got the usual "cannot add a port" error,
but when I went to the Firewall settings, I found that the ports had,
in fact, been successfully added. That was weird.
Does anybody have any ideas on where to go next? It's frustrating as
hell knowing the remote end (usually the hardest part) is working
fine, but I can't get out of my own box. The on-ramp to the highway
is clear, but I'm locked in my garage, so to speak. Thanks for
anybody's help!