有时，程序会故意或无意中隐藏RPC编组引擎中的信息。一些例子如下：
- 将数据结构作为无差别的字节块发送
- 通过使用方法的副作用在线路上引导其他数据来利用性能
- 尝试通过将其作为DWORD或ULONG传递来伪装句柄
即使在将应用程序移植到64位Windows之前，这些技术几乎可以保证引入兼容性问题。
不是在标准远程过程调用中将服务器上下文作为DWORD发送，而是使用上下文句柄为代表客户端的服务器上下文提供不透明句柄。当服务器为客户端创建上下文句柄时，上下文由RPC运行时定义的GUID标识。在线上没有使用指针，操作在32位或64位边界上完全透明。有关使用上下文句柄的更多信息，请参阅上下文句柄。
DCOM接口不能使用上下文句柄，因为COM提供了自己的上下文管理。您可以将接口指针传递给COM对象，而不是创建上下文句柄。然后，您可以直接通过接口指针调用方法，或将指针放在其他调用中。要释放服务器对象，客户端通过接口指针调用接口的Release方法。
同样，有时您可能无法更改正在移植的代码的原始设计。如果无法避免将指针作为DWORD发送到线路，则必须在DWORD值和指针之间实现某种形式的服务器端映射。一种方法是将客户端应用程序中的指针更改为指针精度类型，例如ULONG_PTR或DWORD_PTR。然后使用MIDL[call_as]属性将指针作为DWORD值放在线上。客户端包装器只需要传递参数。服务器端包装器处理两种类型之间的映射。以类似的方式，您可以使用[transmit_as]属性或[represent_as]属性将数据转换为向后兼容的格式以进行线表示。
如果向后兼容不是问题，或者句柄未用于远程调用，并且您确定永远不会发生32位和64位进程之间的远程调用，则可以将参数重新定义为ULONG64。如有必要，您可以修改32位应用程序以将DWORD传递给用户。或者，您可以使用32位Windows上的DWORD和64位Windows上的ULONG64为每个平台的单独IDL文件构建单独的存根。