When you install OCI, you are not installing Java per se, as a registered application that the Windows Add/Remove Programs aka "Windows Installer" infrastructure knows about.
OCI lays out its Java versions on disk, in its folder structure, but we do not set system environmental variables like JAVA_HOME, etc
That said, if someone were to install Java on the OCI server to run the OCI java client, you would have Windows Installer see a Java install. I honestly forget if a Java Runtime Environment (JRE) installation sets JAVA_HOME, or if that only occurs by default with a JDK
A first cut at triage: drop to a cmd prompt:
C:\Program Files\SANscreen\java64\bin>java -version
Does that run cleanly? I don't know offhand what JRE is in 7.3.13, on 7.3.14:
java version "1.8.0_333"
Java(TM) SE Runtime Environment (build 1.8.0_333-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.333-b02, mixed mode)
If you don't see something similar, that would certainly explain why Wildfly cannot start.
I would recommend installing 7.3.13 on a temporary VM - if your Java is in fact broken, you could simply move your current ..\sanscreen\Java64 to a backup location, and copy in that folder structure from the temporary VM.
Then, run "java -version" in that same path - it should execute. At this point, you should have a sane JRE in the right place. Try bringing up the services.
