[6.6.0003.5] Smart client support (-premote) is broken in various ways.

[Skywing]

There are two problems here...

1) Smart clients don't work at all on Windows 2000.

I've so far been unable to get 6.6.3.5's smart client support
(either -premote or file->Connect to Remote Stub) to work on win2k - I
always get "can't connect to process server" returned. This is regardless
of whether the dbgsrv is on localhost or not. I've tried both npipe and tcp
transports to no avail.

It should be noted that the exact same settings (dbgsrv -t
tcp:port=<port>,password=<password> and windbg -premote
tcp:server=<ip>,port=<port>,password=<password>) work on XP and 2003.

I'm sure that I've used this before in previous versions (6.3?) of WinDbg.
The reason I'm using it on win2k is to do cross session debugging of a
service over terminal server - the old "start dbgsrv on the console session
using at.exe and connect to it on localhost using windbg over terminal
server" trick. I've been unable to get this to work even running as the
same user, and thus far I've ran into this problem on every win2k box I've
tried. FWIW, the computers in question have all happened to be domain
controllers.

It look like this is really a problem with the debug server smart client
(-premote support) in WinDbg and not a problem with dbgsrv.exe. For
instance, I can't connect to a dbgsrv.exe running on XP from the win2k
machine, but I can connect to a dbgsrv.exe running on win2k from an XP
machine (even though the win2k machine can't connect to it).

2) Reverse connection mode for DbgSrv.exe is broken for tcp transport.

I can't get reverse connections (clicon) to work at all. Specifically, I
can't get dbgsrv.exe to even try and open a connection to a smart client.
I've tried starting windbg in client connection mode with either -premote or
File>Connect to Remote Stub, and neither work. The command line is
something like this:
"tcp:clicon=<ip-on-local-machine>,port=<port>,password=<password>". This is
not a firewall problem, and I've verified through netstat that WinDbg really
does listen on the port I've specified. If I try to telnet to this port
from a remote machine and then abort the connection, the WinDbg UI wakes up
from being hung at the "attach process" dialog and says there was an error
connecting to the process server. So it would seem that here, the problem
is with dbgsrv.exe and not windbg itself.

Now, if I try to start dbgsrv.exe in clicon on a XP machine, dbgsrv starts
without complain but doesn't even try to connect to WinDbg. If I try to
start dbgsrv.exe in clicon mode on a win2k machine, it dies with a message
box that says StartProcessServer failed with
HRESULT_FROM_WIN32(ERROR_INVALID_PARAMETER).

[Skywing]

Incidentally, I am also unable to get clicon to work on win2k when using
ntsd -server with the tcp transport (same command line works for XP).

For instance, if I do (on XP):

E:\Program Files\Debugging Tools for Windows>ntsd -remote
tcp:port=7000,clicon=127.0.0.1,password=mypass

E:\Program Files\Debugging Tools for Windows>ntsd -server
tcp:port=7000,clicon=127.0.0.1,password=mypass -p 7764

Then everything works.

However, given the exact same command lines (for 6.6.3.5) on win2k, both
ntsd instances die.

C:\Program Files\Debugging Tools for Windows>ntsd -remote
tcp:port=7000,clicon=127.0.0.1,password=mypass

DebugConnect failed, Win32 error 87
"The parameter is incorrect."
ntsd: exiting - press enter ---

C:\Program Files\Debugging Tools for Windows>ntsd -server
tcp:port=7000,clicon=127.0.0.1,password=mypass -p 1700

StartServer failed, Win32 error 87
"The parameter is incorrect."
ntsd: exiting - press enter ---

As far as I can tell, the only scenarios that *DO* work for remote debugging
on win2k using 6.6.3.5 are:

* -premote with dbgsrv running in server mode (no clicon) on win2k, and
smart client on a different computer (XP or later)
* -server (no clicon) on win2k, and -remote client on either the same win2k
machine or a different machine (also works on XP).
* (possibly) remote.exe, haven't tried that yet.

"Skywing" <skywing_...@valhallalegends.com> wrote in message
news:%23eSVr%23dJGH...@TK2MSFTNGP12.phx.gbl...

[Drew Bliss [MSFT]]

We only do minimal testing on Win2K, we'll go back and try to repro this.
Nothing in the debugger's net code is OS-specific. It does require Winsock
2.0 but that isn't new.

I just tried clicon and dbgsrv on XP and it worked fine.

"Skywing" <skywing_...@valhallalegends.com> wrote in message

news:OHywSmeJ...@TK2MSFTNGP11.phx.gbl...

[Jochen Kalmbach [MVP]]

Hi Drew!

> We only do minimal testing on Win2K

Is this really true????
Why the heck do you release a new minimal tested version?

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Drew Bliss [MSFT]]

The new version is fully tested, just not on all OS versions. The full test
matrix is just too large. Our test team is two people. We don't have the
resources to do full test passes on NT 4 and Win2K. We don't support Win9x
even though the debuggers mostly work because again we don't have the
resources to support it.

It would be great if we had a team that was much larger so that we could do
more feature work and more test work, but we don't and we have to make
choices about where to spend our time.

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message
news:%23Lps362...@TK2MSFTNGP11.phx.gbl...

[Skywing]

Out of curiousity, what were the exact parameters you used for this case (in
XP with -premote)?

"Drew Bliss [MSFT]" <dr...@online.microsoft.com> wrote in message
news:O7FSDy2J...@TK2MSFTNGP11.phx.gbl...

[Drew Bliss [MSFT]]

First

start cdb -premote tcp:port=1234,clicon=drewb20 notepad.exe

Then

dbgsrv -t tcp:port=1234,clicon=drewb20

