RPC_S_INVALID_BINDING in client

[Shawn Fessenden]

I've got a problem in an RPC client. Any server method invocation fails with
RPC_S_INVALID_BINDING. Both RpcStringBindingCompose and
RpcBindingFromStringBinding succeed. The protocol is tcp (ncacn_ip_tcp) on
port 1054. I've tried several different protocol sequences with the same
result.

I found a reference on a DEC site that gives a little more info than just
"The binding handle is invalid": RPC Protocol ID in binding handle was
invalid. Well, it looks ok to me in it's string form:

569f2117-297a-4c65-afaf-***@ncacn_ip_tcp:\\\\PIII733[1054]

The server shown is the localhost. So can anybody shed some light on just
where I should start looking for problems?

Additional info: environment is Windows 2000 Pro, MSVC++ 6 SP3 using SDK
MIDL & RPC includes. Server must eventually run on everything from Windows
95 to Server 2003. Should I switch to pure VC? Is rpcrt4.lib hassling me
because of differences between MSVC & SDK? SDK libraries are included &
linked first anyway. Server and client are both standard MFC dialog apps.
Server uses:

status = RpcServerRegisterIfEx(ISnapRemote_v1_0_s_ifspec,
NULL, NULL, RPC_IF_AUTOLISTEN, cMaxCalls, NULL);
status = RpcServerListen(cMinCalls, cMaxCalls, TRUE);

(both succeed)

[Gianluca Braccini]

Can you set on server side: RpcServerUseAllProtseqs() or
RpcServerUseProtseqEp() ?

Gianluca

Post by Shawn Fessenden
I've got a problem in an RPC client. Any server method invocation fails with
RPC_S_INVALID_BINDING. Both RpcStringBindingCompose and
RpcBindingFromStringBinding succeed. The protocol is tcp (ncacn_ip_tcp) on
port 1054. I've tried several different protocol sequences with the same
result.
I found a reference on a DEC site that gives a little more info than just
"The binding handle is invalid": RPC Protocol ID in binding handle was
The server shown is the localhost. So can anybody shed some light on just
where I should start looking for problems?
Additional info: environment is Windows 2000 Pro, MSVC++ 6 SP3 using SDK
MIDL & RPC includes. Server must eventually run on everything from Windows
95 to Server 2003. Should I switch to pure VC? Is rpcrt4.lib hassling me
because of differences between MSVC & SDK? SDK libraries are included &
linked first anyway. Server and client are both standard MFC dialog apps.
status = RpcServerRegisterIfEx(ISnapRemote_v1_0_s_ifspec,
NULL, NULL, RPC_IF_AUTOLISTEN, cMaxCalls, NULL);
status = RpcServerListen(cMinCalls, cMaxCalls, TRUE);
(both succeed)
--
-SHAWN-

[Shawn Fessenden]

Post by Gianluca Braccini
Can you set on server side: RpcServerUseAllProtseqs() or
RpcServerUseProtseqEp() ?

Hi Granular. Yes, I'm using Protested:

// Start the remoting interface.
RPC_STATUS;
unsigned char pProtseq[] = "ncacn_ip_tcp";
unsigned char pEndpoint[] = "1054";
unsigned int cMinCalls = 1;
unsigned int cMaxCalls = 4;

status = RpcServerUseProtseqEp(pProtseq, cMaxCalls, pEndpoint, NULL);
if(status) AfxMessageBox("RpcServerUseProtseqEp failed");
status = RpcServerRegisterIfEx(ISnapRemote_v1_0_s_ifspec,
NULL, NULL, RPC_IF_AUTOLISTEN, cMaxCalls, NULL);
if(status) AfxMessageBox("RpcServerRegisterIfEx failed");
status = RpcServerListen(cMinCalls, cMaxCalls, TRUE);
if(status) AfxMessageBox("RpcServerListen failed");

In the mean time I've switched back to using all VC++, recompiling the .idl
with MIDL 5 & eliminating all SDK references & linkage. I thought that would
help, but I still get the same thing. No matter what transport I try to use.
At least the problem hasn't changed.

I dealt with this once a few years ago and didn't have this problem but
unfortunately I don't have the code any more. It was basically the same
thing. An MFC dialog on both ends.
--
-SHAWN-

[Shawn Fessenden]

Further info:

The latest documentation states that RpcServerRegisterIfEx (on the server
side) *REQUIRES* a server version of Windows, yet the call succeeds! What's
this all about? Does that mean I can't use an auto-listen interface? That
kinda blows. That means I'll have to put the call to RpcServerListen in a
separate thread - so's my dialog can draw & function.

And speaking of RpcServerListen, the dox also say that if I'm using an
auto-listen interface then I don't have to call listen! Jebus. Is there just
a simple tutorial somewhere on using MS RPC? So far the one I'm using (the
SDK RPC tutorial) has been wrong on all points - and *it* doesn't work
either.

And there's all this stuff about registering endpoint vectors & crap. All I
want to do is remote a few simple functions. I don't really care what RPC
does, as long as it does it right. Could somebody just give me a basic
overview for the following requirements:

The server will run on any version of Windows (using Win32). The server is a
dialog that displays status information - remote function name, last hit
time and number of hits. I could care less what transport is used. TCP/IP is
common to all servers. If I have to specify a port, ok but I would rather
let it float.

The client initially is a simple dialog that allows calling all functions on
any server for testing purposes. The client's final form is a php extension.
It will run on Windows 2000 Pro but should be compatible with XP / Server
2003 and whatever future versions of NT that MS cooks up, with the exception
that I don't plan on doing that Longhorn stuff.
-SHAWN-

