7 Appendix B: Product Behavior

Article
09/01/2021

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

Windows NT operating system
Windows 2000 operating system
Windows XP operating system
Windows Server 2003 operating system
Windows Vista operating system
Windows Server 2008 operating system
Windows 7 operating system
Windows Server 2008 R2 operating system
Windows 8 operating system
Windows Server 2012 operating system
Windows 8.1 operating system
Windows Server 2012 R2 operating system
Windows 10 operating system
Windows Server 2016 operating system
Windows Server operating system
Windows Server 2019 operating system
Windows Server 2022 operating system
Windows 11 operating system
Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 2.1: Protocol towers based on Banyan Vines, DECnet, and Microsoft Message Queuing (MSMQ) are deprecated and are only supported on Windows NT and Windows 2000. Except for those, all protocol towers that Microsoft supports or previously supported on Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2 operating system, Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10, Windows Server 2016, Windows Server operating system, Windows Server 2019, Windows Server 2022, Windows Server 2025, and Windows 11 are specified in this document and its normative references.

<2> Section 2.1.1.1: In Windows NT and Windows 2000, IPv6 addresses are not supported.

<3> Section 2.1.1.2: In Windows NT and Windows 2000 IPv6 addresses are not supported.

<4> Section 2.1.1.2: This protocol identifier was implemented by legacy versions of Windows for historical reasons and is preserved by current versions for backward compatibility.

<5> Section 2.1.1.2: Windows always asks the Server Message Block implementation to execute a transaction over the named pipe for all PDUs except bind and bind_ack on the client for synchronous RPC calls that do not have a communication timeout associated with the RPC call.

Encompassing the write of the last PDU and the read of the first PDU on the client for synchronous RPCs.

<6> Section 2.1.1.3: Windows NT, Windows 2000, Windows XP operating system, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 support this protocol sequence.

<7> Section 2.1.1.4: Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 support this protocol sequence.

<8> Section 2.1.1.4: Windows implementations of NetBIOS require processes to listen on a specific network interface device, and they have no provisions for routing messages between network interfaces that are not directly attached to the same link. For a Windows RPC client and RPC server to communicate, the server has to be listening on a network interface that the client can reach.

<9> Section 2.1.1.4: This protocol identifier was implemented by legacy versions of Windows for historical reasons and is preserved by current versions for backward compatibility.

<10> Section 2.1.1.5: This protocol identifier was implemented by legacy versions of Windows for historical reasons and is preserved by current versions for backward compatibility.

<11> Section 2.1.1.5: Windows implementations of NetBIOS require processes to listen on a specific network interface device, and they have no provisions for routing messages between network interfaces that are not directly attached to the same link. For a Windows RPC client and RPC server to communicate, the server has to be listening on a network interface that the client can reach.

<12> Section 2.1.1.5: Windows NT and Windows 2000 support this protocol sequence.

<13> Section 2.1.1.6: Windows implementations of NetBIOS require processes to listen on a specific network interface device, and they have no provisions for routing messages between network interfaces that are not directly attached to the same link. For a Windows RPC client and RPC server to communicate, the server has to be listening on a network interface that the client can reach.

<14> Section 2.1.1.6: Windows NT and Windows 2000 support this protocol sequence.

<15> Section 2.1.1.7: Windows NT and Windows 2000 support this protocol sequence.

<16> Section 2.1.2: Windows based clients and servers supports connectionless RPC exchanges and connectionless RPC transports.

<17> Section 2.1.2.1: When a connectionless RPC server or RPC client runs over UDP on Windows NT 4.0 operating system, the maximum size of a PDU is 1,024 bytes. Details on PDU length and fragmentation of request and response buffers are as specified in [C706] section 12.5.1. When a connectionless RPC server or RPC client runs over UDP on all other versions of Windows, the maximum size of a PDU is 4,096 bytes. Details on PDU length and fragmentation of request and response buffers are as specified in [C706] section 12.5.3.

<18> Section 2.1.2.2: When connectionless RPC exchange occurs over IPX on Windows NT 4.0, the maximum size of a PDU is 1,024 bytes. For details about PDU length and fragmentation of request and response buffers, see [C706] section 12.5.1. When connectionless RPC exchange occurs over IPX on all other versions of Windows, the maximum size of a PDU is 1,464 bytes. For details about PDU length and fragmentation of request and response buffers, see [C706] section 12.5.3.

