Windows 11 File Explorer - Navigation and Context Bars Swapped Places

trumpy81 said:

Your assumption that the key is protected is incorrect as far as I am aware.

Click to expand...

Any existing keys under the Overrides key are set to Full Control only for TrustedInstaller and Read for Administrators. You can check that for yourself with RegEdit. It's not a new thing. It's that way on Windows 10 as well.

In your case, and Zamzummin's case, either the 1 key did NOT already exist or the permissions had been changed. In Lucas's case, the 1 key must have already existed and therefore was protected.

You also claim it is not advisable to use this reg edit...

Click to expand...

The problem is that the results are not consistent. I tested on three Windows 11 machines. One switched to the old layout, but now cannot be switched back. The other two did not switch to the old layout. EP, on the other hand, worked correctly on all three. If the reg setting worked fine for you, that's great. No worries there.

Perhaps you are using a Windows Insider build?

I am using the public released/updated version and I assume that Zamzummin is also using a similar build:



In my case at least, nothing under the overrides key is protected. There are other areas of the registry that have been protected, but they are not relevant here.

I also dual boot and my Windows 10 install is up to date and also NOT protected.

trumpy81 said:

Perhaps you are using a Windows Insider build?

In my case at least, nothing under the overrides key is protected. There are other areas of the registry that have been protected, but they are not relevant here.

I also dual boot and my Windows 10 install is up to date and also NOT protected.

Click to expand...

Inside or release appears to make no difference.

On closer examination, what I've found is that SOME of the numbered subkeys of HKLM\System\CurrentControlSet\Control\FeatureManagement\Overrides are limited to Read only for Administrators. For example, my main Windows 10 computer has subkeys of 0, 4, 9, and 15. Of those, all are protected except 4.

A Windows 10 VM I checked had keys 0 and 15 protected and 4 not.

A freshly built Windows 11 22H2 release build was the same (0 and 15 protected and 4 not).

But there are also cases where the numbered subkey is not protected, but the feature key is. For example, on my Windows 11 computers, that already have a 248140940 key, it's protected, even though the parent 1 key is not.

It's seems this is a YMMV thing.

P.S. My Windows 11 Release Preview, that I switched to the old layout using the reg change, is still stuck that way even after putting the registry back as it was, rebooting several times, SFC and DISM done, and uninstalling and reinstalling the last big Windows update. So, I guess that's great news for those that don't want the new Explorer to come back.

I double checked both Win 10 and Win 11 and none of the HKLM\System\CurrentControlSet\Control\FeatureManagement\Overrides sub keys are protected in either OS.

In Windows 11, I checked sub keys 0, 1, 2, 4, 6, 9 and 15 and their sub keys all appear to be modifiable. Admittedly, I only sampled two or three of the sub keys in each of the aforementioned sub key folders and all were modifiable.

I normally use Registry Workshop x64, but I also verified the same results in Regedit.

In Windows 10, I checked sub keys 0, 4, 9, and 15 and I found that all of their sub keys are also modifiable. My downstairs PC, which also runs Windows 10, does not have any protected sub keys either.



I wonder, if you were to update to Win11 23H2, if that would make a difference?

Probably not, but it's an interesting question just the same.

Possibly, you have some software or even hardware common to each machine, that is forcing the key protection perhaps?

Do you use a third party anti-virus at all?

Have you used any tweak type utilities at all?

trumpy81 said:

I double checked both Win 10 and Win 11 and none of the HKLM\System\CurrentControlSet\Control\FeatureManagement\Overrides sub keys are protected in either OS.

In Windows 11, I checked sub keys 0, 1, 2, 4, 6, 9 and 15 and their sub keys all appear to be modifiable. Admittedly, I only sampled two or three of the sub keys in each of the aforementioned sub key folders and all were modifiable.

I normally use Registry Workshop x64, but I also verified the same results in Regedit.

In Windows 10, I checked sub keys 0, 4, 9, and 15 and I found that all of their sub keys are also modifiable. My downstairs PC, which also runs Windows 10, does not have any protected sub keys either.

