[Bug 45673] New: Calling delegated proxy methods returns 0x800706b5 ( RPC_S_UNKNOWN_IF), "err:rpc: RpcAssoc_BindConnection syntax {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}, 0.0 not supported"

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=45673

            Bug ID: 45673
           Summary: Calling delegated proxy methods returns 0x800706b5
                    (RPC_S_UNKNOWN_IF), "err:rpc:RpcAssoc_BindConnection
                    syntax {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}, 0.0 not
                    supported"
           Product: Wine
           Version: 3.14
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ole32
          Assignee: wine-bugs at winehq.org
          Reporter: z.figura12 at gmail.com
      Distribution: ---

Created attachment 62097
  --> https://bugs.winehq.org/attachment.cgi?id=62097
test program

The test program demonstrates the problem fairly clearly.

In Wine, IShellBrowser delegates proxy methods to its parent IOleWindow. If you
obtain a proxy to an IShellBrowser (e.g. via ShellWindows) you can call
IShellBrowser methods without difficulty, but the RPC runtime will throw up
RPC_S_UNKNOWN_IF if you try to call IOleWindow methods:

0009:err:rpc:RpcAssoc_BindConnection syntax
{00000114-0000-0000-c000-000000000046}, 0.0 not supported
0009:fixme:ole:NdrClearOutParameters (0x61fc7c,0x7ebc63c6,0x61fdb0): stub
got 0x800706b5

(N.b. 00000144-etc. is the IID of IOleWindow.)

However, after you query for IOleWindow, calling IOleWindow methods on the
original IShellBrowser interface will succeed.

The underlying problem is this:

When an interface is marshalled by ole32, it creates a stub on the server side
and then registers that stub with rpcrt4. The interface ID that is used in
RpcServerRegisterIf() is the IID of the interface itself, in this case
IID_IShellBrowser. The stub creation functions live in rpcrt4 and end up
delegating some methods to the stub of IOleWindow, which is different (e.g. it
lives in ole32 instead of actxprxy). However, this stub never is registered
with rpcrt4.

When the program calls proxy methods, the proxy goes through ndr_client_call()
-> NdrProxyGetBuffer() -> ClientRpcChannelBuffer_GetBuffer() [in ole32/rpc.c]
-> I_RpcGetBuffer(). NdrProxyGetBuffer() passes the IID of the proxied
interface to IRpcChannelBuffer_GetBuffer(), and that interface is eventually
used by rpcrt4 as the ifid for the transaction. When that interface is
IID_IShellBrowser, the server will recognize it, and the transaction works
fine.

However, when the program calls IOleWindow proxy methods, the proxy object is
'swapped out' (by the assembly thunks in fill_delegated_proxy_table()) and so
the IID that NdrProxyGetBuffer() passes is the IID of the *parent* interface.
Since this interface was never registered with RPC on the server side, the
server refuses connection ("syntax not supported") and the proxy call fails.

As a corollary, if you query that parent interface—even if you then throw away
the resulting proxy—it will have been registered on the server side, and so
calls to the delegated methods on the original object will miraculously start
to succeed.


I don't know what the correct way is to solve this problem. As far as I
understand it's not something that can be tested—all of this is quite deep
inside of OLE/RPC implementation details. It doesn't seem like there's any
appropriate place to tell OLE about the delegated stub, at least not given the
current infrastructure, and I'm not sure how RPC could appropriately inform OLE
about the stub location. On the other hand I'd guess that maybe the child IID
(i.e. IID_IShellBrowser) should be passed somewhere along the line on the
client side; i.e. the standard proxy implementation should store the original
IID inside the delegated proxy, and that original IID should be used by
NdrProxyGetBuffer().

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.