Cannot install 64bit version. Unable to execute netsh.

[IgorFi]

Hi folks.
I'm trying to install the latest 64bit version 1.2.2.1 but always get this error:



Could you tell me, what is wrong here? Thank you.

[Oliver]

The error 193 means ERROR_BAD_EXE_FORMAT, with the description as given in the message box.

What exact OS version do you use? I know a few modern Windows versions (especially the server ones) lack the WOW64 layer required to run 32-bit applications on 64-bit Windows. But it would be very very very odd for this to happen for an executable that ships with Windows.

Now it doesn't make sense that this is due to the missing .exe suffix either, because typically then you'd expect ERROR_FILE_NOT_FOUND or ERROR_PATH_NOT_FOUND or similar.

[IgorFi]

Hi Oliver! Thank you for the answer. It windows 10 Educational (same as Enterprise). 64bit. 16GB ram, i7. Trying to install and always get this error. 32bit version is fine though.

[SkyBeam]

I have noticed something which might be related and actually might be the cause of the issue.

Note: This only happens to me on Windows 7 64-bit. Not on Windows 10 (didn't try Windows 7 32-bit or Windows 8.x yet).

When I launch some 32-bit applications on Windows 7 64-bit from the UltraVNC folder it fails with a message:


There might be multiple DLLs it complains about, depending to what the application is linked.

How to reproduce:
Copy a 32-bit binarie e.g. c:\windows\syswow64\netsh.exe to the uvnc installation directory and try to run it from there.

The cause in case of netsh.exe semes to be IPHLPAPI.DLL. If this DLL is deleted netsh.exe run from the UVNC installation folder is working fine. The same issue might also occur if the working folder is within the UVNC installation directlry. I currently suspect some DLL injection issue here. I have seen binaries failing also when NETAPI32.dll or VERSION.dll is in there (for example I tried to run subinacl.exe from the UVNC folder and it failed due to NETAPI32.dll and VERSION.dll).

I have found a possible answer here. But it should only happen if one of those core libraries are directly linked rather than correctly use the documented APIs only.
It's not fully clear to me yet why those UVNC DLLs are causing this except if they are incorrectly linked.

Perhaps this is showing some potential code/linking issue on those libraries.

[Rudi De Vos]

Cause is de installer calling direct netsh via a run command, this has nothing todo with uvnc.

Code: Select all

Run]
..
Filename: "{sys}\netsh"; Parameters: "firewall add portopening TCP 5900 vnc5900"; Flags: runhidden; StatusMsg: "{cm:firewall}"; MinVersion: 0,5.01; Components: UltraVNC_Server UltraVNC_Server_S
Filename: "{sys}\netsh"; Parameters: "firewall add portopening TCP 5800 vnc5800"; Flags: runhidden; StatusMsg: "{cm:firewall}"; MinVersion: 0,5.01; Components: UltraVNC_Server UltraVNC_Server_S
Filename: "{sys}\netsh"; Parameters: "firewall add allowedprogram ""{app}\winvnc.exe"" ""winvnc.exe"" ENABLE ALL"; Flags: runhidden; StatusMsg: "{cm:firewall}"; MinVersion: 0,5.01; Components: UltraVNC_Server UltraVNC_Server_S
Filename: "{sys}\netsh"; Parameters: "firewall add allowedprogram ""{app}\vncviewer.exe"" ""vncviewer.exe"" ENABLE ALL"; Flags: runhidden; StatusMsg: "{cm:firewall}"; MinVersion: 0,5.01; Components: UltraVNC_Viewer
...

like when you open a cmd
and type
netsh firewall add portopening TCP 5900 vnc5900
This add an exception to allow vnc

could it be that{sys} is replaced by c:\windows\syswow64\ vy inno setup or i just need to use {syswow64} instead of {sys}