[Shawn Fessenden]

More further info:

I have since blown off the auto-listen interface and created a server
application that is bare bones. It's a console app that simply registers a
protocol sequence, registers the interface and calls listen. The client has
the same problem. Here is the server (minus method implementation):

void main(void) {

// Start the remoting interface.
RPC_STATUS status;
unsigned char pProtSeq[] = "ncacn_ip_tcp";
unsigned char pEndpoint[] = "1054";

status = RpcServerUseProtseqEp(pProtSeq, RPC_C_LISTEN_MAX_CALLS_DEFAULT,
pEndpoint, NULL);
if(status) {
printf("RpcServerUseProtseqEp failed");
return;
}

status = RpcServerRegisterIf(ISnapRemote_v1_0_s_ifspec, NULL, NULL);
if(status) {
printf("RpcServerRegisterIf failed");
return;
}

status = RpcServerListen(1, RPC_C_LISTEN_MAX_CALLS_DEFAULT, FALSE);
if(status) {
printf("RpcServerListen failed");
return;
}
}

You can't get much barer than that. All calls succeed. The server *is*
listening. The problem has to be the client. It calls
RpcStringBindingCompose with the UUID of the interface, transport and port,
then RpcBindingFromStringBinding. The binding returned is apparently bogus.
Why? It's as simple as all get-out.
-SHAWN-

[Gianluca Braccini]

Are you using:
RpcEpResolveBinding() on the client side ?

Gianluca

Post by Shawn Fessenden
I've got a problem in an RPC client. Any server method invocation fails with
RPC_S_INVALID_BINDING. Both RpcStringBindingCompose and
RpcBindingFromStringBinding succeed. The protocol is tcp (ncacn_ip_tcp) on
port 1054. I've tried several different protocol sequences with the same
result.
I found a reference on a DEC site that gives a little more info than just
"The binding handle is invalid": RPC Protocol ID in binding handle was
The server shown is the localhost. So can anybody shed some light on just
where I should start looking for problems?
Additional info: environment is Windows 2000 Pro, MSVC++ 6 SP3 using SDK
MIDL & RPC includes. Server must eventually run on everything from Windows
95 to Server 2003. Should I switch to pure VC? Is rpcrt4.lib hassling me
because of differences between MSVC & SDK? SDK libraries are included &
linked first anyway. Server and client are both standard MFC dialog apps.
status = RpcServerRegisterIfEx(ISnapRemote_v1_0_s_ifspec,
NULL, NULL, RPC_IF_AUTOLISTEN, cMaxCalls, NULL);
status = RpcServerListen(cMinCalls, cMaxCalls, TRUE);
(both succeed)
--
-SHAWN-

[Shawn Fessenden]

Post by Gianluca Braccini
RpcEpResolveBinding() on the client side ?

No. So I added it. And it returns RPC_S_INVALID_BINDING.

[Shawn Fessenden]

Post by Shawn Fessenden
No. So I added it. And it returns RPC_S_INVALID_BINDING.

Correction - that call succeeds. But the client still throws an invalid
binding exception.

[Shawn Fessenden]

NEW FURTHER INFO:

Ok, so I went back through the tutorial code very carefully, and I found
that it was using hello_IfHandle. I didn't see this in the tut code
anywhere, so I declared RPC_IF_HANDLE ifHandle and used that.

This was wrong. Massively wrong. It's declared in the MIDL generated code.
When I used that handle, everything worked out ok.

I still have problems, but I think I can take it from here. The interface is
now making remote calls just fine. I have to specify servers by their IP and
I have some memory issues, but I can handle that.

Thank you Gianluca Braccini for your help. Viva Italia!
-SHAWN-

[duncan]

Shawn Fessenden wrote on 02/26/2005 03:23 ET

Post by Shawn Fessenden
I've got a problem in an RPC client. Any server method invocation fails wit
RPC_S_INVALID_BINDING. Both RpcStringBindingCompose an
RpcBindingFromStringBinding succeed. The protocol is tcp (ncacn_ip_tcp) o
port 1054. I've tried several different protocol sequences with the sam
result
I found a reference on a DEC site that gives a little more info than jus
"The binding handle is invalid": RPC Protocol ID in binding handl
wa
invalid. Well, it looks ok to me in it's string form
:\PIII733[1054
The server shown is the localhost. So can anybody shed some light on jus
where I should start looking for problems
Additional info: environment is Windows 2000 Pro, MSVC++ 6 SP3 using SD
MIDL & RPC includes. Server must eventually run on everything from Window
95 to Server 2003. Should I switch to pure VC? Is rpcrt4.lib hassling m
because of differences between MSVC & SDK? SDK libraries are included
linked first anyway. Server and client are both standard MFC dialog apps
Server uses
status = RpcServerRegisterIfEx(ISnapRemote_v1_0_s_ifspec
NULL, NULL, RPC_IF_AUTOLISTEN, cMaxCalls, NULL)
status = RpcServerListen(cMinCalls, cMaxCalls, TRUE)
(both succeed
-SHAWN

In case any other poor fool experiences this issue and manages to stumbl
acros
this thread. The problem is likely you are including both of the mid
generate
stub files (xxxx_s.c, xxxx_c.c) in your server code. It confuses it as t
wha
implementation it should be using for your remote call... and for whateve
reason inexplicable chooses to toss out the invalid handle nonsense

Good luck!