<19> Section 2.1.2.2: Windows NT and Windows 2000 support this protocol sequence.

<20> Section 2.2.1.1.3: Windows uses the algorithm specified in [RFC4122] to generate the UUID.

<21> Section 2.2.1.1.4: Windows–based servers set the context_handle_attributes field to zero.

<22> Section 2.2.1.1.7: Without the installation of additional software, Windows supports the following authentication types:

Security Provider

Security Provider Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
NT LAN Manager (NTLM)
Kerberos
Netlogon

<23> Section 2.2.1.1.10: The Windows implementation of SMB server operations do not implement SECURITY_DELEGATION functionality.

<24> Section 2.2.1.2.2: Windows NT, Windows 2000 and Windows XP use the same definition of the structure as what is specified in [C706] Appendix L.

<25> Section 2.2.1.2.4: Windows treats any value other than the listed possible values as 0x00000000.

<26> Section 2.2.1.2.4: Windows redefines the same method by:

Adding the ptr attribute to the object and Ifid parameters.
Removing the [idempotent] method attribute.

The redefined method is as follows.

 void
 ept_lookup (
         [in] handle_t hEpMapper,
         [in] unsigned long inquiry_type,
         [in, ptr] UUID   * object,
         [in, ptr] RPC_IF_ID * Ifid,
         [in] unsigned long vers_option,
         [in, out] ept_lookup_handle_t *entry_handle,
         [in, range(0, 500)] unsigned long max_ents,
         [out] unsigned long *num_ents,
         [out, length_is(*num_ents), size_is(max_ents)]
               ept_entry_t entries[],
         [out] error_status *status
         );

Everything else about this method remains as specified in [C706] Appendix O.

<27> Section 2.2.1.2.5: Windows NT, Windows 2000 and Windows XP redefine the method by:

Adding the ptr attribute to the obj and map_tower parameters.
Removing the [idempotent] method attribute.

The redefined method is as follows.

 void __RPC_FAR
 ept_map (
     [in] handle_t hEpMapper,
     [in, ptr] UUID * obj,
     [in, ptr] twr_p_t
  map_tower,
     [in, out] ept_lookup_handle_t  *entry_handle,
     [in] unsigned long max_towers,
     [out] unsigned long *num_towers,
     [out, ptr, size_is(max_towers),length_is(*num_towers)] 
           twr_p_t *ITowers,
     [out] error_status *status
     );

Everything else about this method remains as specified in [C706] Appendix O. Note that this redefinition has no wire impact, and therefore, it is interoperable with the [C706] implementation.

<28> Section 2.2.1.2.6: Windows NT 4.0 supports this method. The definition of the method for Windows NT 4.0 operating system Option Pack for Windows NT Server is as specified in [C706] Appendix O. Windows 2000, Windows XP, and Windows Server 2003 preserve the Windows NT 4.0 definition of the method. However, the method performs no operation, returning EPT_S_CANT_PERFORM_OP in the status field.

All other versions of Windows redefine the method by removing all parameters to the method. The resulting definition is as follows.

 void   ept_insert(void);

This method performs no operation. However, instead of returning EPT_S_CANT_PERFORM_OP in the status field, the method raises an EPT_S_CANT_PERFORM_OP exception.

<29> Section 2.2.1.2.7: Windows NT 4.0 supports this method. The definition of the method for Windows NT 4.0 is as specified in [C706] Appendix O. Windows 2000, Windows XP, and Windows Server 2003 preserve the Windows NT 4.0 definition of the method. However, the method performs no operation, returning EPT_S_CANT_PERFORM_OP in the status field.

All other versions of Windows redefine the method by removing all parameters to the method. The resulting definition is as follows.

 void
 ept_delete(
    void
 );

This method performs no operation. However, instead of returning EPT_S_CANT_PERFORM_OP in the status field, the method raises an EPT_S_CANT_PERFORM_OP exception.

<30> Section 2.2.1.2.9: On Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, this method performs no operation, returning EPT_S_CANT_PERFORM_OP in the status field. On these versions of the operating system, this method is defined as follows.

 void
 ept_inq_object (
    [in] handle_t hEpMapper,
    [in] UUID * object,
    [out] error_status *status
 );

All other versions of Windows redefine the method by removing all parameters to the method. The redefined method is as follows.

 void
 ept_inq_object(
    void
 );