{sys}
The system's System32 directory.
For example: If you used {sys}\CTL3D32.DLL on an entry and the system's Windows System directory is "C:\WINDOWS\SYSTEM", Setup or Uninstall will translate it to "C:\WINDOWS\SYSTEM\CTL3D32.DLL".
On 64-bit Windows, by default, the System32 path returned by this constant maps to the directory containing 32-bit system files, just like on 32-bit Windows. (This can be overridden by enabling 64-bit mode.)
{syswow64}
On 64-bit Windows, the system's SysWOW64 directory, typically "C:\WINDOWS\SysWOW64". This is the actual directory in which 32-bit system files reside. On 32-bit Windows, 32-bit system files reside in "System32" or "System", not in a separate SysWOW64 directory, so this constant will resolve to the same directory as {sys} if used there.
Do not use this constant unless you have a specific need to obtain the name of the actual directory in which 32-bit system files reside. Gratuitously using {syswow64} in places where {sys} will suffice may cause problems. (See the documentation for the [Files] section's sharedfile flag for one example.)

[SkyBeam]

I think {sys} is correct there. However if the installer process is a 32-bit process it will refer to 32-bit system folder (%SystemRoot%\syswow64 on 64-bit systems )while 64-bit processes will refer to 64-bit system folder (%SystemRoot%\system32 on 64-bit systems).

It's actually a bit confusing. On 64-bit systems it looks as follows

• %SystemRoot%\system32: Contains 64-bit binaries and libraries.
• %SystemRoot%\syswow64: Contains 32-bit binaries and libraries.

It's confusing since the name of sysrem32 contains 32 but it actually contains 64-bit binaries and syswow64 contains the teram "64" but only contains 32-bit binaries. The thing only becomes logical if you know the history. Microsoft decided to keep the system32 name as-is for compatibility reasons and just stick all 64-bit binaries and libraries in there. In order to provide the 32-bit compatibility layer they invented the sysWoW64 folder where WoW64 stands for "Windows on Windows 64" so it's 32-bit Windows on Windows64.
Totally disastrous naming and terrible usability with lots of confusion is the result. No doubt you already know this, but there are a few quirks:

• Any legacy 32-bit Programm accessing %SystemRoot%\system32 will be redirected to %SystemRoot%\sysWoW64

Having said this any 32-bit programm calling netsh.exe from %SystemRoot%\system32 will actually execute %SystemRoot%\sysWoW64\netsh.exe (yes, its 32-bit version). There are APIs so 32-bit applications can also access the real 64-bit folder in system32, but usually you just get redirected and you don't even know the real contents of system32. For example try to launch 32-bit cmd.exe (from %SystemRoot%\syswow64\cmd.exe) and list the content of system32 by typing "dir %SystemRoot%\system32" and surprisingly you will get the contents of %SystemRoot%\syswow64 listed.

There is a work-around... you can also access the sysnative folder so from within a 32-bit program you can run %SystemRoot%\sysnative\netsh.exe (yes, the folder is not there in Explorer, but you can run "dir %SystemRoot%\sysnative" from any 32-bit cmd.exe). This allows 32-bit applications to run 64-bit Windows binaries. For example a 32-bit program to run a 64-bit cmd.exe or netsh.exe.

Now the key point... The UltraVNC 64-bit setup seems to be a 32-bit program (run it and add the "Platform" column in details view in task manager to see it). As a 32-bit program you can use {sys} internally and I am quite sure it will refer to syswow64 folder (32-bit applications). To fix this you would either require to inno setup to be compiled as a 64-bit module, so also the setup program and all commands launched by it will be 64-bit variants from system32 folder or you would have to use the sysnative work-around to spawn 64-bit variants on 64-bit systems (but don't use this on 32-bit programs, I think sysnative does not exist on 32-bit OS, at least not on Windows 7).


Well, and then there is the issue I reported, which might be related. When UVNC libraries are in the path (or working directory) many 32-bit applications seem to fail to be run. So This is why I suspected that the (32-bit) inno setup installer for 64-bit UVNC fails to initialize 32-bit netsh as it will just run it from syswow64.
To test this, try to copy %systemroot%\syswow64\netsh.exe to your UVNC install folder and run it from there, it will fail.

[Rudi De Vos]

As it fail for {sys} the only change we can made is {syswow64}.

Original error was not a 32bit app...Using the syswow64 containing the 32bit versions could be the answer.

Changes and installer still work on win10 64bit.

Test version
https://www.uvnc.eu/download/1222/Ultra ... _Setup.exe