Possibly, you have some software or even hardware common to each machine, that is forcing the key protection perhaps?

Do you use a third party anti-virus at all?

Have you used any tweak type utilities at all?

Click to expand...

Mine are all vanilla. Two of them just built with nothing but the OS. The most obvious explanation is that all of mine are Home and yours are Pro. I'll build a Pro machine and check.

LesFerch said:

I'll build a Pro machine and check.

Click to expand...

This is where ElevenForum should auto-insert a mad scientist video...

trumpy81 said:

I double checked both Win 10 and Win 11 and none of the HKLM\System\CurrentControlSet\Control\FeatureManagement\Overrides sub keys are protected in either OS.

Click to expand...

I just built a fresh Windows 11 Pro 23H2 and I still see the same keys protected. Are we looking at the same thing? Here's a screenshot of the advanced permissions dialog for key HKLM\System\CurrentControlSet\Control\FeatureManagement\Overrides\0:

@Ghot

How appropriate ... lol

@LesFerch

No, we are clearly not looking at the same thing. There is absolutely no need to enter the properties of the key, unless you are having issues.

Back out of the properties dialogue and simply right click on an entry and edit/modify the key values, that will tell you if you have the correct permissions or not.

When modifying a key or it's values, a warning dialogue may appear, alerting you of any issue. You can then take appropriate action based on the message information.

BTW, what you show is pretty standard for most keys.

Also, you are at the wrong address. You should be at HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FeatureManagement\Overrides\1\248140940 as specified in the reg entry I posted.

Why use this key?

HKLM\System\CurrentControlSet\ contains your defaults, among other things.
HKLM\System\ControlSet001\ should contain your customisations, as far as I am aware.

If you modify the defaults, it can be that much harder to put things back the way they should be.

trumpy81 said:

@LesFerch

No, we are clearly not looking at the same thing. There is absolutely no need to enter the properties of the key, unless you are having issues.

Back out of the properties dialogue and simply right click on an entry and edit/modify the key values, that will tell you if you have the correct permissions or not.

When modifying a key or it's values, a warning dialogue may appear, alerting you of any issue. You can then take appropriate action based on the message information.

BTW, what you show is pretty standard for most keys.

Also, you are at the wrong address. You should be at HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FeatureManagement\Overrides\1\248140940 as specified in the reg entry I posted.

Why use this key?

HKLM\System\CurrentControlSet\ contains your defaults, among other things.
HKLM\System\ControlSet001\ should contain your customisations, as far as I am aware.

If you modify the defaults, it can be that much harder to put things back the way they should be.

Click to expand...

I think I need to clarify that I've been doing this stuff for 40 years and much of that as a professional (10 years at a major university and 15 at one of the largest banks in the world). I know what I'm doing.

Those properties show the current permissions. That's the point. You can clearly see that Administrators have Read only access. If you would like me to demonstrate it empirically, here's what happens if I try to create a new key under the "0" key (as an Administrator):



Or if I try to change its default value:



That's all to be expected when only TrustedInstaller has full control. Hence the need to use something like PowerRun to get TrustedInstaller privileges.

So please, do me a solid. Post a screenshot of your advanced permissions dialog (aka Advanced Security Settings) for key "0".

And I am not at the wrong address!

You are misunderstanding how those keys work. CurrentControlSet contains the current settings (as the name implies). ControlSet001(and 002) are backups. As I stated earlier, CurrentControlSet is the correct place to make such changes.

Let me give you ChatGPT's nice explanation (which, I assure you, I already knew):

When making changes to the Windows registry, it's generally better to update CurrentControlSet rather than ControlSet001. Here's why:

1. CurrentControlSet: This key points to the control set that Windows is currently using. It is a symbolic link to the control set that was chosen at system startup. Any changes you make here will affect the current session and subsequent boots, assuming no failures occur.
   
   
2. ControlSet001, ControlSet002, etc.: These are backups of various system control sets. Windows maintains multiple control sets for recovery and troubleshooting purposes. For example, if the current configuration fails, Windows can revert to a previous, working control set. ControlSet001 might not always be the one in use, as it depends on how Windows manages these sets.

