Hi, I checked with 19631.1 mn prerelease version (FAST). I have rolled back the VM installation since, so, all is well. But the .NET reference might actually be a clue - I used 2.7.1 WuMgr to install the .NET CU which was offered. That might have been a mistake, maybe on MS' part. After installation and reboot, the WU service was gone (verified in Services Registry, the wuauserv key was still there, but empty). This time, I'm prepared and am trying to reproduce. About Defcon error. When system is under load, VMs may have really sh*tty timing. Plus, network was used also, might have slowed down further. I'll check up upon the other problem first, it's more serious. Edit: I captured my initial problem. Obviously, when all is done, the MS-Defcon line has scrolled out of the window, and there's no way to scroll back. By the way, this time, no error. I have done everything the same.
I tested the script with 19624, 14393, and 17763 before releasing it and after more testing today I can't reproduce the problem that you and @thewizardoz are seeing. I know removing the ms-defcon code from the script will fix it, and I'd rather not do that, but whatever works is what I'll do. I could give the previously mentioned option of opening a browser to see the current ms-defcon level instead of displaying it in the script.
Personally, I don't need it. Couldn't you make it an option in the configurator? "Check the current MS-Defcon level in browser" or so?
M$ could update other hijacker files but leave SIHClient.exe alone. But if this is a low risk, then this check should be okay. Strange, at least for me (running with system permissions, like the scheduled task) "icacls C:\WINDOWS\System32\SIHClient.exe" returns 0, when the file is already locked (no ACLs in the file). You have "if %errorlevel% neq 0 goto okay", so it doesn't go to okay. Code: C:\Tools\Sledgehammer_2.7.1\Portable\Sledgehammer\bin>whoami nt authority\system C:\Tools\Sledgehammer_2.7.1\Portable\Sledgehammer\bin>icacls C:\WINDOWS\System32\SIHClient.exe C:\WINDOWS\System32\SIHClient.exe Successfully processed 1 files; Failed processing 0 files C:\Tools\Sledgehammer_2.7.1\Portable\Sledgehammer\bin>echo %errorlevel% 0 I commented out the last 'exit' line from LockFiles.cmd, so I could see the lines without it exiting, and the script indeed continues and doesn't skip to okay: Code: C:\Tools\Sledgehammer_2.7.1\Portable\Sledgehammer\bin>icacls C:\WINDOWS\System32\SIHClient.exe 1>nul 2>&1 C:\Tools\Sledgehammer_2.7.1\Portable\Sledgehammer\bin>if 0 NEQ 0 goto okay C:\Tools\Sledgehammer_2.7.1\Portable\Sledgehammer\bin>set s32list=EOSNotify.exe WaaSMedic.exe WaasMedicSvc.dll WaaSMedicPS.dll WaaSAssessment.dll UsoClient.exe I think icacls can't be used just alone for this check. I don't know if this is a good idea, but searching "TrustedInstaller" (indicating that the permissions have been reset by an update) and exiting the script only if it fails to find it seems to work: icacls %systemroot%\System32\SIHClient.exe | find /i "TrustedInstaller" || exit
I have an updated v2.7.2 almost ready with the ms-defcon code removed. @freevista thanks for the info. I tried the find trustedinstaller statement and had some wierd issues so I just removed the check for now and it locks the files every time.
Just installed version 2.7.1 this morning. The uninstall by 2.7.0 went perfectly. Downloaded version 2.7.2 and ran the 2.7.1 uninstall. Nothing. The tasks were deleted, but, when I went to install 2.7.2 it told me that the Sledgehammer folder already existed. I manually deleted it. Installed 2.7.2, ran it and then restarted. The result for LockFiles was (0x1). Is that an issue?
Than can happen if unins000.exe and unins000.dat aren't created in the uninstall folder, or if you uninstall the installed version using the portable version. Very perceptive of you. That task doesn't report the error level correctly and always says the error level is 1 when it should show 0. I knew about this before I pushed out 2.7.2, but since the task works it was low on my list of priorities to fix. I'll deal with that with the next update.
I usually install the new script over the old one. Unfortunately, that causes the version number text files and Start Menu entries to accumulate. Could the installer remove all version text+start entries before writing the new one? Couldn't we also spider the AW website HTML and parse it directly for the Defcon level? Currently it's at line 200-201. Code: <h3 style="text-align:center">MS-DEFCON <span class="defcon-level"> 2</span>:</h3>
Inno Setup requires any custom code to be done with some version of Pascal which I know nothing about. I'll see what I can do but I'm not guaranteeing anything. Yes, it's just that the first try was with powershell. I'll play around with other methods.
Maybe download HTML site with wget, aria2 or curl and do a simple text search. As long as he doesn't change the site...
This fixes the LockFiles task not reporting correct errorlevel in Task Scheduler. Change the last line of \bin\LockFiles.cmd from Code: exit to Code: exit /b 0