Inconsistent Elliott Error on Terminal Server
Q - We occasionally run into an issue with our terminal server where Elliott crashes after entering the username/password.
After clicking on the shortcut, it prompts for the username / password. After clicking OK, it crashes. We are confused because there are users already using Elliott 8 on the TS, but new users cannot log in. From my past experience, if I reboot the terminal server (not the Elliott PSQL server), this error will be corrected.
Attached is a screenshot of the faulting module, which is MSVCRT20.dll (see sample message below):
EL800.EXE has stopped working
Problem signature:
Problem Event Name: APPCRASH
Application Name: EL800.EXE
Application Version: 0.0.0.0
Application Timestamp: 5570b0eb
Fault Module Name: MSVCRT20.dll
Fault Module Version: 2.11.0.0
Fault Module Timestamp: 5643d49b
.....
I have verified that MSVCRT20.dll is in the Elliott7/Bin folder. We have added all of the Elliott 8 executables to the DEP safe list already, but you cannot add .DLL files.
Since all other users not on the terminal server do not have this issue, we know that it must have something to do with the terminal server and some Elliott files, but we do not know what. As a matter of fact, the users who are currently running on the terminal server can continue to work in Elliott. It is just the new users logging on to the terminal server that have this issue.
What can we do to diagnose the problem?
A - This is a known issue with Microsoft Terminal Server.
The Cause
You can see additional information of this problem with the following URL:
https://support.microsoft.com/en-us/kb/2536487
Base on our support experience with our own users base, this issue is applicable to Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012. We are not sure if it is still applicable to Windows Server 2016 due to limited installation base of our users with that version. There's no hot fix from Microsoft for this problem at this moment. We are not sure if Microsoft will eventually fix this issue. The following are additional articles that discuss this issue:
http://www.bearnakedcode.com/2011/06/win-2008-terminal-server-network-app.html
The nature of the issue is related to how the Microsoft Terminal Server handles open DLL files from a network shared folder. The FCB (File Control Block) belongs to the user instead of the system. When the user who owns the FCB logs out from the server in certain conditions, the FCB can be orphaned. As a result, other users may get errors when try to access the DLL file.
How to Confirm If This Is Indeed The Cause?
To know for sure if the above KB article is the root cause for your problem on Terminal Server, you need to use a utility called "Process Monitor" which is free from Microsoft. You can search for Windows Sysinternals and download the utility. Procmon (Process Monitor) is one of them. The following is an example of how we can use Process Monitor shows that when EL800RV.EXE try to load a DLL in Elliott Bin folder and receive the "NETWORK ERROR". This is the confirmation of this problem. See sample screen below:
Unfortunately, it is quite complicated to use Procmon. If you don't have the necessary expertise to use this utility, you will need other easier methods as outline in the next section:
Other Common Symptons For This Problem
(1) If you can get all other users on the terminal servers to close Elliott and logout their Windows session. Then, as the sole user on the terminal server, try the same Elliott application again. If the Elliott problem goes away, then we know for sure this is the cause. (2) If you can't get all other Elliott users to logout for some reasons, then you can reboot the terminal server. After the reboot, if Elliott start to work correctly on the terminal server, then it is likely this is the cause, but we can't be sure 100%.
There Are Various Messages for This Same Problem
For Elliott users on the terminal server, when they try to startup Elliott, they may experience Elliott failing at the startup at the same position as indicated in this article. The messages may be different, depend on which DLL get affected. They may simply indicate that EL700.EXE, EL800.EXE or an related EL800*.EXE has stopped working. It could be message indicating that it has problem loading some DLL files. Here is an example:
**********************************************************
Elliott was unable to load the following module:
GUILIB32.DLL
Elliott will terminate now...
**********************************************************
Sometime, the problem is less intrusive and only happen when you try to print bar code on the document. The following is an example:
Load error: file 'BC_DrawBarCode'
error code: 173, pc=0, call=46, seg=0
Error 173 simply means the particular file is not found. In this case, Elliott is trying to load the bar code DLL to render the barcode image. The DLL is in the Elliott root or bin folder. Elliott is not able to find this file due to bogus NETWORK ERROR as outlined in previous discussion.
In Elliott V8.x, it is common to see error with displaying reports with Elliott Report Viewer. See example below:
With this particular problem, you can display the report in notepad which you will by pass the error temporarily.
There are many faces to this same problem. In all these cases, at its root, Elliott has problem loading a DLL file from the Elliott mapped network drive which is caused by Microsoft Operating system bug as mentioned in the previous article.
Solutions
Generally speaking, when you encounter this problem, you can resolve this issue by doing one of the three methods below:
- Ask all users on this Terminal Server to exit Elliott. Once all users are out of Elliott, then ask users to come back into Elliott again.
- If some terminal server users can not be contacted.. Especially, they are disconnected, you can log them out by bringing up the task manager on the server console. In the User tab, highlight the disconnected users and choose to "Logoff". See sample screen below.
- General speaking, the above two steps should solve the problem. If not, reboot the Terminal Server.
We have tried to replicate this issue in-house by doing various tests with login/logout combinations, but we can't duplicate this issue. However, we are seeing this problem being reported from our users. Generally speaking, after our users adopt the following solutions, this problem is dramatically improved, if not resolved totally:
(1) Ask Users to Logout of Elliott When Done
In one incident, the user has a terminal server for overseas users to access Elliott. We noticed many of their overseas users do not logout of Elliott when done. This is understandable because it takes time for these users to logon to the Terminal Server, then it takes time for their Elliott session to start up. These users felt that if they kept their sessions open by just disconnect (by clicking on the "x" of their terminal server sessions,) then when they reconnect again, they can skip all the startup process and get to work in Elliott quickly. Unfortunately, this practice is not desirable if you are ecountering this problem described in this article.
Therefore, we asked their US office to monitor the terminal server overseas users at the time when they are not supposed to be in the system. Then report those users to the president of the company. After the president of the company had a conversation with those users who didn't logout of Elliott when done, this problem totally went away.
It is important that Elliott users should logout at night time for many reasons. This is just one of the reason. You could, for example, implement a procedure to ask the first person that arrive the company to start up Elliott as the first thing in the morning, then go to Main Menu -> System Utilities -> User List. Then a list of users will be displayed and show the last login time. For those users does not logout at night, email them to remind that they need to logout of Elliott at night time. Keep on doing this until they adopt this practice. If they ignore, then take this issue to the higher authority in your company.
(2) Do Not Forcefully Terminate Elliott Users When Disconnected
In another incident, the terminal server is configured to end a user session when it is discounted for 1 minute. See sample screen below:
It is bad idea to forcefully terminate the Elliott users just because their connection is dropped temporarily. Our theory is that the forceful termination of Elliott sessions may leave certain Elliott DLL files in the orphan state as indicated in the Microsoft Knowledge Base. We suggest changing the above setting to "Never" so the terminal server will never end a user session automatically after a session is disconnected. As a system manager, if you wish to terminate the disconnected Elliott user session, you should take over the user session and log the user out of Elliott and then logout the user session gracefully.
(3) Upgrade to Elliott 8.5 or Later Version
Starring Elliott 8.5, by default, Elliott runs in "Local" mode which means all users run a copy of Elliott in their local profile folder (i.e. c:\users\<userid>\appdata\...) instead of running from a shared network drive. This approach applies to terminal server users as well. Because of this "Run Local" mode, the orphan FCB problem is not applicable anymore. So if you have this inconsistent Elliott error on a terminal server, your best solution is probably upgrade to Elliott 8.5 and start using the "Run Local" mode.
EMK