This method performs no operation. However, instead of returning EPT_S_CANT_PERFORM_OP in the status field, the method raises an EPT_S_CANT_PERFORM_OP exception.

<31> Section 2.2.1.2.10: Windows NT 4.0 supports this method. The definition and behavior of the method are as specified in [C706] Appendix O. Windows 2000, Windows XP, and Windows Server 2003 preserve the Windows NT 4.0 definition of the method. However, the method performs no operation, returning EPT_S_CANT_PERFORM_OP in the status field.

All other versions of the Windows redefine the method by removing all parameters to the method. The redefined method is as follows.

 void
 ept_mgmt_delete(
    void
 );

This method performs no operation. However, instead of returning EPT_S_CANT_PERFORM_OP in the status field, the method raises an EPT_S_CANT_PERFORM_OP exception.

<32> Section 2.2.1.3.2: This type is not defined in Windows versions earlier than Windows Server 2003.

<33> Section 2.2.1.3.3: Windows NT, Windows 2000 and Windows XP use the definition of the method specified in [C706] Appendix Q.

<34> Section 2.2.1.3.4: Windows NT, Windows 2000 and Windows XP use the definition of the method specified in [C706] Appendix Q.

<35> Section 2.2.2.2: Windows ignores the PFC_MAYBE flag when it is present in a PDU.

<36> Section 2.2.2.9: Windows NT and Windows 2000 ignore the RPC extended error information BLOB.

<37> Section 2.2.2.11: Clients on Windows NT, Windows 2000 and Windows XP prior to SP2 send undefined octets at the end of the authentication token, if the security provider indicates a shorter length of the authentication token than the sender of the data estimated initially.

<38> Section 2.2.2.13: On Windows 2000 operating system Service Pack 4 (SP4) and subsequent service packs, Windows XP operating system Service Pack 2 (SP2) and subsequent service packs, and Windows Server 2003 and subsequent service packs, Windows does not send the verification trailer for an RPC with the pipe IDL attribute, as specified in [C706] section 4.2. All other versions of Windows will send the verification trailer for an RPC with a pipe IDL attribute only if all the parameters with a pipe attribute are [out] only.

<39> Section 2.2.2.13: Stub padding octets are sent by Windows 2000 Server operating system Service Pack 4 (SP4) and subsequent service packs, Windows XP SP2 and subsequent service packs, and Windows Server 2003 and subsequent service packs.

<40> Section 2.2.2.13: Support for verification trailers is present on Windows 2000 Server SP4 and subsequent service packs, Windows XP SP2 and subsequent service packs, and Windows Server 2003, and subsequent. What part of the verification trailer is used by Windows and when it is used are specified in sections 2.2.2.13.3 and 2.2.2.13.4.

<41> Section 2.2.2.13.2: In Windows, this verification trailer command is sent for the first request on a connection only.

<42> Section 2.2.2.13.3: In Windows, this verification trailer command is sent for every request when the security provider does not support header signing. Windows does not send this verification trailer if the security provider being used is RPC_C_AUTHN_GSS_NEGOTIATE, RPC_C_AUTHN_WINNT, RPC_C_AUTHN_GSS_KERBEROS or RPC_C_AUTHN_NETLOGON.

<43> Section 2.2.2.13.4: In Windows, this verification trailer command is sent on the first request PDU that uses an abstract_syntax and transfer_syntax that were previously sent on a bind or alter_context PDU.

<44> Section 2.2.3: Windows NT, Windows 2000, Windows XP and Windows Server 2003 support connectionless RPC messages.

<45> Section 2.2.3.3: PF2_UNRELATED is not set in Windows NT Server 4.0 operating system.

<46> Section 2.2.3.5: Clients on Windows NT, Windows 2000 and Windows XP prior to SP2 send undefined octets at the end of the authentication token if the security provider indicates a shorter length of the authentication token than the sender of the data estimated initially.

<47> Section 2.2.3.5: These extensions require the model specified in [RFC2743] for all interactions with all security providers. An implementation instructs the GSS-compatible security provider to operate in a DCE-compatible manner by setting the DCE Style protocol variable. The following table details what PDU type carries (in its token section) the output of the GSS [GSS] call. Note that the first call to GSS_Init_sec_context generates no token transmitted to the server and that there is no support for a provider requiring more than two calls to GSS_Init_sec_context or GSS_Accept_sec_context.

