The problem arises again with the final release of Windows 10 [and Server 2016 Preview 3 too] using e. g. Oracle 11g [11.2.0.4, 64 bit] after installation tasks worked fine with several preview builds of Windows 10. All things said above are o. k. resp. do not work.
The ultimate cause is an incompatibility of OracleRemExecService [vs. RemoteExecService.exe]: as known, at the beginning of installation process it is created via %TEMP%\oraremservice. If you watch it e. g. with Sysinternals' ProcessMonitor using an appropriate filter, you can see several crashes [the most of them with "buffer Overflow"] and restarts, and there are also corresponding with messages in Windows' "System" event log.
If you start [after deleting the HKLM\Software\oracle in the registry] the installation several times [more than three times - see below] it suddenly works. The reason for this behaviour is Windows' "Fault Tolerant Heap" mechanism [see //msdn.microsoft.com/de-de/library/windows/desktop/dd744764[v=vs.85].aspx] that creates after three attempts within 60 minutes [see //blogs.technet.com/b/askperf/archive/2009/10/02/windows-7-windows-server-2008-r2-fault-tolerant-heap-and-memory-management.aspx] a FTH entry in HKLM\Software\Microsoft\FTH\State and a corresponding shim in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers. Although the content of the FTH entry is related to the current process of RemoteExecService.exe you can import the registry keys to a system before you start the DB installation. If you set Windows' %TEMP% environment variable and also %TMP% [due to the fact that Oracle uses both directories while creating the things around OracleRemExecService] to a predefined value [e. g. C:\TEMP] you are able to use this for all your installation tasks as follows [unfortunately, it works only with Windows 10, not Server 2016 - updated 2015-09-24, see below]:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Temp\\oraremservice\\RemoteExecService.exe"="FaultTolerantHeap"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH\State]
"C:\\Temp\\oraremservice\\RemoteExecService.exe"=hex:10,00,00,00,10,00,00,00,\
0c,b4,ff,0c,52,00,65,00,6d,00,6f,00,74,00,65,00,45,00,78,00,65,00,63,00,53,\
00,65,00,72,00,76,00,69,00,63,00,65,00,2e,00,65,00,78,00,65,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00
Update 2015-09-24: With Server 2016 [Preview 3], it's a little bit more tricky: first you also have to set the environment variable %TEMP% e. g. to C:\Temp and to import the registry keys above [after this, it's no bad idea to restart the system]. Than you start the Oracle installation using an additional parameter:
setup.exe -debug
If you watch what happens in %TEMP% you can see that the folder %TEMP%\oraremservice\ is created twice: after first creation, the installer seems to notice that the service does not work, deletes the folder and creates it again. After this, the Installation process works as expected.
Update 2015-11-27: - Using Windows Server 2016 Preview 4, the workaround via "setup.exe -debug" is not necessary anymore; you can proceed as described for Windows 10. - Of course, you do not need the procedure with new C:\TEMP vs. %TEMP% and %TMP% if you have a defined user [e. g. Administrator]. Then you can use modified registry items like this:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Users\\Administrator\\AppData\\Local\\Temp\\oraremservice\\RemoteExecService.exe"="FaultTolerantHeap"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH\State]
"C:\\Users\\Administrator\\AppData\\Local\\Temp\\oraremservice\\RemoteExecService.exe"=hex:10,00,00,00,10,00,00,00,\
0c,b4,ff,0c,52,00,65,00,6d,00,6f,00,74,00,65,00,45,00,78,00,65,00,63,00,53,\
00,65,00,72,00,76,00,69,00,63,00,65,00,2e,00,65,00,78,00,65,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00
Update 2017-01-31: Tested all builds of Windows 10 [Insider Preview] until now, so we have seen a new problem coming up with build 15002: the Oracle setup isn't able to determine the PATH variable anymore [the variable itself, not a wrong content or so on!]. So all attempts to install the Oracle DB fail. Comparing the registry of the Windows versions and "playing around" with this variable and their contents did not help. The only work-around is to edit the related XML file \64bit|32bit\stage\cvu\cvu_prereq.xml and delete in the section all tags ... [or this tag only in the last item "Windows Server 2012"]. And btw: despite of we are primary using Oracle 11g this new installation problem also occurs using the up to date setup of Oracle 12c...