Uniface User Forum

Hello

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?

Regards,

Johan

Hi Johan,

just quick questions:

• first check: have you upgraded c++runtime on all PC clients when migrated from previous Uniface version to U97?
• second check: if you try to start your runtime with /pri=255...when Uruntime start to hang? Immediately? Nothing is written to application log?
• Third check: have you already tried to disable antivirus either on PC client and/or on your server?

Hope it helps...

Regards,
Gianni

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

mmmhhhmmm
Check 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.

Regards,
Daniel

Gianni

/pri=64 is already enough, /pri=63 is not the solution

Daniël

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!

Johan

Hi Johan,

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 file

You 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=63
The 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?

Gianni

P.S. Could it be your application is using SOAP driver in the crashing point?

Hello Gianni

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)

Regards

Johan

Hi Johan,

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 Directory
Based 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?

Gianni

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.

At last, we found the solution.

When Uniface.exe from a network-drive (also Uniface 10.03.02) hangs in the system tray, you have to close the process (use taskmanager). Check the Disable fullscreen optimizations option (right-click on the uniface.exe - properties - Compatibility)

And Uniface will start as it should!

Thanks to everybody who added a reaction!

Hi

Checking the "Disable fullscreen optimizations".
Is this something that is needed to get it started as you have got problems, or is it something that prevents Uniface from hanging?
What actually does it do?
Regards RogerW.

It prevents Uniface from hanging.

We found out that on some Windows (Server???) versions this is not the solution. So we changed another setting: DISABLETHEMES and than Uniface starts as it should but checkboxes and radiotbuttons are not displayed!

So still in trouble...