Wow! What timing. I was just preparing a message on this very topic when I
read this thread. I am having the same problem and the client and server
machines are ALWAYS Win2k.

My symptoms are as follows:

My client app is sometimes getting an E_OUTOFMEMORY error when it calls a
custom Advise method on a remote object. I am not savvy on NetMon, but I
do know the call never gets into the server Advise method. The scenario is
like this:

Remote Server A implements ObjA with custom interface IObjA and method
IObjA::Advise([in] IStream* pStream, [in] ICallback* pCallback)
where pStream is an IStream created by the client, and pCallback is a sink
interface implemented by the client app.

Client Machine B has process which calls
CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE,
RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL);
at startup.
It then creates an ObjA object on the remote server.
It then calls IObjA::Advise and that is where I SOMETIMES get an
E_OUTOFMEMORY error. Odd thing is that it doesn't happen for all users and
it doesn't happen all the time. Currently, both Client and Server machines
are Win2k.

I read Keith Brown's FAQ that references a problem like this, and the
solution suggests that SYSTEM be granted Access permission to the server. (I
assume in this case, it means SYSTEM be granted access permission to the
client process?) I did that on the server machine using DCOMCNFG, but on the
client machine, the client process is not a DCOM server. It is an MFC app
that loads an in-proc COM server that implements the callback. I was not
sure how I could make sure that SYSTEM had access to the callback object,
but I did add SYSTEM to the system-wide default access permissions via
DCOMCNFG. This had no effect on the result.

Other tidbits are that the server process is running as a distinguished
user, but it is a local account. I don't know if that has any significance
here.

I hope to find a resolution to this soon, because it sure is annoying the
hell out of our Beta users. I had never seen this during development, and
even now, it occurs on only a few machines, and not 100% of the time.

Thanks to this list, at least I know I'm not alone in this misery...
Peter

-----Original Message-----
From: Distributed COM-Based Code [mailto:DCOMDISCUSS.MICROSOFT.COM]On
Behalf Of Steve Swartz
Sent: Friday, April 20, 2001 3:54 PM
To: DCOMDISCUSS.MICROSOFT.COM
Subject: Re: Implementation of callback causing problems on Windows98
machines only

A guy in PSS (Riyaz Pishori) helped me find a bug which may be causing
the behavior that's been reported on this thread. If you have a netmon
capture of the failure, compare you trace with what follows. If they
match up, and if the key is RPC bind with non zero assoc group followed
by a bind NAC, then you're probably experiencing an RPC bug (17553 in
the WinSE database, if you deal with PSS folks). There's a hotfix
available through PSS (Q278046). Examination of the RPC packets reveals
that the server attempts to issue an RPC Bind to the client for the
interface being passed from client to server. The client responds with
an RPC Bind NACK. This causes the original RPC request to the server to
be returned as an RPC fault with status 0x8007000E.

The packets would look something like this:

Client -> Server : MSRPC: c/o RPC Request: call 0x5 opnum 0x6 context
0x1 hint 0x1BE
Server -> Client : MSRPC: c/o RPC Bind: UUID
12341234-1234-1234-1234-123412341234 call 0x5 assoc grp 0xA731 xmit
0x16D0 recv 0x16D0
Client -> Server : MSRPC: c/o RPC Bind Nak: call 0x5 reject reason
(Reason not specified)
Server -> Client : MSRPC: c/o RPC Fault: call 0x5 context 0x1 status
0x8007000E cancels 0x0

Or, if you've been seeing these E_OUTOFMEMORY failures against your
server, you might want to just try downloading and installing the fix.
The KB for this is still being built. The fix will be included in
Windows 2000 SP3.

One other thing. I'm not at all sure but that some of the issues raised
on this thread were other problems (especially the ones that claimed to
reproduce exclusively on dcom98 clients).

----------------------------------------------------------------
Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://msdn.microsoft.com/workshop/essentials/mail.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]