Hi Gianni, Just for pinpointing your problem: - Do you have Uniface 9.7 installed in the default C:\\Program Files...? ->Then please try 'Run as administrator for your IDF.exe and/or uniface.exe  This has helped me in similar cases. Please also check this issue... Cheers, Arjen

Thanks Arjen! "Run As Administrator" did the trick... I do not understand why administrative privileges are involved considering how fast it was having it working with U9.6 and expecially considering the U9.7 usys.ini file was edited and saved with Windows user "Gianni" having normal privileges of standard users. The renewed access control from Microsoft in latest Windows versions (from 8 on) and its relation with applications has still some black corner for me to be discovered... Anyhow thanks again...[Solved] Gianni

You're welcome Gianni! Daniel did some explaining on this Windows behaviour in the topic on the missing Debugger buttons as well.

gianni said Thanks Arjen! "Run As Administrator" did the trick... I do not understand why administrative privileges are involved considering how fast it was having it working with U9.6 and expecially considering the U9.7 usys.ini file was edited and saved with Windows user "Gianni" having normal privileges of standard users. The renewed access control from Microsoft in latest Windows versions (from 8 on) and its relation with applications has still some black corner for me to be discovered... Anyhow thanks again...[Solved] Gianni

My theory here is slightly different: some action probably caused that the IDF updated the usys.ini and hereby creating a "copy" of the file in the VirtualStore of your user profile. After that you've changed the usys.ini in the "original" location (e.g. \\Uniface\\adm\\usys.ini). When the "normal" user will now start the IDF he will see the content of the usys.ini "copy" (in the VirtualStore). And when the IDF is started with elevated rights (e.g. Run as Admin) then you'll see the content of the "original" usys.ini. In order to avoid any future confusion it might be a good idea to delete the files in the VirtualStore. You should find the files here:

• C:\\Users\\{UserName}\\AppData\\Local\\VirtualStore\\Program Files (x86)\\Uniface

Under the assumption that you've installed Uniface in the default location (i.e. C:\\Program Files (x86)\\Uniface). The problem could actually be "avoided" if the internal manifest of the uniface executables (e.g. idf.exe) would feature the following:

<trustInfo xmlns=”urn:schemas-microsoft-com:asm.v3″>     <security>         <requestedPrivileges>             <requestedExecutionLevel level=”asInvoker” uiAccess=”false”/>         </requestedPrivileges>     </security> </trustInfo> More info about this can be found (e.g.) here. Now any update of the usys.ini (and in fact any file that is located in a protected Windows directory, like e.g. 'Program Files (x86)') would fail (and nothing is written to the VirtualStore). But this might cause other "inconveniences". Hope this helps. Daniel

Daniel,

It's a kind of magic One shaft of light that shows the way It's a kind of magic You've hit the center: a copy of the old usys.ini was saved in my virtual store. It will be nice if the additional manifest rule will be included in the next maintenance releases to reduce headaches to Unifacers. Definitively [SOLVED]. Thanks! Gianni