<48> Section 2.2.3.6: The Windows implementation always sends the fack PDU with the vers field set to 1.

<49> Section 2.2.4.3: Arrays of context handles are not supported Windows NT, Windows 2000, Windows XP, and Windows Server 2003.

<50> Section 2.2.4.5: In the Windows version of the Microsoft Interface Definition Language (MIDL), this is accomplished by compiling with the ms_union MIDL compiler option on MIDL compilers, starting with version 3.01.75.

<51> Section 2.2.4.7: Windows supports a subset of the expressions allowed in C language in both NDR64 transfer syntax and when target level 6.0 strict NDR/NDR64 data consistency check is requested. The subset is the same in both cases.

<52> Section 2.2.4.13: Windows implementation indicates the octet stream as invalid if the provided byte count is not big enough to contain all the memory needed to unmarshal the pointer indicated by the other pointer parameter. byte_count is not supported in NDR64 transfer syntax.

<53> Section 2.2.5: NDR64 is available on 64-bit versions of Windows. NDR64 is not available for connectionless RPC. NDR64 is not available on Windows NT and Windows 2000.

<54> Section 2.2.5.3.2.1: A conformant array can contain, at most, 2³¹-1 elements in Windows.

<55> Section 2.2.5.3.2.2: A varying array can contain, at most, 2³¹-1 elements in Windows.

<56> Section 2.2.5.3.2.3: In Windows, a conformant varying array can contain, at most, 2³¹-1-o elements where o is the offset.

<57> Section 2.2.6.1: If the endianness is not 0x10 indicating little-endian, Windows assumes big-endian, as specified in section 2.2.6.1.

<58> Section 2.2.7.1: During unmarshaling, Windows ignores the value of the InterfaceID field.

<59> Section 3.1.1.1.3: In Windows, this value is kept in the registry and is set by the administrator of the machine. The value is always used by the server.

<60> Section 3.1.1.1.3: In Windows, this value is kept in the registry and is set by the administrator of the machine. The value is always used by the server.

<61> Section 3.1.1.1.3: In Windows, this value is kept in the registry and is set by the administrator of the machine. The value is always used by the server.

<62> Section 3.1.1.1.3: In Windows, this value is kept in the registry and is set by the administrator of the machine. The value is always used by the server. The default value for Windows based servers is 0. The default value for Windows based clients is 1.

<63> Section 3.1.1.5.1.1.2: The Windows system always selects the leftmost [in] handle as the binding handle.

<64> Section 3.1.1.5.3.2: This level of strict NDR/NDR64 data consistency check is enabled by using target robust compiler option, using a MIDL compiler. Target level 5.0 strict NDR/NDR64 data consistency check is not available in Windows NT.

<65> Section 3.1.1.5.3.2.2.1: If the maximum memory size exceeds 2³¹-1 bytes for a conformant structure, conformant varying structure, conformant array, conformant varying array, or conformant and varying string, the octet stream is indicated as invalid.

<66> Section 3.1.1.5.3.2.2.5: Interfaces using auto_handle are rejected in this level of consistency check.

<67> Section 3.1.1.5.3.3: This level of strict NDR/NDR64 data consistency check is enabled by using the target NT60 compiler option, using a MIDL compiler. Target level 6.0 strict NDR/NDR64 data consistency check is not available on Windows NT, Windows 2000, Windows XP , and Windows Server 2003.

<68> Section 3.1.1.5.3.3.1.2: This behavior is not available on Windows NT, Windows 2000, Windows XP, and Windows Server 2003 when the IDL file is compiled for target level 6.0 strict NDR/NDR64 data consistency check. This behavior is turned off if the IDL file is compiled with MIDL command option backward_compat maybenull_sizeis.

<69> Section 3.1.1.5.4: By default, Windows NT, Windows 2000, Windows XP without service pack 2, Windows Server 2003, Windows Server 2008 and Windows Server 2008 R2 allow remote anonymous calls; otherwise, remote anonymous calls are not allowed.

For details and how to change this behavior, see [MSFT-RPCIFRESTRICTION].

<70> Section 3.1.2.7.1.6: These additional client conformant validation checks are not available on Windows NT, Windows 2000, Windows XP, and Windows Server 2003. Users can disable these validations through registry and/or application compatibility settings. There is no validation support for multiple dimension conformant/varying arrays. A subset of the rules specified in this section are available in Windows Server 2003 operating system with Service Pack 1 (SP1), as listed. These validations can be disabled by Windows registry settings.

Validations are available for parameter-level correlation only. There is no support for embedded pointers, arrays, or structures.
Validations are available for NDR transfer syntax only. There is no support for NDR64 transfer syntax.
Conformant array, conformant varying array, or conformant varying string parameter are declared earlier in the parameter list before the parameter describing the conformance.
Conformance can only be specified by dereference of another parameter, the value of another parameter plus one, the value of another parameter minus one, the value of another parameter multiplied by two, or the value of another parameter divided by two.

There is no validation support for a conformant varying string whose maximum count is not specified by another parameter.

<71> Section 3.1.3.3.1: On Windows, the endpoint mapper does not listen on a protocol sequence until at least one server using dynamic endpoints on the system starts to listen on that protocol sequence.

<72> Section 3.1.3.5.1: Windows provides a configuration setting to limit the size of server stub memory allocation.

<73> Section 3.2: Windows based clients and servers support connectionless RPC protocol variants.

<74> Section 3.2.1.5.1: Windows NT 4.0 will only interoperate if the response fits into a single unfragmented response. A client can interoperate with a server running on Windows 2000, Windows XP or Windows Server 2003 using multiple fragmented response packets.

<75> Section 3.2.1.5.1: Windows NT 4.0 does not have support for Kerberos.

<76> Section 3.2.1.5.2: In Windows, RPC provides a set of asynchronous call invocation APIs. See section 8.1 for APIs listing.

<77> Section 3.2.1.5.2: Windows NT 4.0 does not support multiple simultaneous active calls in a single activity; otherwise, Windows supports multiple simultaneous active calls in a single activity.

<78> Section 3.2.1.5.3: The version-specific constant is 0x10000 for RPC servers that run on Windows based clients and is 0x40000 for RPC servers that run on Windows based servers. RPC clients use 0x2000.

<79> Section 3.2.2.1.4: In all versions of Windows, sequence numbers (and representations including Lowest-Allowed-Sequence Counter and Lowest-Unused-Sequence Counter) will "wrap around" to zero (0) if the next sequence number exceeds the maximum value for an unsigned 32-bit data type.

<80> Section 3.2.2.2.2: Windows RPC provides the API RpcAsyncCancelCall to set the F_CANCELED flag.

<81> Section 3.2.2.2.4: Windows NT 4.0 does not implement this timer.

<82> Section 3.2.2.4.1.3: Windows does not check the expiration of the security context.

<83> Section 3.2.2.5.2: Windows silently discards PING packets.

<84> Section 3.2.2.5.6: Windows follows the guidance specified in section 3.2.2.5.6. If the client has accepted five consecutive NOCALL packets containing a packet body with a window_size greater than 0, the call state is changed to STATE_FAULT.

<85> Section 3.2.2.6.1: In Windows RPC clients, set this interval to a constant value of 120 seconds.

<86> Section 3.2.2.6.1: In Windows RPC clients, set this interval to a constant value of 30 seconds.

<87> Section 3.2.3.1.6: In Windows NT 4.0, at most, one call can be in progress per activity. When a packet of a higher sequence number is accepted, the call with the lower sequence is canceled, and the higher number becomes the new lowest-allowed-sequence.

<88> Section 3.2.3.2.1: In Windows NT 4.0, the timer interval is always three seconds. In all other versions of Windows, the interval is effectively infinite: The server sends a burst of packets only in response to a client packet.

<89> Section 3.2.3.2.2: In Windows RPC servers, set this interval to a constant value of 30 seconds.

<90> Section 3.2.3.4.1: In Windows, the server implementation of the application protocol layer indicates to the RPC runtime that the error is handled at the RPC protocol layer by raising an exception.

<91> Section 3.2.3.5.3: Windows-based servers follow this clause, except that the dc_rpc_cl_pkt_hdr_t.auth_proto check is skipped when the PDU type is PING or the maybe flag is set in the dc_rpc_cl_pkt_hdr_t.flags1 field.

<92> Section 3.2.3.5.4: Windows NT 4.0 has the following behavior when receiving this packet: Find or create an activity object for the activity ID in the header. If the activity's lowest-allowed-sequence number is higher than the packet sequence number, discard the packet. If no active call exists with the packet sequence, create a call with that sequence in STATE_INIT and add it to the activity. Set the activity's lowest-allowed-sequence to the packet sequence. Process the packet according to the call state.

