Environment facts:
1. Windows 2012 R2 RDS server.
2. 5-20 concurrent users.
3. Users run several applications, including MS Office 2013, that are installed directly on the RDS server. In addition, they have a set of several front-end Delphi-based applications managing data on a back-end DB2 server (separate from the RDS server).
The EXEs for these are housed on a separate server and so are accessed via a drive letter mapped via Windows 2012 AD login script. This is the behaviour intended for them by the third-party developers, not a workaround. (My role is that, although I did not
write the Delphi apps or design the DB2 back-end, nor am I employed by the company that did, I provide targeted support for the business components dealing with the DB2 environment, including these applications and, where required, advise the IT department
on issues related to the DB2 server and the related applications).
4. All applications run on the RDS server are the same ones run on about 50 PCs by users physically located on the LAN at the corporate site that hosts the RDS server. The local users access the DB2-related EXEs the same way as the RDS-based users: via
the same drive ltter mapped to their network location.
Herein is the problem: some RDS users frequently, although not predictably enough to duplicate the problem at will, receive External Exception C0000006 errors, but only for the DB2-related applications. Two things helped me target my research:
1. These errors do not occur for the local users running the applications on their PCs,
2. Nor do they occur when testing with a copy of the DB2-related EXEs copied onto the RDS server.
My research thus far reveals that this error is apparently related to (or at least, displaying the same symptom as) a long-standing issue going back to Windows 2000, where there was a hotfix for the issue, wherein one or both of two things happens:
1. The single IP connection between the terminal server and the server hosting the EXEs gets confused about which RDS session requested the EXE/DLL, so the client session does not get the entire file loaded into memory.
2. Due to host server or network latency, the EXE or related DLL is not fully loaded into memory.
Whichever it is, it results in a page fault, ending with the C0000006 External Exception error. Per several online posts, it seems that it may be Delphi-related, although the suggestions there did nothing to diagnose the underlying cause and simply directed developers to provide RDS-local implementations. I am not the Delphi developer, so I have no control over the applications themselves, and my interest here is not in trying to debug the applications but to pinpoint what, exactly is happening on the terminal server when this happens. And I am already using a very limited local deployment to keep users running temporarily, but for a number of reasons, that is not a good option. So my focus here is attempting to understand in more depth the underlying issue with the goal of solving it at it source, not by workarounds that will cause other problems in our environment.
There are four more factors, although I cannot tell for certain the relative importance of each:
1. It was all working on our old Windows 2003 terminal server before we moved everyone over to Windows 2012 R2 RDS server.
2. The RDS server is running as a Hyper-V VM on a Windows 2012 R2 server with the bandwidth management disable for the VM.
3. The physical network adapter is a Broadcom BCM5709C card with VMQ (Virtual Machine Queues) enabled. Although there have been known poor-network-performance issues with some Broadcom cards when VMQ is enabled, this particular card is not on the list
of problematic cards. See this link:http://support.microsoft.com/kb/2902166
4. This is the one currently very much in focus for me: after extensive testing with a couple of the users that revealed everything above, the IT department revealed to me in passing that that this is happening only for the five or six users in the one
remote office where they have Apple workstations--and therefore the Mac version of the RDP client. That has to be very significant (and would have been nice to know at the outset), but I cannot figure out how it is related.