By modifying CurrentControlSet, you ensure that the changes are applied to the active configuration. However, it's crucial to be cautious when making registry changes, as incorrect modifications can lead to system instability or failure. Always back up the registry before making changes, and consider seeking guidance if you're unsure about a specific modification.

I stand corrected.

I tried to modify the key in question, as I posted just now and it is indeed protected and yet the other keys I tried and tested in Win10 and Win 11 are editable with no protection and I did try a lot of them?

Although, I am sure I did try the posted key on at least one of my machines and the modification succeeded. Of course I immediately reversed the modification, but saw no warning/error at all?

The reg file succeeded in the VM and the desired effect was observed, I have not applied it to my main machines though.

So tell me, how is it possible that the reg file is able to override the protection without any intervention?



And no, I have not made any changes to these permissions and these are for CurrentControlSet.

trumpy81 said:

I stand corrected.

I tried to modify the key in question, as I posted just now and it is indeed protected and yet the other keys I tried and tested in Win10 and Win 11 are editable with no protection and I did try a lot of them?

Although, I am sure I did try the posted key on at least one of my machines and the modification succeeded. Of course I immediately reversed the modification, but saw no warning/error at all?

The reg file succeeded in the VM and the desired effect was observed, I have not applied it to my main machines though.

So tell me, how is it possible that the reg file is able to override the protection without any intervention?

View attachment 78665

And no, I have not made any changes to these permissions and these are for CurrentControlSet.

Click to expand...

Applying the reg file as only an Administrator will definitely fail if the the target is restricted to TrustedInstaller.

I think there's a simple explanation.

The "1" key, as shown in your screenshot there, may not have already existed. It did not exist on most machines I checked. In that case, RegEdit can create the new "1" key, without TrustedInstaller permissions, because the parent "Overrides" key is never protected.

In some cases though, the "1" does exist, is not protected, but the "248140940" key is protected. And in other cases, the "248140940" is found under the "0" key, which appears to always be protected.

I think that explains why sometimes the registry file can be used directly and other times will require a tool like PowerRun to get TrustedInstaller privileges. And I think the "248140940" appearing under different subkeys will add to the complications.

I suspect that the result, of getting the older Explorer layout, is a side-effect of something gone wrong, as opposed to a direct, intended change. As I mentioned, I had success at making the change on only one of three test machines. I cannot get the new Explorer back on that one machine. I've done the SFC and DISM commands and a Windows Repair Install using the latest ISO. It looks like I'll have to do a complete fresh Windows install to get the new Explorer back. YMMV.

BTW, did you try reverting the registry change to see if you can get the new Explorer back (just for curiosity)?

P.S. If we are to look for a more generalized solution, I think it would involve using ViveTool because the Overrides key is what it's designed for (i.e. it must deal with the feature key possibly being under different numbered keys) and I would think it must have the ability to self-elevate to gain TrustedInstaller access (TBD).

The permissions I posted above are for the '1' key on my main Win11 machine and checking the "248140940" subkey itself shows the same permissions that you posted earlier.

I have not applied the reg file to this machine or edited the registry, so the key obviously exists on this machine at least, in Win11, but the "248140940" subkey is protected as you stated.

LesFerch said:

BTW, did you try reverting the registry change to see if you can get the new Explorer back (just for curiosity)?

Click to expand...

I only made the modification in the VM and I did not try reverting to the new layout.

I restored the VM to the previous state from a backup and checked for the existence of the key in both locations and it did not exist. I also noted that File Explorer had not changed to the new layout and I noted that subkeys 2 & 6 that exist on my main machine, do not exist in the VM.

I updated the VM and installed KB5032190, KB4023057, KB890830 & KB5032007 and observed that File Explorer has changed to the new layout, but adding the reg file did not change things this time and the new layout remains?

