Remote Debugging 
Author Message
 Remote Debugging

I've done everything MS recommends to set up remote debugging between two
identical machines on the same network.  In spite of this, the "Debug
monitor password" edit box remains grayed out and there is not way to enter
a password.  It doesn't matter
whether the Win32 Network (TCP/IP) Settings dialog is being called by VC++
or msvcome.exe, it is always grayed out.  When I attempt to connect, nothing
happens, so I assume I must solve this problem first.  My entire situation
couldn't be more vanilla, I'm just trying to debug between two NT 4
machines, my main machine and test machine on a regular corporate network.
I have shares set on both machines and each can see the other just fine.


Tue, 30 Sep 2003 02:55:48 GMT  
 Remote Debugging
The password field is permanently greyed out in 6.0, there is no password on
remote debugging in 6.0. (I think it was enabled in VC 5.0 but it was
ignored).

Ensure both machines can "ping" each other.

What error do you get on F5?


Quote:
> I've done everything MS recommends to set up remote debugging between two
> identical machines on the same network.  In spite of this, the "Debug
> monitor password" edit box remains grayed out and there is not way to
enter
> a password.  It doesn't matter
> whether the Win32 Network (TCP/IP) Settings dialog is being called by VC++
> or msvcome.exe, it is always grayed out.  When I attempt to connect,
nothing
> happens, so I assume I must solve this problem first.  My entire situation
> couldn't be more vanilla, I'm just trying to debug between two NT 4
> machines, my main machine and test machine on a regular corporate network.
> I have shares set on both machines and each can see the other just fine.



Sat, 04 Oct 2003 02:06:44 GMT  
 Remote Debugging
Thanks, for responding.  I didn't realize the password edit controls were
useless since MS has no KB's on it.  Then even think that things can go
wrong due to the password:
http://www.*-*-*.com/
alc/vccore/_core_error.3a_.the_specified_debug_password_is_incorrect.htm

For references, I'm using:
http://www.*-*-*.com/
g_remote_applications.htm
http://www.*-*-*.com/
http://www.*-*-*.com/
_.debugging.htm

I don't need to ping between my test and main developer machines, because
I'm on a corporate network and have multiple shares set up on both machines.
The machines see each other just fine.

When I hit F5, what happens is that the de{*filter*} starts, but then stops
after 15 seconds.  If I submit to the web server during this time, it catchs
the request, and the de{*filter*} never hits its breakpoint, so it is obviously
not engaged and/or not connecting.

I've been developing ISAPI dll's for a while now and I'm able to debug them
by using Attach to Process.  However, I wanted to try remote debugging, so
that I won't have to go sit in front of the eventual server when I deploy.

The MS documentation seems incomplete or incorrect for debugging ISAPI dll's
running under inetinfo.exe, when inetinfo is running on another machine.

The VC++ Debug Monitor, msvcmon.exe is set to "Network (TCP/IP)" on the
machine that is running inetinfo.exe.  The address is the (host) machine
that will debug it:  dev04.  dev04 I'm using to debug has (target) dev05 as
the address for the remote de{*filter*} connection setting.

Here are my questions:
1.
Why is msvcmone.exe so dumb?  When I hit connect, it just puts up a little
"Connecting..." dialog for the rest of the day.  This has a "Disconnect"
button on it.   Am I connected, or am I waiting forever to connect?

2.
F5 Go might be connecting okay from the de{*filter*}, but I'm not sure.  If I
use \\dev05, I get a {*filter*} message "The remote machine: '\\dev05' count not
be found.  Since I'm not getting any {*filter*} message when I'm use "dev05", do
you think I'm connected?

3.
I'm not sure the project workspace I'm using will work.  What do you think?
I began by creating a share on the dev04 target which is the inetsrv root.
I'm separtely sharing the entire build area on the target, which contains
the ISAPI dll I'd like to debug.
The project workspace I'm using on the (host) was set up by first attaching
to the local (host) inetinfo.exe process but then changing "Executable for
debug session" to point to:
 \\dev05\inetsrv\inetinfo.exe on the (target) machine.  This was the only
way to start the de{*filter*}.  The de{*filter*} won't start unless you have a
setting here.  I also have the same setting in "Remote executable path and
file name:", but if I try to use that alone, the "Executable For Debug
Session" dialog pops up anyway when I hit F5, so "Remote.."
seems to have no purpose.  To me, it's stupid to hit F5 Go to start
debugging a service, since a service is already running, albeit on another
machine.  However, obviously you can't use Attach to Process when the
process is on another machine.

It's not clear to me what the project environment should really look like
for the debug session and I'm trying to get by without copying everything
back and forth all over both machines.  I don't think it will help to bring
over the project I'm using for the actual build, even though I do have like
named directories on both machines, and can/have even built it on the host.
The point is I'm never debugging out of the project I build with ala F5.

4.
Have you seen this, and what does it mean?
Now that the project is set up as above, MSDEV blows up at 0x77f6ce4c saying
"Cannot initialize the debugging subsystem."  This appears to happen as soon
as it shakes hands with msvcmon.exe, which is terminated without a trace on
the target. The msvcmone.exe is version 6.00.8168.0 from 6/16/98.  I suppose
I'll have to get happy applying service packs to try to work through that.
Both machines are fairly clean, and nearly identical.

Thanks.



Quote:
> The password field is permanently greyed out in 6.0, there is no password
on
> remote debugging in 6.0. (I think it was enabled in VC 5.0 but it was
> ignored).

> Ensure both machines can "ping" each other.

> What error do you get on F5?



> > I've done everything MS recommends to set up remote debugging between
two
> > identical machines on the same network.  In spite of this, the "Debug
> > monitor password" edit box remains grayed out and there is not way to
> enter
> > a password.  It doesn't matter
> > whether the Win32 Network (TCP/IP) Settings dialog is being called by
VC++
> > or msvcome.exe, it is always grayed out.  When I attempt to connect,
> nothing
> > happens, so I assume I must solve this problem first.  My entire
situation
> > couldn't be more vanilla, I'm just trying to debug between two NT 4
> > machines, my main machine and test machine on a regular corporate
network.
> > I have shares set on both machines and each can see the other just fine.



Sat, 04 Oct 2003 07:07:46 GMT  
 Remote Debugging
1. You DO need to be able to ping between the two machines - if ping fails,
then so will msvcmon as it uses sockets too.

2. I am a little rusty on 6.0, but "Connecting" means "trying to find
msvcmon" I think. Disconnect means "give up". Do NOT use \\ on the front, we
use the sockets API not fileshare APIs so put the pingable machine name in
(e.g. "dev05").

3. It *is* stupid to use F5 to start a service, true enough, you cannot
remotely debug a service using 6.0 for this reason. You can with 7.0 as you
can remote attach either via the UI or on a project's F5.

4. I would recommend all SPs as we did fix a number of remote debugging
issues in at least one of them.

Hope this lot helps. Remote debugging is tricky in 6.0, thats why we were so
pleased when we fixed 95% of the madness in 7.0.



Sun, 05 Oct 2003 08:00:34 GMT  
 Remote Debugging
Okay, msvcmon.exe and remote debugging now tries to work, since I applied VC
sp5 and  then
VC SP4 redistributibles zip file, which VC sp5 didn't update.

I now get to see that you can't debug a service using VC++ 6.0.  What
happens is the same thing that happens if you hit F5 locally against a
service - the service control manager shuts down the service after 15
seconds.

This means that:
http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_i...
_.debugging.htm
which documents remote debugging of ISAPI dlls is rubbish, which is typical.

Thanks for coming out with the truth.



Quote:
> 1. You DO need to be able to ping between the two machines - if ping
fails,
> then so will msvcmon as it uses sockets too.

> 2. I am a little rusty on 6.0, but "Connecting" means "trying to find
> msvcmon" I think. Disconnect means "give up". Do NOT use \\ on the front,
we
> use the sockets API not fileshare APIs so put the pingable machine name in
> (e.g. "dev05").

> 3. It *is* stupid to use F5 to start a service, true enough, you cannot
> remotely debug a service using 6.0 for this reason. You can with 7.0 as
you
> can remote attach either via the UI or on a project's F5.

> 4. I would recommend all SPs as we did fix a number of remote debugging
> issues in at least one of them.

> Hope this lot helps. Remote debugging is tricky in 6.0, thats why we were
so
> pleased when we fixed 95% of the madness in 7.0.



Mon, 06 Oct 2003 01:36:09 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Remote debug

2. Remote debugging problem on managed C++ application.

3. Remote Debugging

4. remote debugging with visual studio .net

5. Rich-Error info lost on Attributed ATL project in remote debug config (again)

6. Borland Remote Debugging

7. How can I disable remote debugging with MSVC?

8. Remote Debugging

9. remote debugging a dos program

10. Cannot remote debug COM+ server app

11. Remote debugging COM component with DLLHOST.EXE /ProcessID

12. Remote debugging COM component with DLLHOST.EXE /ProcessID

 

 
Powered by phpBB® Forum Software