<93> Section 3.2.3.5.5: Windows-based servers answer the PING only if its serial number is higher than the serial number of any client packet previously seen in this call.

<94> Section 3.2.3.6.1: In Windows RPC servers, set this interval to a constant value of 30 seconds.

<95> Section 3.2.3.6.1: In Windows RPC servers, implement the idle scavenger timer event as a delayed procedure that is asynchronously called from a thread whose dynamic priority boosting is disabled. As a result, the scan for scavenging idle calls and activities could be delayed. To alleviate this, after receiving a new packet and dispatching to its activity's call, if the idle scavenger timer has already expired, then the server processes idle scavenging.

<96> Section 3.2.3.6.1: In Windows RPC servers set this interval to a constant value of 15 seconds.

<97> Section 3.3.1.5.1: Servers return a PDU indicating an error depending on the received PDU with the invalid version number, as specified in section 3.3.3.5.7.

<98> Section 3.3.1.5.2.1: The following list names the security providers that Windows assumes use three legs, as specified in section 3.3.1.5.2.1:

Security Provider

NTLM
NetLogon

<99> Section 3.3.1.5.3: Windows NT, Windows 2000, Windows XP, and Windows Server 2003 without SP1 do not support the bind time feature negotiation; otherwise, Windows has support for bind time feature negotiation. The server uses the message processing rules in this section, and clients always indicate support for bind time feature negotiation and for security context multiplexing. For Windows NT, Windows 2000, Windows XP and Windows Server 2003, the server uses the behavior specified in [C706], and the client does not indicate support for bind time feature negotiation and security context multiplexing. Windows allows a client to disable proposing use of the bind time feature negotiation through configuration.

<100> Section 3.3.1.5.3: Windows-based clients on Windows NT, Windows 2000, Windows XP and Windows Server 2003 prior to SP1 do not use security context multiplexing on this connection.

<101> Section 3.3.1.5.3: Windows-based clients on Windows NT, Windows 2000, Windows XP and Windows Server 2003 do not support keeping the connection open after sending the orphaned PDU. Also, Windows-based servers on Windows NT, Windows 2000, Windows XP and Windows Server 2003 do not support keeping the connection open after receiving the orphaned PDU.

<102> Section 3.3.1.5.4: Windows-based clients and servers do not send authentication information in this case.

<103> Section 3.3.1.5.4: A Windows-based client that is capable of security context multiplexing does not build more than 1,000 security contexts per connection.

<104> Section 3.3.1.5.4: Windows NT 4.0 and Windows 2000 do not enforce a limit of security contexts per connection; otherwise, Windows enforces a limit of 2,048 security contexts per connection.

<105> Section 3.3.1.5.6: Windows-based clients return error RPC_S_UNSUPPORTED_TRANS_SYN.

<106> Section 3.3.1.5.6: Windows-based clients negotiate a transfer syntax in parallel with marshaling data using transfer syntax NDR in cases where an existing connection does not support both the NDR and NDR64 (2.2.5) transfer syntaxes or there are multiple transfer syntax bindings that are available but no preferred transfer syntax. In such cases, the client always proposes NDR as one of the transfer syntaxes, and, if the server accepts a transfer syntax different from NDR, the client attempts to renegotiate transfer syntax NDR, which is used to send the requests already marshaled. But the server-accepted transfer syntax in the first negotiation is used for requests that have not started transfer syntax negotiation by the time the first negotiation completed.

<107> Section 3.3.1.5.8: Windows NTdoes not support concurrent multiplexing on a connection.

<108> Section 3.3.2.1.3: The Windows API to set this value is the RpcBindingSetOption() function with Option set to RPC_C_OPT_CALL_TIMEOUT.

<109> Section 3.3.2.1.5: Windows NT Server 4.0 does not set the bind time-out value. Windows implementations use the RpcMgmtSetComTimeout API.

<110> Section 3.3.2.2.1: Only NCACN_IP_TCP makes use of this timer. The RPC runtime on the client instructs the TCP/IP stack on the client to use a potentially smaller value than the default for the TCP keep-alives to monitor the state of the connection. The value used for the timer is determined by a higher-level protocol. A higher-level protocol passes a value between 0 and 10, and, on Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1 and Windows Server 2012 R2, the RPC runtime on the client uses these values as an indication of how long to wait for a response from the server before it turns on keep-alives. The value passed in by a higher-level protocol is interpreted according to the following table.

