Remote debugging broken on WinXP Pro SP2



I've run across an unusual remote debugging problem...

I've got 2 virtual machines running under VMware Workstation v5.5, one is WinXP Pro SP2 and the other is Win2K3 SP1. Both are configured for host-only networking and both can communicate with the WinXP Pro SP2 installation that VMware is on [e.g. on my laptop]. On my laptop, I have Visual Studio .NET 2003 installed, and I have a simple Win32 DLL project built.

Both virtual machines have the remote debug client installed [MSVCMON], which is being run with the "-tcpip -timeout -1 -anyuser" switches. I'm using the Visual C/C++ IDE and have it configured for "native only" debugging via TCP/IP.

With the Win2K3 SP1 VM, I can perform remote debugging w/o any problems.

With the WinXP Pro SP2 VM, I cannot get the Visual C/C++ IDE to connect to the remote debug agent. I see the debug agent startup in a console window and the last message it gives is "Waiting for Connections - everyone is allowed access". When I attempt to make my debug connection to this system, the IDE reports back an error in a messagebox:

"Unable to start debugging."
"Unable to start program '...'."
"MSVCMON is either not running on the remote machine or is running in pipe mode."

I can see in the MSVCMON console window that my incoming debug connection was at least attempted, with a line being displayed stating "A Debug session has been started for user: <my username>".

I've tried making a Telnet connection to port 2064 and I can connect successfully on both of the virtual machines.

It appears that the remote debugger agent is in fact present and is able to receive an incoming connection from my debug client on the laptop. AFAIK, the Windows Firewall is completely disabled & turned-off on both the WinXP Pro SP2 VM, the Win2K3 SP1 VM and on my WinXP SP2 host system. In fact, both of the virtual machines are running the exact same copy of MSVCMON from a network share, and I've also tried copying it local to each VM and running it locally on them and I still get the same results.


After doing some Google searches and MS KB article searches, I'm not coming up with anything beyond making sure that there's no firewalls intervening between the debug client and the remote debug agent.

Any ideas what might be going on?


TIA,

Chuck
--
Chuck Chopp

ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
103 Autumn Hill Road 864 801 2774 fax
Greer, SC 29651

"Racing to save lives"
The Leukemia & Lymphoma Society - Team in Training
http://www.active.com/donate/tntsc/tntscCChopp

Do not send me unsolicited commercial email.
.



Relevant Pages

  • Re: have way to debug Service in remote machine?
    ... TCP-IP mode is not a secure way to debug your application. ... To use the default port you will need to install the full set of remote ... Remote Machine= Remote Machine IP ... > For remote debugging using TCP/IP, you need to install the Remote Debug ...
    (microsoft.public.vc.debugger)
  • Return argument has an invalid type - does remoting work reliably at all?
    ... > remote object, ... > remote object returns (I can debug to that point. ... "Advanced .Net Remoting" by Ingo Rammer, his website, msdn, articles on ... .Net Remoting is really a pain to work with. ...
    (microsoft.public.dotnet.framework.remoting)
  • RE: Assembly reported as built without debug info - that is not true
    ... enabled or without debug information:..." ... successfully remote debug any other assembly which is not in the GAC? ... in the Modules window's loading assemblies' list, ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.framework)
  • Re: XP SP2 and Remote Debugging
    ... DCOM, XP SP2, and Remote Debugging ... granted both local and remote permissions in Edit Limits. ...
    (microsoft.public.vsnet.debugging)
  • Re: XP SP2 and Remote Debugging
    ... DCOM, XP SP2, and Remote Debugging ... granted both local and remote permissions in Edit Limits. ...
    (microsoft.public.vsnet.debugging)