Windows 10: Intel iCLS client - is it Program Files or Program Files (x86)?

Whilst working on problem with my Win10 OS, I found a bit of treacle during my examination. The Intel iCLS Client shows system environment variables for both the C:\Program Files directory and also C:\Program Files (x86). I don't see how that could be correct.





Sure enough, there are files in both locations.
That and several other Intel component appear in dual locations.





If appropriate to clean up, what steps would I use? Seems to me that uninstalling has a lot of potential to break something severely, and I suspect these won't uninstall cleanly.

I'll be chasing around looking for install files while waiting for your thoughts on the thread. Cheers.

:)

 

Windows 10, version 1709 after update Some programs not operational

Are you on 1709 or 1703? You have mentioned both.

It sounds like MS reset an "environment" variable back to default. Windows uses environment variables as shortcuts. Windows associates the long version with the shortcut then uses the shortcut elsewhere. For example

%programfiles%

expands to "C:\Program Files"

The easiest one to fix is "Path". it lists all of the places Windows should check for your program files.

For example, here is my path:

C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Intel\Intel(R)
Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program
Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\Calibre2\;C:\Users\Luser\AppData\Local\Microsoft\WindowsApps;

Updating your path to point to those other locations should fix your problem, I think. It's been a VERY long time since I've played with it.

 

Task Scheduler of Windows 10 has some new features *not*

A)

I'm used to work a lot with batch files and command line. So if an executable can be found within the defined path I won't use the full path to call it.

If you have a look at your machine path you will find that components from Microsoft or Intel or Nvidia, etc. do set the a path to their executables....so you see I'm in good company.

example:

C:\Program Files (x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Intel\Intel(R)
Management Engine Components\IPT;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;E:\Programme\Freepascal\bin\i386-Win32

I do really agree to you do it as robust as necessary, but not to overdo it if it ain't really really necessary.

And on the other hand:

It worked with Windows 7!: So this knowledge might be usefull if you upgrade to Win10 and find things not working as expected. (This is the real issue.)

B)

It's true, not all exported tasks with win7 compatibility will have an issue.

And I did not really pin it down to which settings exactly causes the problem.

My guess ist that this settings in the XML-file will cause problems with Win7:

<DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>

<UseUnifiedSchedulingEngine>true</UseUnifiedSchedulingEngine>

I really have no idea where they come from... might depends on the trigger.

I have at least one task which's trigger is set to execute monthly on a given day and it will have this settings when exported with win7 compatibility, but not when exported with Vista compatiblity.