RPC Call Returns an Incrementing Value Instead of ULONG_PTR

Question

I'm relatively new to RPC code, so my apologies if this is trivial.

I'm writing an RPC function that calls a WINAPI function in WinSCard on the server side. The function, SCardEstablishContext, returns an LPSCARDCONTEXT handle by reference, which is ultimately just a ULONG_PTR which is an unsigned __int64 pointer. Ideally, the server RPC call should then hand this handle value back to the client that made the call

My problem is that when I do this, instead of getting an unsigned __int64 value placed at the location referenced by the pointer I passed to the RPC function, I instead get a single digit, starting with 0, which simply increments if we make subsequent calls to the RPC function.

If I eliminate the call to the WINAPI function, I can pass and set ULONG_PTR/ unsigned __int64 values without a problem, so I have no idea why instead I end up with an incremented digit on the client side.

Client Side Code

ULONG_PTR myuptr = 0;
ULONG_PTR* cpr = &myuptr;
TC_LongRetVal(cpr);
cout << "My ULONG_PTR's value is: " << *cpr << "\n";

Server Side Code

int TC_LongRetVal(ULONG_PTR* b){
    LPSCARDCONTEXT contH = b;
    SCardEstablishContext(2, NULL, NULL, contH);
    return 0 ;
}

Interface Definitation

int TC_LongRetVal([in, out] ULONG_PTR* b);

If I debug this function and walk through the server side calls, immediately before returning, the values of the LPSCARDCONTEXT "contH" and the argument pointer "b" are identical. But in this case, after returning, instead of "cpr" on the client pointing to a value "14771806......185" it points to a ULONG_PTR with a value of "0" the first time I call it. If I rerun the client code, the value of CPR increments by 1 with each successive call, until I restart the RPC server.

Is there a reason I can't seem to get the actual ULONG_PTR value back? Why does the pointer value increment by one? I know this handle means nothing to the client, but I intend to use it in later calls to the server.

Update 1 I updated the server side code to see if I could get any values back that were explicitly set. After some playing around, and a nagging feeling the the "64" portion of "unsigned __int64" had something to do with it, I finally found that if I pass back 4294967295, the largest unsigned 32 bit value, or anything less than that, the function works fine. Sending 4294967296 back, however, returns 0, and ..97 returns 1, etc.

So it looks like there's a problem with my RPC code handling a 64 bit values.

Answer 1

So it looks like the problem was little bit outside where I was originally looking.

In the IDL definitions file, I was forced to declare my own typedefs due to IDL only supporting base types. When I defined ULONG_PTR, I typed it to a __int3264 which will change between being a 32 bit or 64 bit in based on the system. While both of the systems I was testing on was 64 bit, __int3264 are truncated to 32 bits before being sent over the wire.

Changing my interface typedef of ULONG_PTR to __int64 did the trick.