Empower application Freeze
Options
We have found the error in event log report.exe and fault module is ntdll.dll. how to overcome this issue. Please suggest.Thanks in advance.
0
Comments
-
Thank you for your question. Due to the technical nature of your question, please contact iRequest Technical Service/ Support: http://www.waters.com/waters/iRequest-Technical-Support/nav.htm?cid=10006027
A Waters Support Specialist will contact you to quickly address your needs. Thank you.
0 -
Hi, If the event logs say "Report Publisher.exe" I feel your pain.
This error can also be caused by other MFC programs like QUICKSTART.EXE and REPORT~1.EXE (short name for RP..)
We have had problems when users do not wait (or notice) the hourglass pointer when interacting with this MFC app. MFC Crash message gui shows sometimes. Other times it just hangs or exits.
There are two common event log errors. When it crashes with Faulting module name: ntdll.dll it shows the user did not wait or clicked away before it started responding again. The other error is with OraClient12.Dll. When I see the specific ntdll.dll error I know I need to remind my user that they have to wait or it can crash! You will know who it is when they ask for help!
It just seems to be a buggy program on Citrix server. It became much better once we changed the DEP to only system programs. This is tricky on Windows 2012r2 server!
You can also check the C:\Windows\ error path. ..\Windows\WER\ReportArchive\AppCrash_REPORT~1.EXE_cab* There will be lots of *useless* info there.
Until Waters fixes this 1990's program we will just have to live with many failed sign offs and empty ID's. I would love to know if the latest FR5 SR5 has any better performance. Regards, John c1 -
2012r2? I thought you'd be up to 2016... I'm wondering if using that might also be helpful.
In another thread, you said that the latest version would not support IEEE. I'm hoping that does not apply to SR4 of FR5! That's what I'm testing on before we move the rest of our stuff over. Do I have a problem? I shouldn't according to my research and discussions w/ Waters...
Did any of the names I sent you pan out? Look me up on LinkedIn some time, I'm easy enough to find.0 -
2012R2 Server has a limited life cycle however it was the only supported OS when we deployed last year on FR4 SR3. 2016/2019 server should be addressed by Waters and encouraged to test and deploy.
Are all your Lace updated? W7 is now only supported on old Lace and should really be migrated to W10.
If you don't plan to look at SR5 then SR4 is the last Waters release that will be 'tested' with IEEE. That seems minor until you have an audit or an issue that needs support.
Here is page 8 from the release notes:
Important: As of Empower 3 Feature Release 5, Windows Server 2008 and 2012 are no longer supported. See also: The Empower 3 Feature Release 5 Installation, Configuration, and Upgrade Guide (715006184).
Instrument support To further align our products, after the release of Empower 3 Feature Release 5 Service Release 4, Waters will no longer be offering Empower defect corrections or enhancements related to IEEE control in any release of Empower. As a result, support for IEEE instrument control will cease in all versions of Empower after the release of Empower 3 Feature Release 5 Service Release 4. Furthermore, if you use IEEE instrument control beyond Empower 3 Feature Release 5 Service Release 4, please be aware that it has not been tested.
FR5 has a lot of listed new features and enhancements. I always look for info in the sections; Issues resolved in this release and Known issues in this release. It was just out last month. However there are a ton of new/changed files that leads me to believe they have put a great deal of effort in this. Hopefully others will report the testing and confidence in this release soon. They may fix the issues in this thread! TBD.0 -
Good - as I thought, we're on latest release supporting IEEE, of which we have lots. We dropped it on a new server running Server 19 downgraded to 16, so we *should* be fine. We did have some crushingly slow performance at first with my test group's fat clients. As soon as I put out an alert to let me know when that happens again, they behaved. In a conf. call/TeamViewer session with out IT people and Waters people, I did the same report generation on the server and 2 different fat clients. Turns out the fat client that prompted the original complaints was the slowest option for generating that report, but it was not too bad. Ping tests didn't show anything seriously amiss. So we're suspecting WiFi issues of an intermittent nature. We're rolling W10 onto nodes and fat clients as we move them over to the new server.
0
