A few big issues

[whiggs]

to whom this may concern,
I have had some major issues with UVK that I was hoping could be looked into (especially since I have a license). First issue: autologon function doesn't appear to support domain-joined computers. If the username needs to have the domain name before it (eg Domain\username) then maybe instruction in the application that tells people this is in order. Or maybe have an extra input requesting domain name and leave blank if not in domain. Second and last issue actually, I have noticed that, when running a particular action under "maintenance tasks" (not sure exactly which one, but I know for a fact it is either "Empty all users temp folders", "Clear the Shell cache", "Clear MUICache", "cleanup junk files", or all of them) breaks built-in operating system diagnostic tools, like sfc and DISM (at least on Windows 10 pro x64 it does), and prevevnts them from functioning properly that moment onward. For example, every single time I run these scans and restart, I have run a script THAT I WROTE which runs various DISM repair commands, runs a sfc scan, and chkdsk and outputs results to desktop. The "Restorehealth" command will fail stating "The source files could not be found". Even though providing a wim and using the "source" parameter in the command will allow it to run to completion successfully, that is not the point. The point being that something your app is doing/deleting is removing what DISM considers to be "important operating system source files." Furthermore, sfc is just broken. Period. Forever. After your tool runs, sfc always fails at 24% with "Windows Resource Protection could not perform the requested operation." Yes the windows modules installer service is started, yes I have tried plenty of troubleshooting on my own time to resolve the issue myself, and yes, your tool is responsible. If you are going to call it a system repair tool, please at least try to develope it so that the computer is more healthy after the tasks complete rather less.

[Fred]

Hi whiggs.

Thanks for the bug report. I will try to reproduce the issue you mentioned, and in case I'm able to, repair it.

[Charger440]

SFC on Windows 7 Pro 64 works fine after the same actions. Will test on a windows 10 box when I have one available.

[Fred]

It may be the Cleanup Junk Files maintenance action. I will make it skip the WinSxS folder, and maybe some other system folders.

[whiggs]

Thank you sir. That would be great. I do like your tool, but it has also been the source of my repeated need for os re-installs. BTW, what about the issue concerning autologon and domain joined computers?

[Fred]

whiggs, I will try to make the autologon feature work for domain users.

[whiggs]

Awesome. Now, I haven't tried this, so this is just a guess, but when utilizing the autologon feature, it automatically attempts to login users that are local to the computer (in other words, "%computername%\" or ".\" is implied to be in front of the user name). Sure enough, when the user fails to login when utilizing the autologon feature, when I get back to the login screen to manually input credentials, the user that is listed as attempting to logged in is ".\%USERNAME%" on machines that are domain joined. Now I do not know how the feature is programmed to work in your application, but a potential solution could be just specifying the domain name in front of the user name when it is being setup (eg. %DomainName%\%username%). I don't know if this would result in the correct configuration or result in ".\%domainname%\%username%", but any forward slash (\) that is read in the username field is interpreted by windows to indicate that the user is not logging in with the default domain and specifying their own on the left side of the forward slash. That is why I was recommending that, if not a separate input box requesting the name of the domain to which the user account provided belongs (or leave blank if the account specified is a account local to the computer, in which case the logon domain would be implied %Computername% and the user name for logon would be %computername%\%username%), then simply allow for the domain to be specified as part of the user name that is input (and make the end users aware of this in the prompt in which they configure autologon). Thats just my 2 cents on the issue. In the end, you are the developer.

[Fred]

whiggs, the auto-logon feature works by setting both the DefaultUserName and the DefaultDomainName values of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon registry key. The password is securely saved as an LSA secret.

The problem is that I forgot about domain users and was setting the DefaultDomainName value with the name of the local computer without checking if the user belonged to a different computer/domain.

I know how to get the domain a user belongs to, so it should be working fine in the next update. Let me know if it doesn't.

[whiggs]

can do. Didn't mean to talk down to you or anything. I believe in being 100% clear so that anyone who reads, no matter level of skill, understands. Nothing is more frustrating when reading something where a obvious [to the person writing] step is left out and the readers are left scratching their heads...

[Fred]

It should be working fine in v10.3.5.

Actually the issue already existed in my dev laptop. Don't know when it started, though. So I just reinstalled Windows (10 x64) keeping personal files and apps. The problem was solved, then.

Then I ran the fixes you listed one by one followed bi a reboot, and then all at once, plus a few more I checked, followed by a new reboot. Here's the result:

Capture.JPG (61.19 KiB) Viewed 7151 times

Also added support for auto-logon domain users, as promised. Thanks again for reporting this issue.

[Charger440]

Fred,

Are you saying after a reboot, the machines worked fine without you changing your code?

I ran it myself Saturday on a fresh install of Windows 10 and it showed the error.
Having said that, one reason I had not discovered it is I have little to no faith in SFC. in my career, I have personally never seen it work for anything.

[Fred]

Jim, no, this was with the new version. I confirmed that previous versions were actually creating this issue.

[wmmiller]

So is it thought that it was system booster, junk files clean up that was causing this issue?

[Fred]

Yes, so it seems, Bill. The issue only seemed to happen on Windows 10, though. Anyway, the Junk files cleanup is also part of the System booster. Anyway, the most important is that it is fixed now.

[wmmiller]

Ok, thanks Fred.