RPC cancel request dialogue box due to session timeout triggered by the Network devices

“Outlook is retrieving data from the Microsoft Exchange Server <Server name>. You can cancel the request or minimize this message to the Windows taskbar until Outlook closes the message automatically” is a well known error message displayed in Outlook connected to an Exchange server. The server name displayed could be an Exchange server name or a Domain controller. This can happen due to various reasons.

KB article 839862 talks in detail about how to troubleshoot the RPC cancel request dialogue box.

In this blog, I would like to discuss one more cause of this issue.



Outlook displays this message for a few seconds or minutes and returns to normal work.

Outlook is in a hung state until you do “cancel server request” or kill Outlook.

When you do a GAL lookup or expand a distribution group after keeping the Outlook session idle for a few minutes, you get the above error message.

While you may experience any of these issues in Outlook, Outlook Web Access users do not encounter any such issue.


Troubleshooting Steps:

Take Netmon Trace on the client machine, Exchange server, and the domain controllers simultaneously.

Load it on Netmon 3.3 or wireshark.

Filter all RPC traffic between the two machines using the filter “MSRPC” in Netmon. You will see the following pattern. We can see that the client is sending a RPC bind request to the server and the server return a packet with error code Status=0x1C00001A.

558         0.515625              19:16:21.781                       {MSRPC:130, TCP:129, IPv4:10}     MSRPC                MSRPC:c/o Request: unknown   Call=0x7  Opnum=0x1  Context=0x0  Hint=0x18

559         0.515625              19:16:21.781                       {MSRPC:121, TCP:120, IPv4:10}                  MSRPC MSRPC:c/o Fault:  Call=0x8  Context=0x0  Status=0x1C00001A  Cancels=0x0


Filter all RPC traffic between the two machines using the filter “DCERPC” in Wireshark. You will see the following pattern. We can see that the client is sending a RPC bind request to the server and the server return a packet with error code Status: nca_s_fault_context_mismatch.


558         2009-05-06 19:16:21.781625       DCERPC                Request: call_id: 7 opnum: 1 ctx_id: 0

559         2009-05-06 19:16:21.781625  DCERPC                Fault: call_id: 8 ctx_id: 0 status: nca_s_fault_context_mismatch


Use the filter “MSRPC.Fault.Status == 0x1c00001a” in Netmon or “dcerpc.cn_status == 0x1c00001a” in wireshark to see all such error packets.

After this pattern the connection will be reset.

From the Netmon trace it will appear that the reset packet is being sent by the server or the client, but actually the TCP session was torn down by one of the network devices sometime back. Outlook Application attempts to reuse the connection using RPC protocol thinking that it is still available.

If you are seeing this symptom in complicated RPC/HTTPS setup, you have to take simultaneous Netmon trace from the Exchange Frontend server /CAS server, Exchange Backend server/Mailbox server, and the domain controllers. As the primary protocol used is HTTP, this issue may not affect the session between client and the firewall or firewall and the Frontend/CAS server. RPC communication is primarily effected by this if you have a router or firewall or any other network device in between.

nca_s_fault_context_mismatch error can also happen if the MTU size limit set on any of the network devices is lower than the default settings on Windows.

We have seen this issue with the following network devices and software:

1)      Proventia integrated security appliance

2)      Some of the CISCO routers

3)      CheckPoint firewall

4)      Nokia firewall

5)      Trunk configuration on 2950 switches

6)      Officescan firewall on the client machines

7)      CISCO ACS software

8)      CISCO firewall

9)      Symantec end point protection on the client machines



1)      Check the logs on the network devices between the machines and find out which device is causing the idle session timeout. Update the latest fix on these devices or increase the time for the idle session timeout or disable the feature.

2)      Identify how much time it is taking to reproduce the issue. I have seen session timeout happening if the session is idle for 5 minutes. In that case, we can set KeepAliveTime registry settings on the clients and servers affected to 4 min 30 sec. This parameter controls how frequently TCP tries to verify that an idle connection is still intact by sending a keepalive packet. If the remote computer is still reachable and functioning, the remote computer acknowledges the keepalive transmission. By default, keepalive packets are not sent. A program can turn on this feature on a connection. By setting this feature, we are not giving a chance to the network devices to close the idle sessions.


3)      To know if this issue is due to the MTU size limit, follow the article below and use the ping test to find out the right MTU size and fix it using any of the method mentioned in this article.




Thank you

Roopesh Pattan

Comments (0)

Skip to main content