I checked for the modification in both locations and it was applied to both locations.

These are the permissions from the VM:


I manually edited the keys in both locations and they are NOT protected.

Strange...

Yeah, that's consistent with my observations. I'm going to spend some time experimenting with ViveTool. For now, it looks like EP stands as the only reliable method to switch back and forth between the new and old Explorer layouts.

Yeah I think you may be right. I have certainly seen some inconsistencies here now.

Thanks for the education though, it is always welcome

@trumpy81

Doh! It's all documented here:


To go back to the earlier address/search bar layout:

Vivetool.exe /disable /id:40950262

And then restart.

@LesFerch

Thanks for that.

I don't normally use tools like this, as they introduce too many unknowns for my liking. Who knows what modifications are being made?

At least this tool offers a disable/re-enable option.

I will take it for a spin in a VM and see how it performs.

Wish me luck ... lol

trumpy81 said:

@LesFerch

Thanks for that.

I don't normally use tools like this, as they introduce too many unknowns for my liking. Who knows what modifications are being made?

At least this tool offers a disable/re-enable option.

I will take it for a spin in a VM and see how it performs.

Wish me luck ... lol

Click to expand...

The end result is that it makes the correct changes in the OverRides key, but indirectly via the FeatureManagement API. The source code is quite a lot to digest (still studying it) but monitoring the results, I only saw the aforementioned key touched.

@LesFerch

So, I fired up another freshly updated VM and attempted to disable the new File Explorer with tabs.

I opened CMD as admin and after entering ViVeTool.exe /disable /id:40729001 I recieved a message stating that the command succeeded.

I then rebooted the VM and re-opened File Explorer. Unfortunately, there was no visible change at all and tabs remain

From the link you posted, there is another link showing how to disable tabs, but one of those id's does not exist in my present query list, so it will obviously not work.

So it seems I am stuck at this point, any suggestions?

trumpy81 said:

@LesFerch

So, I fired up another freshly updated VM and attempted to disable the new File Explorer with tabs.

I opened CMD as admin and after entering ViVeTool.exe /disable /id:40729001 I recieved a message stating that the command succeeded.

I then rebooted the VM and re-opened File Explorer. Unfortunately, there was no visible change at all and tabs remain

From the link you posted, there is another link showing how to disable tabs, but one of those id's does not exist in my present query list, so it will obviously not work.

So it seems I am stuck at this point, any suggestions?

Click to expand...

I tested ViVeTool.exe /disable /id:40729001 on all three of my Windows 11 test builds. Two of them switched to the pre-App SDK version of Explorer (with tabs but address bar below tool bar) and one of them (Canary) switched all the way back to the Windows 10 Explorer.

All three switched back to the new Explorer with ViVeTool.exe /enable /id:40729001

What's the Windows version and build number of your VM? I can try to build the same and see what happens.

The VM version is as listed below, but I am about to update the VM to 23H2 (it has finally been offered). I will try ViVeTool again after the update has completed. I can revert to 22H2 by restoring from backup if I need to.



After the update to 23H2:



I ran ViVeTool again and it reported success once again, I then rebooted.



Again, there was no change at all. Of course, I did not really expect there to be any change after the update, as the 23H2 version is no longer compatible with the published settings for ViVeTool.

Out of curiosity, I tried ViVeTool.exe /enable /id:40729001 and rebooted once again, but there was no change at all and again, no change was expected.

I think your semi-success/success is down to the versions you have installed. If you were to update your machines to 23H2, then they would all fail consistently as far as I can tell, at least until the correct procedure in ViVeTool is discovered.

Out of curiosity, I tried disabling 37634385 which is listed as [37634385] (TIFE) (Tabs In File Explorer perhaps???). The command succeeded and a reboot ensued. The result was a complete non working File Explorer and even the main explorer.exe shell would restart when attempting to open File Explorer.

Re-enabling the ID restored File Explorer to a working condition, so that's good.