Upon starting dbgsrv, cdb becomes active and runs to the initial break for
notepad.exe.

"Skywing" <skywing_...@valhallalegends.com> wrote in message

news:uV1lcF3J...@TK2MSFTNGP09.phx.gbl...

[Drew Bliss [MSFT]]

That reminds me of something I should have mentioned before: windbg needs to
make multiple connections to the dumb server, which can be problematic for
clicon. If things work for you with cdb that may be the issue.
Unfortunately there isn't anything simple that can be done about it.

"Skywing" <skywing_...@valhallalegends.com> wrote in message

news:uV1lcF3J...@TK2MSFTNGP09.phx.gbl...

[Jochen Kalmbach [MVP]]

Hi Drew!

> We don't have the
> resources to do full test passes on NT 4 and Win2K. We don't support Win9x
> even though the debuggers mostly work because again we don't have the
> resources to support it.

NT4 and W95 is currently not a supported OS from Microsoft, so this does
not matter. All currently OSes should be supported and tested!

> It would be great if we had a team that was much larger so that we could do
> more feature work and more test work, but we don't and we have to make
> choices about where to spend our time.

If you need some votes, I will vote for it!

(See my other post regadring a bug in the new dbghelp.dll)

[Skywing]

That worked for me. It works for WinDbg too, fwiw.

Btw, I figured out what the problem was for me with dbgsrv on XP: if you
don't have 'port=' as the first argument in the connection string, the whole
process fails. So apparently the argument order matters, but only for
'port='. Incidentally, debugger.chm examples use clicon= instead of port=
first, and if you do that then it breaks - so if you follow the
documentation and don't know not to use port= first, you're hosed. I assume
this is probably a bug...

To give some examples:

These don't work (hangs forever waiting for a dbgsrv connection):

E:\Program Files\Debugging Tools for Windows>start cdb -premote
tcp:clicon=127.0.0.1,port=1234,password=test calc.exe

E:\Program Files\Debugging Tools for Windows>dbgsrv -t
tcp:clicon=127.0.0.1,port=1234,password=test

But these work fine:

E:\Program Files\Debugging Tools for Windows>start cdb -premote
tcp:port=1234,clicon=127.0.0.1,password=test calc.exe

E:\Program Files\Debugging Tools for Windows>dbgsrv -t
tcp:port=1234,clicon=127.0.0.1,password=test

The same seems to be true for iterations of ntsd and WinDbg too.

"Drew Bliss [MSFT]" <dr...@online.microsoft.com> wrote in message

news:uHURQT3J...@TK2MSFTNGP11.phx.gbl...

[Drew Bliss [MSFT]]

NT 4 and versions of Win9x (not Win95, but Win98, Win98 SE WinME) are still
used.

We don't have the resources to test everything on all versions of Windows.
Unfortunately it isn't a matter of voting, it's just the way it is.

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message

news:ughjtX3...@TK2MSFTNGP14.phx.gbl...

[Jochen Kalmbach [MVP]]

Hi Drew!

> Unfortunately it isn't a matter of voting, it's just the way it is.

I think it is a matter of resources... and also a matter if you want to
release a "Debugging Tools for Windows" as beta versions... (thats at
least my perspective after some troubles with dbgehlp.dll in the last
two versions)

[Drew Bliss [MSFT]]

I can repro the problem with port= ordering, we'll fix it in the next drop.

"Skywing" <skywing_...@valhallalegends.com> wrote in message

news:uQdvBn3J...@TK2MSFTNGP15.phx.gbl...

[Skywing]

Great! Thanks for the quick response on both problems, btw. It's highly
appreciated :)

"Drew Bliss [MSFT]" <dr...@online.microsoft.com> wrote in message

news:e$ZJ8s3JG...@TK2MSFTNGP12.phx.gbl...

[Drew Bliss [MSFT]]

6.6.03 is a beta release.

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message

news:O5pZir3...@TK2MSFTNGP10.phx.gbl...

[Jochen Kalmbach [MVP]]

Hi Drew!

> 6.6.03 is a beta release.

But it is not marked as a beta, is it?

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Quote: "Current Release version 6.6.3.5 - January 24, 2006"

[Drew Bliss [MSFT]]

You're right, it appears that the people that wrote the web pages didn't
explicitly say it was a beta. The release notes that come with it should
indicate it's a beta, is there a relnotes.txt in your install?

Our usual pattern is to do a beta and then a final release every six to nine
months. 6.6.03 is the beta for 6.6, there'll be a 6.6 final release in
three or four months (just guessing, we don't have any firm dates right
now).

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message

news:%23Bti533...@TK2MSFTNGP10.phx.gbl...

[Jochen Kalmbach [MVP]]

Hi Drew!

> You're right, it appears that the people that wrote the web pages didn't
> explicitly say it was a beta. The release notes that come with it should
> indicate it's a beta, is there a relnotes.txt in your install?

Yes. And it says:
<quote>
This release of Debugging Tools for Windows contains many bug fixes and
new enhancements. The debuggers are stable and more reliable than
previous releases and we recommend that you upgrade to this version.
</quote>

A search for "beta" does not find anything...

> Our usual pattern is to do a beta and then a final release every six to nine
> months. 6.6.03 is the beta for 6.6, there'll be a 6.6 final release in
> three or four months (just guessing, we don't have any firm dates right
> now).

Hmmmm... so you should mark it asap as beta on the download page...

Thanks for this info!

[Drew Bliss [MSFT]]

I took a look and it appears we only mention that it's in a beta in
redist.txt.

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message

news:%23dKMQ$3JGHA...@TK2MSFTNGP15.phx.gbl...