Hi RogerW, The described problem does not really ring a bell. I don't think that I ever came across such an issue or know of someone that encountered something like this. It's a bit puzzling that the users can (at least attempt to) start Uniface when it's located on a network share that is not available. Sounds like "magic". Maybe Windows is caching some stuff, but that's not the complete Uniface installation? Just guessing. I would start with creating some log files with a large $ioprint (e.g. 255 or maybe even 2047). Maybe that give's you some clue what Uniface tries to do and where it "fails". Another handy tool is Process Monitor (ProcMon) from Windows Sysinternals. Maybe you can find some "obstacles" in the ProcMon log files that could explain, why Uniface is hanging. Hope this helps. Regards, Daniel

Hi Roger, IMHO an unstable network connection can be the reason for such unusual behaviour. I've found in past similar behaviour when the Uniface client is configured to heavily use TCP connections (Polyserver with FILSRV scope). Hope it helps. Gianni

Hi, I don't mean that Uniface is started without a network connection. User with laptops disconnects from the network without stopping the Uniface application. As they arrives to the conference room, they again connects the laptop to the network-cable. Then the Uniface application is dead. As this happens, they try to start a new Uniface application, which doesn't work as there is a "ghost" Uniface process in the Task Manager. Stopping the ghost-processes (there are two now) makes it possible to restart a Uniface-application.  The problem is that a Uniface application can't be started when there are ghost-processes in the Task Manager. This is not a problem in Windows 7, neither using Uniface 9.6.04. The same is probably happening as the network connection is lost for a while, ie. not just as the user is deliberately disconnecting. I don't see it as a problem if the Uniface-application is lost as they disconnect from the network, but the problem is that a new Uniface application can't be started. Users don't understand that they should kill all Uniface-processes in Task Manager or restart the laptop. First I saw this as a minor problem, but now there are persons here not wanting to update to Uniface 9.7 before this problem is clarified. Any help appreciated. Even if the solution is to update to Windows 10. Regards RogerW.

Have you tried to kill previous uniface. exe processes using osunix command as initial condition?

Hi fearandir, Hmm, tell me more.... Notice that these users are able to start many sessions of any Uniface-application and so they want to do. It's probably as their network connection has been lost as there are Uniface processes left that prevents the starting of further Uniface applications?? Regards RogerW. 

rogerw said Notice that these users are able to start many sessions of any Uniface-application and so they want to do.

Are the ghost processes on status "NOT RESPONDING"?   try something like this (windows) as initial condition of your uniface program: taskkill /f /fi “status eq not responding” /im uniface.exe check taskkill documentation    https://technet.microsoft.com/es-es/library/bb491009.aspx   Regards   Sergio

Hi Sergio, At least in Task Manager there is a normal status on the process, ie. not on status "NOT RESPONDING". As I start Uniface-application (windows 7), trying to disconnect the network-cable, reconnecting and then using the Uniface-application again. Then I get the following response "A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.". The process is successfully ended. Doing the same from Windows 8, seem to hang on the database login screen, and then usually a ghost-process is left and Uniface can't be started again. However sometimes the process is ended. ****The latest news, says that as the login-screen is showed, the process is ended. I interpret this as the ghost-process is a Uniface process trying to start blocking also later processes trying to start.... I think those users will have to stop the applications as they move to the conference room. And hopefully there won't be the same problems installing to our customers... Sergio, I suppose that if I try your solution, the status should be "NOT RESPONDING" as I don't want to end all Uniface processes, and all our startup-icons should start Uniface via a bat-file. Regards RogerW.

****The latest news, says that as the login-screen is showed, the process is ended. I interpret this as the ghost-process is a Uniface process trying to start after the cable has been reconnected, blocking also later processes trying to start…. Sorry about this, but I haven't been using these laptops myself. As a matter of fact, Windows 7 seem to handle this, but in Windows8 subsequent processes hangs as the first Uniface-process can't start... On the other hand, other Windows8 users seem to say that they have to start Uniface twice as the first  seem to be just loading, but the second start is successful (they haven't been disconnected from network at all).  There is something strange going on, starting from Uniface 9.7. Yes it would probably not happen if Uniface would be installed to the local drive C:. But that's not possible.  Regards RogerW

What is the OS of the server where uniface is running? net resources access between w8 and w7 is awful sometimes 

Let's forget about disconnecting from the network, although keeping in mind that the network sometimes could be slow. So, the first Uniface-process doesn't start on Windows 8. A second attempt, sometimes hangs and sometimes is successful. A successful start gives the below log, and a failing start probably hangs on loading umsw.dll as yrtl.dll is the last row showing up:   Loaded 'libdlm32' from G:\\mynet\\Uniface9704\\Common\\bin\\libdlm32.DLL, version: 9.0.4.241 Heartbeat process: SINGLE_THREAD, 1 Using license option LM_LICENSE_FILE xxxxxxxxxxx Checkout UW81: -1     Feature UWALL expires in 3650000 days Checkout UWALL: 1 Feature UCLIENT expires in 3650000 days Checkout UCLIENT: 1 Loaded 'ucall' from G:\\mynet\\Uniface9704\\Common\\bin\\UCALL.dll, version: 9.7.04 G401 Loaded 'ulib' from G:\\mynet\\Uniface9704\\Common\\bin\\ulib.dll, version: 9.7.04 G401 Loaded 'urtl' from G:\\mynet\\Uniface9704\\Common\\bin\\urtl.dll, version: 9.7.04 G401 Loaded 'yrtl' from G:\\mynet\\Uniface9704\\Common\\bin\\yrtl.dll, version: 9.7.04 G401 Loaded 'umsw' from G:\\mynet\\Uniface9704\\Common\\bin\\umsw.dll, version: 9.7.04 G401 Loaded 'ugui' from G:\\mynet\\Uniface9704\\Common\\bin\\ugui.dll, version: 9.7.04 G401 Non-DBMS file open: ..\\..\\..\\..\\support\\uniface9\\images\\GrayScaleLogo3.jpg Loaded 'uimg' from G:\\mynet\\Uniface9704\\Common\\bin\\uimg.dll, version: 9.7.04 G401   Regards RogerW.

We experienced similar issues when using Uniface 9.6.0.6 on Win2012 R2 servers. There is an option in Windows Server 2012R2 to do an "Analyze wait chain" on a process. When I clicked that back in the days, it told me Uniface.exe was in a deadlock ! Turned out is was indeed a Uniface deadlock, on the Uniface Logo Screen  We had to change our ini file, in the [application] section we had to put 

Logotime=off

  We were using the same settings for Logo since  Uniface 6 or something like that, and suddenly this was necessary. it might help you too ...

Thanks wimmme, I got one  of my fellows stop crying by setting  logosynch=on It seems that Uniface now started on the first try even on Windows8. logotime=OFF also seem to work... I've to investigate logosynch and logotime further... Regards RogerW.

No problem. Uniface users gotta help each other ;-)