Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RPC_S_SERVER_TOO_BUSY - why?

341 views
Skip to first unread message

ed.gar

unread,
Mar 9, 2012, 7:25:57 AM3/9/12
to
Hi,

It's very rare, but from time to time, customers are reporting problems with
RPC_S_SERVER_TOO_BUSY error.

I was asking about this some time ago: I have an RPC application, the server
and client. The application works fine on WinXP, 7 and Vista, but one of our
customers reports that client app fails to connect due to error 1723 -
RPC_S_SERVER_TOO_BUSY. This is the first connection from client app to
server app. There are no other connections.

I was able to determine that following methods works fine:

RpcStringBindingCompose
RpcBindingFromStringBinding
RpcMgmtInqServerPrincName
RpcBindingSetAuthInfo

The problem is on first remote call:

RpcTryExcept
{
RemoteCall
}
RpcExcept(1)
{
DWORD err = RpcExceptionCode();
}

RpcExceptionCode is 1723.

In the example above, the client was Windows Vista (TM) Ultimate, Service
Pack 2, the server Windows XP, but it happens on other scenarios too.

I wasn't able to find any solution, except for "Restore System" and
"Download and save Rpc_s_server_too_busy fix application.". I don't know
what that application do, so I'd rather not recommend it to customers. Do
you know what Rpc_s_server_too_busy fix application do?

Thanks,
Ed.


Deanna Earley

unread,
Mar 9, 2012, 7:38:07 AM3/9/12
to
On 09/03/2012 12:25, ed.gar wrote:
> Hi,
>
<SNIP>
> I wasn't able to find any solution, except for "Restore System" and
> "Download and save Rpc_s_server_too_busy fix application.". I don't know
> what that application do, so I'd rather not recommend it to customers. Do
> you know what Rpc_s_server_too_busy fix application do?

I have no idea about the RPC error (apart from it being too busy?) but
the vast majority (100%?) of the sites that claim to "Fix XYZ error" are
scam wildcard sites and can also offer to fix your radiator, dog, or
even your next door neighbour with the correct search terms.

The best destination to find out about the problem is the MSDN article
for the error itself.

--
Deanna Earley (dee.e...@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

ed.gar

unread,
Mar 9, 2012, 7:56:51 AM3/9/12
to
You're right, you don't know what RPC is. And your "answer" doesn't make any
sense.



Użytkownik "Deanna Earley" <dee.e...@icode.co.uk> napisał w wiadomości
news:jjctjd$6mh$1...@speranza.aioe.org...

Deanna Earley

unread,
Mar 9, 2012, 8:34:44 AM3/9/12
to
On 09/03/2012 12:56, ed.gar wrote:
> U¿ytkownik "Deanna Earley"<dee.e...@icode.co.uk> napisa³ w wiadomo¶ci
> news:jjctjd$6mh$1...@speranza.aioe.org...
>> On 09/03/2012 12:25, ed.gar wrote:
>>> Hi,
>>>
>> <SNIP>
>>> I wasn't able to find any solution, except for "Restore System" and
>>> "Download and save Rpc_s_server_too_busy fix application.". I don't know
>>> what that application do, so I'd rather not recommend it to customers.
>>> Do
>>> you know what Rpc_s_server_too_busy fix application do?
>>
>> I have no idea about the RPC error (apart from it being too busy?) but the
>> vast majority (100%?) of the sites that claim to "Fix XYZ error" are scam
>> wildcard sites and can also offer to fix your radiator, dog, or even your
>> next door neighbour with the correct search terms.
>
> You're right, you don't know what RPC is. And your "answer" doesn't make any
> sense.

I was commenting in reply to your question about the
"Rpc_s_server_too_busy fix application". It is most likely trojaned or a
scam as the page is based on what you search for, and nothing at all to
do with the error itself.

Does this not give you a more useful clue for debugging:
http://support.microsoft.com/kb/176734

Stefan Kuhr

unread,
Mar 9, 2012, 9:07:58 AM3/9/12
to
Hi Deanna,

On 3/9/2012 2:34 PM, Deanna Earley wrote:
><snip>
> I was commenting in reply to your question about the
> "Rpc_s_server_too_busy fix application". It is most likely trojaned or a
> scam as the page is based on what you search for, and nothing at all to
> do with the error itself.
>
> Does this not give you a more useful clue for debugging:
> http://support.microsoft.com/kb/176734
>

Wow, this is interesting, I did not know such a problem as described in
this KB article exists with ncacn_np. Ed, do you use named pipes as a
transport? If so, the article suggests what I suggested to you earlier,
IIRC, namely, retry after some time.

I have never received any such complaint for my rpc servers that use
named pipes. However, I do not use the RpcTryExcept schematics as Ed
does, but instead I always use comm_status and fault_status attributes.
I wonder if this has any influence on whether this problem can occur.

Maybe I have always been lucky so far, but now I know that I need to
handle this problem. Thanks for bringing this to my attention.

--
S


ed.gar

unread,
Mar 9, 2012, 9:14:37 AM3/9/12
to
> I was commenting in reply to your question about the
> "Rpc_s_server_too_busy fix application". It is most likely trojaned or a
> scam as the page is based on what you search for, and nothing at all to do
> with the error itself.
>
> Does this not give you a more useful clue for debugging:
> http://support.microsoft.com/kb/176734
>
> --
> Deanna Earley (dee.e...@icode.co.uk)
> i-Catcher Development Team
> http://www.icode.co.uk/icatcher/

Awesome.


ed.gar

unread,
Mar 11, 2012, 5:57:35 PM3/11/12
to
> Wow, this is interesting, I did not know such a problem as described in
> this KB article exists with ncacn_np. Ed, do you use named pipes as a
> transport? If so, the article suggests what I suggested to you earlier,
> IIRC, namely, retry after some time.
>
> I have never received any such complaint for my rpc servers that use named
> pipes. However, I do not use the RpcTryExcept schematics as Ed does, but
> instead I always use comm_status and fault_status attributes. I wonder if
> this has any influence on whether this problem can occur.
>
> Maybe I have always been lucky so far, but now I know that I need to
> handle this problem. Thanks for bringing this to my attention.

Hi Stefan,

I use TCP/IP, in fact SSL over TCP/IP. Now I think that the SSL encription
might cause problems, I was following this example:

http://us.generation-nt.com/answer/rpc-c-authn-gss-schannel-help-26886012.html

I couldn't find any example in SDK/MSDN, so maybe something is missing in
the code. google returns only 7 responses (most duplicated) for this query
"SCHANNEL_CRED RpcBindingSetAuthInfo CertFindCertificateInStore"

Only 3 out of 700 customers are reporting RPC_S_SERVER_TOO_BUSY, not much,
but I want to know what is causing problems, or at least, how to diagnose it
properly.

Thanks,
Ed.


0 new messages