The script runs fine if it's run on the OS drive, and the drive I would like to run it from was created with Windows 7. I keep the hotfixes and your script in a folder together, and never had a problem under Windows 7. This is the first time I've tried this when using Windows 8.
I think I know what the issue is . With the registry setting 'EnableLUA' enabled, which enables UAC (UAC is always enabled even if the slider is set to the lowest setting in the control panel), I and a couple of others have noticed that using or manipulating files on other drives created under Windows 7, regardless of the security permissions, doesn't work like it should (such as trying to edit script files!). I'm guessing that it may be this very fault that you are experiencing, but why it occurs I'm not sure. It could also be another related issue. I would has it to guess that if you had created/formatted the drive in Windows 8, then run the script off it, it would run fine. Of course, disabling 'EnableLUA' means that you cannot use Windows Apps.
Hi Burf, I tried the reg setting and turned UAC off, but its still doing the same after the reboot. It's funny, as the .EXE that McRip gave me works fine, just not your original .CMD file... I just added the location to the exclude list of Windows Defender... Still nothing...
hmmm, that's weird. What happens when you just run the script with EnableLUA disabled (and not clicking 'run as administrator')? Also, try changing the extension from .cmd to .bat and see if that changes anything. It shouldn't, but wouldn't be surprised if it did! If not I can pack it in an exe from now on. I was thinking of doing that with the uninstaller script, but there was little point if it's unnecessary. Basically it's just a self-extracting archive file that runs the script after extraction. The reason why the exe may work and the script not is because Windows probably treats the exe differently when running as administrator? and the script actually runs through the temp folder.
OK, the scripts (all versions that you sent to me) run if I don't run as admin. Changing to .bat makes no difference.
I might start packaging it in an exe then for the next version (next month's security release most likely) in case others run in to the same issue. It shouldn't happen, an I can't recreate it here. If I run the normal script as administrator, it does ask where the updates are (because of the system32 issue), but with the test 4 script correction it does work from the original location. I don't know why I can't recreate the issue you are having here, but it's definitely related to the changing of path bug. Scripts aren't loaded into memory when run, they seem to run command by command (if you open the script, modifiy it, save it, and select another option in it, it will actually use alterations!). So, basically what is happening for you is it's like the script has been 'deleted', and therefore can't be run, because the script can't be found.
Well it seems like the .EXE format is the way to go. There must be some security measure in Win8 that prevents DOS or BAT & CMD files from executing if its not located on the OS Drive.
It's actually a longstanding bug in Windows, and if anything it is a security risk. Not for the installer of course, but potentially for other files. The security risk occurs because of the change of folder to 'C:\Windows\System32', which if you were to define the most important folder on the computer that would be it! (of course many other folders are critical too, but system32 is by far the most exceedingly critical).
Hi Burf, Yeah, it's exactly the same. With UAC totally disabled it will run without admin rights, but if you use admin rights the dos box opens and closes almost instantly. (if not run from the OS drive.)
Windows 8 has two more reg entries which do not allow scripts to run when double-clicked or right-clicked. That means the UAC disabled setting pretends to be disabled completely. To disable UAC on Windows 8 completely apply the following reg file and reboot Windows 8. Then you only need to double-click the cmd file and it should work: Code: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] "ConsentPromptBehaviorAdmin"=dword:00000000 "EnableInstallerDetection"=dword:00000000 "EnableLUA"=dword:00000000 "EnableSecureUIAPaths"=dword:00000000 "EnableUIADesktopToggle"=dword:00000000 "PromptOnSecureDesktop"=dword:00000000 "ValidateAdminCodeSignatures"=dword:00000000 "dontdisplaylastusername"=dword:00000000 "FilterAdministratorToken"=dword:00000000
Funny thing is for me it works (including 'run as administrator') with just changing EnableLUA to 0. I still have some of those other settings set to their default values. It would be good to work out the root cause of the issue. Are the temp folder locations in the standard places or have they been changed to another drive etc?
On my test Windows 8 I had to apply the reg settings, too. Without, it didn't work at all. I'd be the best to package it in an exe which must be run as Administrator and extracts the cmd files in the folder where the updates are stored, just as I did it with the exe file.
Nope, the temp files are all default, my OS disk is Drive C:, so no strange setup. It's strange that this seems to be different for you Burf, but I can say that I didn't realise that UAC was not fully disabled on my system, until it came up in this thread. Now I have used the reg settings kindly provided by McRip. After the reboot, the behaviour has not changed, but at least it works, as long as I don't use Run As Administrator.
On my test setup w/ win8 x64, I have to use the reg file that I got from a friend w/c is the same as Mcrip in order to totally disable UAC.
Many thanks to komm for releasing the latest version of KUC for Windows 7. I was starting to worry that everyone had deserted Windows 7 for the delights of Windows 8...
If only there "were" delights in Win8. From my own testing it's more like every advanced function i want to perform is made 3x harder by MS and thus reducing productivity.