Uniface on GitHub
Fixes and Updates
Since years we start the Uniface runtime from a networkshare with our customers. (= server-installation of the runtime.- with client-installation of C++ runtime and client-side SQLserver ODBC-source + asn)
Since Uniface 9.7.04 we experience problems starting our application.
Our first trial to start our application usually doesn't give a result (uniface.exe process starts but hangs) The second time we start our application is usually succesfull. BUT since uniface 9.7.05 things became worse, we sometimes have to start our application multiple (+- 10) times before the application really visualises. If you debug from startup it always works, but that's not really what customers should do.
Any idea what we can investigate?
We still launch Uniface from standalone PCs (\\servername\share\...\common\bin\uniface.exe), and have no issues. We do have to run the C++ runtime on the client workstation.
From terminal servers, we actually install the uniface.exe client on the server, and launch it using d:\...\uniface.exe.
Microsoft also recommended we setup DFS shares, instead of just using regular shares. Using that, we have had no issues.
How have you installed your "network-runtime"? Directly to the network-share? Or first on a standalone machine and then a copy to the network-share. In the past in the Uniface-setups you had the possibility to install development OR deployment. In the latest versions there is no more such option.
just quick questions:
Hope it helps...
Thank you very much for your quick reaction!
Check 1 : I have Visual C++ 2015-2019 version 14.24.28127.4 installed - other collegues too, but I can't assure that all users have that version
Check 2 : if I use /pri=255 it always works, if I use /pri=63 it doesn't
Check 3 : I disabled the antivirus software (Sophos) on my workstation, but not on the server, I'lltalk about that to our sysadmins
mmmhhhmmmCheck 2: /pri=255...it works.../pri=63...it doesn't!What if you start it with /pri=64 (just logging filesystem access)?
Just my 2 Cents: I remember one weird issue where the Windows patch level made a difference.
This was specific to Windows 10. With one Windows 10 patch level Uniface could hang on startup when /pri or $ioprint was not set (i.e. I/O message level = 0) and with higher I/O message levels it worked. With a later Windows patch levels the problem disappeared again. The Uniface installation and the configuration of the application was the same in both cases, and the only difference was the patch level of Windows 10.
So, you might want to check if all the Windows updates are installed correctly and the machine is restarted (after the installation of the updates). I know from my own experience that Windows can behave rather erratic when it's not restarted after running Windows updates.
Apart from that, maybe the Windows Sysinternals utility Process Monitor (https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) can shed some light where the Uniface process is hanging and if there's another process that interferes with the I/O of the application.
Hope this helps.
/pri=64 is already enough, /pri=63 is not the solution
Al MS updates are/were installed, even update 1909. A reboot was made. Any idea which (missing) update was the cause?
I tried Process Monitor but it's a whole mission to compare a working and an non working sessions log.
This is the end of a non-working version:
Thank you all for your suggestions/help!
Let's stick with ProcessMonitor as per Daniel suggestion:
In the image you have posted your appl (just before the crash) is trying to manage some namespaces with standard system calls (DLLs are coming from Windows\CSC directory); usually looking at ProcessMonitor log for a crashing appl does not help you enough because what you are looking for is what is trying to do the runtime just after: when is crashing! You need to compare two sessions: one running regularly the other one crashing.ProcessMonitor is enabling you to:- Filter for processName = uniface.exe- Save your session into a CSV fileYou need to save two process monitor sessions:- The first one is your Uniface appl started with /pri=127- The second one is your Uniface appl started with /pri=63The first one should NOT crash while the second one should crash. Right?
You should open both session logs and use the second one to identify the point where the first one is going over the crash point: the issue you are looking for will be there!Let's try to identify more info in this way...Is my english description clear enough?
P.S. Could it be your application is using SOAP driver in the crashing point?
Your english is perfect for me, I hope mine is too.
I do use the filter in ProcessMonitor. I will try the 2 sessions with logs as you described but to be clear, the uniface.exe process hangs and I think does nothing any more, (nothing appears in procmon any more) but it does not crash. (it hangs)
If it hangs probably is more useful recording just one session and you've already done it.
1)In the image you have posted last action Uniface runtime is trying to do is:- 11:53:16,8- uniface.exe- create file- \\intranet.cevi.be\dfsroot\Uniface\r9705\common\SystemResources\umsw.dll.mun- PATH NOT FOUND- Desired Access: Read Data/List DirectoryBased on this info the Uniface runtime is trying to do something at filesystem level.
2)Just as suggestion for your sysadmins: I feel not usual every action trying to decode name intranet.cevi.be has initially status FILE NOT FOUND then SUCCESS in the following line.
Could those help you?
© 2020 Uniface Privacy & Cookies | Privacy Statement | Legal