Time-out parameter	Actual delay before turning on keep-alives (in seconds)
0 (RPC_C_BINDING_MIN_TIMEOUT)	120
1	240
2	360
3	480
4	600
5(RPC_C_BINDING_DEFAULT_TIMEOUT)	720
6	840
7	960
8	1,080
9 (RPC_C_BINDING_MAX_TIMEOUT)	1,200
10 (RPC_C_BINDING_INFINITE_TIMEOUT)	Never

The default is time-out parameter 5. Once the keep-alives are turned on, the implementation of these extensions instruct the TCP/IP stack to send one keep-alive packet every second.

<111> Section 3.3.2.4.1.3: The RPC runtime on the Windows client can obtain the credentials from a higher-level protocol that can supply a user name/domain/password, or it can use the implicit credentials of the logon session that is attached to the thread on which the call is made.

<112> Section 3.3.2.4.1.4: In Windows, the higher layer protocol can use the RpcMgmtEnableIdleCleanup function.

<113> Section 3.3.2.5.1: Windows-based clients return error code 0x6c0 (RPC_S_PROTOCOL_ERROR) to the client application in this case.

<114> Section 3.3.2.6.2: Windows defines a threshold of existing connections above which the system will apply a more aggressive timeout. This value is fixed to 500.

<115> Section 3.3.2.6.2: Windows defines a threshold of existing security contexts above which the system will apply a more aggressive timeout. This value is fixed to 500.

<116> Section 3.3.2.6.3: The following table lists the Windows behavior for the various security providers:

Security provider	Security information applied for endpoint mapper requests
Kerberos	NTLM
NTLM	NTLM
Simple and Protected GSS-API Negotiation Mechanism	NTLM
Netlogon	None

In Windows, the application of this protection is triggered through configuration or APIs available to higher layers.

<117> Section 3.3.3.2.1: Only NCACN_IP_TCP makes use of this timer. The RPC runtime on the server instructs the TCP/IP stack on the server to use a potentially smaller value than the default for the TCP keep-alives to monitor the state of the connection. The value used for the timer is determined by a higher-level protocol. A higher-level protocol passes a value between 0 and 10, and the RPC runtime on the server uses these values as an indication of how long to wait for a packet from the client before it turns on keep-alives. The value passed in by a higher-level protocol is interpreted according to the same table that is specified in section 3.3.2.2.1. The default is parameter value 5. Once the keep-alives are turned on, the implementation of these extensions instruct the TCP/IP stack to send one keep-alive packet every second. This behavior is not supported on Windows NT, Windows 2000, and Windows XP.

<118> Section 3.3.3.3.1.3: In Windows, the name of the security provider module is retrieved from the registry by using the authentication_type constant supplied by the higher-level protocol.

<119> Section 3.3.3.4.1: In Windows, the server implementation of the application protocol layer indicates to the RPC runtime that the error is handled at the RPC protocol layer by raising an exception.

<120> Section 3.3.3.4.2: Windows-based servers never send shutdown packets.

<121> Section 3.3.3.4.3.1: The Windows equivalent of GSS_Inquire_context is known as QueryContextAttributes (Negotiate), the access token is retrieved by specifying SECPKG_ATTR_ACCESS_TOKEN as the attribute of the context to be returned. (See [MSDN-QueryContextAttributes]).

<122> Section 3.3.3.4.3.2: The Windows equivalent of GSS_Inquire_context is known as QueryContextAttributes (Negotiate), the token is retrieved by specifying SECPKG_ATTR_ACCESS_TOKEN as the attribute of the context to be returned. (See [MSDN-QueryContextAttributes].)

<123> Section 3.3.3.5.2: Windows systems reject call_id values greater than 0x7FFFFFFF and do not allow call_id rollover.

<124> Section 3.3.3.5.4: This behavior can be turned off by higher-level protocols or machine configuration. Note that the limit on Windows 2000 is 1 megabyte; Windows NT 4.0 does not implement such a limit.

<125> Section 3.3.3.5.6: This message handling is not present on Windows NT 4.0, Windows 2000, and Windows XP versions earlier than Service Pack 2.

7 Appendix B: Product Behavior

Additional resources