Shadow/Test Mode


I've read other requests before and I know it is a big ask that doesn't seem reasonable on first glance but like I tried to say in my PMs I think it can actually be done MORE EASILY then removals but you never responded so I figured I'd open up a public chat about the desired option in the hopes others might convince you where I obviously failed. I suppose it is also entirely possible they will devour me.

I don't recall which PM it was where I first informed you of my attempts but I do remember that it was about creating an OS build that was lighter like an NTLite build but also always 100% updateable and I know you've improved the update situation quite a bit since that time (at the cost of reduced 'remove ability'). This was always less of an issue on my personal PCs but any others I worked on HAD TO HAVE reliable update mechanisms.

So how could NTLite potentially remove stuff without actually removing it? My answer: Don't remove anything.

Sounds stupid huh? My solution was instead to change the access control lists for the related files and registry keys then only allow "NT SERVICE\Trusted Installer" access to them. Why "NT SERVICE\Trusted Installer"? So that windblows can always UPDATE anything we decide we don't want the rest of the OS to read, use, execute etc in an unimpeded manner.

Wait, you are now exclaiming?! Doesn't that mean it all still exists on the PC in question if it has to be able to update it? Yes, that's exactly what it means! So how does it remove anything you ask? That's the entire doesn't. So far as anything outside of "NT SERVICE\Trusted Installer" is concerned (eg the update king) the files or keys would not be accessible. This is why I proposed the Shadow/Test mode naming.

If it doesn't actually remove anything how would it be lighter? I'm glad you asked!
If the rest of the OS can't read it, it gets an ACCESS DENIED response instead of the normal NOT FOUND response it would in the case of an actual removed file or registry entry...This isn't ideal, I've found a couple more poorly coded apps that can handle the not found response but not the access denied ones. This isn't a universal issue though. In the end the things that would normally be removed are instead 'blocked' for all access outside of the Windows Update scheme. As such it would allow users to test removals without actually removing them, retain 100% update compatibility AND allow permissions to be restored when needed to fix things while trying to come up with that perfect build. The ACCESS DENIED response remains though and the entries will NOT be usable (even if you can still view them with a proper admin account).

Does it have limits? Be darned sure that it does. Moreso on Windows 10 with AppX packages whose permission changes don't work out well due to the (current) horrible implementation of the related AppX services. Things like that would still need to be *actually* removed as they currently stand. What else? I'm sure I haven't encountered every situation but mainly the other big issue is that you can't change every registry entry like that. As such some registry entries would still need to be *actually* deleted. It might have sounded like I was on repeat but I was actually talking about two different instances. AppX keys WILL currently need deletions as they currently exist via NTLite to avoid breaking the fragile (eg poorly coded) AppX related services...Most "Win32" software would not.

Would it require other large changes? Why yes I'm sure it would but the biggest would actually be a boon IMHO. It would require NTLITE to edit LESS when the shadow\test mode was enabled (eg leave the components hive mostly untouched and not delete stuff from WinSxS, oh my that sounds horrible!) and as such improve update compatibility once again.

Some issues I faced have been program specific. For instance ProcessExplorer wouldn't properly show running tasks when I would 'hide' tasks using the permissions method. Most others are likely things that nuhi has already figured out and added exclusions for in NTLite which are less related to HOW and more related to WHAT. This is why I would love to simply see a Shadow/Test mode making use of this already awesome engine.

This method would have some potential other pitfalls in a software setting. How to keep track of the fixes which need to be applied between NTLite versions in test mode? How to keep track of the original security permissions and restore them if the user wants to UNDO the test? How to backup or add those edited/removed reg entries with an undo option?

My idea isn't perfect. I know this. But I believe in NTLite and I know nuhi is even smarter than I am. So if you think my ideas (and tests) have any merit (I obviously do) please help me bug nuhi.

Still, I've used the idea (nearly flawlessly) on my own system and a few others via a limited number of test policy files which essentially hide the parts that NTLite would normally 'remove' giving me the option of restoring permissions to certain files or registry keys instead of attempting to 'put them back.' It's faster, it's safer and if it became an option in NTLite it's the one I would want to use in these more recent days. I'm sure many others would continue to trust in and use actual removals and I won't argue with them. That's just not me anymore.
Last edited:


Finally decided to look at this drunk post again and (while also drunk now) realized I failed to mention one of the largest potential issues I had encountered. Amusing that it also ends up being: Windows Updates themselves!

Windows restores permissions for updated they need to be refreshed after an update!

On my end where I created the inf files used in my limited test/use cases coupled with lgpo so far I have simply been relying on group policy file bats to do a check upon each shutdown/reboot followed by another check during the added task. I suspect something more like a resident service would make things easier on the user and I have no doubt nuhi could figure out an even more elegant way and I think I've read of the service idea a few times already and while I think it should be optional I do like it a lot.

But for now here are the relevant .bat entries related to how mine gets checked 'automatically' on a LCU for Win10.

For the shutdown bat
REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
IF %ERRORLEVEL% EQU 0 (SCHTASKS /CHANGE /ENABLE /TN "\Custom\Refresh Windows Permissions")
Obviously the "\Custom\Refresh Windows Permissions" entry is the path and name to the task for which I have created to apply on USER logon when enabled but normally sits as disabled.

If windows get that far after the 'reboot required' updates then then the called bat which is set to refresh the permissions using saved infs and a SYSTEM account also re-checks the same registry entry BUT in my limited experience it no longer exists upon user logon when updates get properly applied. So this may simply be redundant but I was 'trying' to be safe. After this USER logon followed by the task getting preformed ANOTHER reboot is required before the system would behave as you might 'expect for the LITE version' but I also added this to my tasks bat.

For testing in general and allowing an undo button option for most things I still hope it would be worth considering.. It's also potentially possible that the permission refresh could be attempted when initially detected but this seemed a rather dangerous approach for me to attempt if something should fail and feel as though it might be wasted due to pending changes but then I never tested it.
Last edited: