How to query the dword for Windows 10 Search Highlights

Topic

New Reply

At the bottom of Ten Forums – Tutorial on Search Highlights, there is a comment by farag2. The comment provides two ‘New-ItemProperty’ commands to change the dword to 0. I assume that these are Powershell commands, but I don’t know for sure.

If so, is there a command like these that would query the dword, i.e., not set it, but query it to see what the setting is?

I ask because Search Highlights is enabled in GP and it is checked in Taskbar-Search, but the highlighting feature does not show up in the Search box, like it should. I am wondering if I can query the dword in the Registry without actually going in and looking.

I have the same GP setting and Taskbar-Search setting on another device and the highlighting feature DOES show up, as expected.

Reply | Quote

Replies

WCHS wrote:

The comment provides two ‘New-ItemProperty’ commands to change the dword to 0. I assume that these are Powershell commands, but I don’t know for sure.

Yes, they are PowerShell.

WCHS wrote:

If so, is there a command like these that would query the dword, i.e., not set it, but query it to see what the setting is?

You can use Get-ItemPropertyValue -Path <registrypath> -Name <valuename> to query the DWORD value of specific settings.

So, in the examples you gave, try these 2 queries in a PowerShell console:

Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\DSB -Name ShowDynamicContent

Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings -Name IsDynamicSearchBoxEnabled</pre

Note that if the value name you’re querying doesn’t exist then you’ll get an error (a):

For this reason it’s often a good idea to use Get-ChildItem -Path <parent key> instead.

For example, the following command (b):

Get-ChildItem -Path 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\'

… should show you whether a DSB sub-key exists (c) and what values are stored in it (d).

Hope this helps…

Reply | Quote

Erratum:

I’ve just noticed that the second query using Get-ItemPropertyValue in my previous post has some characters appended to it incorrectly.

It should show:

Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings -Name IsDynamicSearchBoxEnabled

Hope this helps…

Reply | Quote

Further info:

The two sub-keys and their registry value pairs (name, data) do not exist by default… so you’ll get an error running either of the two Get-ItemPropertyValue queries above and neither will show in the Get-ChildItem query either.

This is probably best shown as Before and After screenshots of the PowerShell console (and RegEdit) results to demonstrate.

PowerShell console results *before* any changes (default):

You will need to make a change to Taskbar > Search > Show search highlights for the sub-keys and their respective value pairs to be created. Only then will the DWORD data values show.

PowerShell console results *after* any changes:

(I have screenshots of RegEdit before and after as well… but I can’t include them in this single post due to this forums’ restrictions on how many attachments are allowed per post.)

I note that OP hasn’t made any subsequent posts in the last few days so I’ll leave it here.

Hope this helps…

Reply | Quote

To @rick-corbett:
I didn’t turn on ‘Subscribe’ when I posted, thinking that since I opened the topic, I would be automatically subscribed, so that’s why you haven’t heard back from me sooner.

Let me read your posts and then I’ll reply.

Reply | Quote

Problem Machine: Toolbar Context Menu>Search settings
In Search settings, I’ve been checking and unchecking the ‘Show search highlights’.. Currently, it is checked. Notice that ‘Open on hover’ is greyed out and NOT checked. (yellow square).

Problem Machine: GP Setting for Search
I’ve been Enabling and Disabling “Allow search highlights.” Currently, it is Enabled, which I think means that the Search settings are supposed to show up in the Toolbar Context Menu. As indicated in the image above, ‘Search’ is expanded to reveal the Search settings:

So, here are the results of those 3 PowerShell commands:
Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\DSB -Name ShowDynamicContent

ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings -Name IsDynamicSearchBoxEnabled

See next post for Get-ChildItem and more

Reply | Quote

continuation of more to add to #2534120

I have another laptop (same vendor {Dell}, newer model) with the same Search settings and the same GP Search ‘Allow search highlights’ Enabled. The only difference in the Toolbar context menu Search settings is that ‘Open on hover’ is bright, but not checked.

And this is what I see on that machine in the Taskbar Search Box:

And this is the result of the Get-ChildItem command on that machine:

Here there is no “DisabledReason:DisabledbyPolicy” and there is a “UseDefaultGleam:0”. “OpenOnHover is set to 0”, which corresponds to the Taskbar Search setting for it.

Maybe, if I could get rid of “DisabledReason:DisabledbyPolicy”, initiate a “UseDefaultGleam” and set it to “0”, and set “OpenOnHover” to “0”, the problem machine would behave the way it should?? If so, I’d like to use PS commands to do it.

Reply | Quote

They got posted out of order. This is the order in which to read them:

#2534106

#2534120

#2534126

Reply | Quote

continuation of #2534106

Get-ChildItem -Path ‘HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\

I think this Powershell output tells me that the Registry says that ‘Show Search Highlights’ is checked, right? If so, this is actually the case in the Toolbar context menu settings for Search. I also think it tells me that the Registry says that ‘Open on hover’ is checked, as well, but, actually, in the Toolbar context menu settings for Search, it is greyed out and NOT checked (yellow square). There seems to be another problem here, as well, since there is a “DisabledReason:DisabledbyPolicy” Say What??? What has been disabled by policy? And where in GP was whatever disabled?

The Registry says that ‘Show Search Highlights’ is checked and GP settings have Enabled “Allow search highlight”, but
the Search Box is not showing any highlighting. Does this have something to do with the “DisabledbyPolicy” in the Registry?

See next post for information about my other laptop, which works right.

Reply | Quote

WCHS wrote:

Does this have something to do with the “DisabledbyPolicy” in the Registry?

OK, you’ve expanded your original query significantly and it’s becoming a little hard to follow. (To be honest, it would be far easier to just use the Registry Editor… but, whatever.)

IMO the screenshot result in post #2534120 is showing that the setting for registry value name DSB has relinquished control from a DWORD data value in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\DSB to a policy sub-key within HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Feeds.

I suspect the sub-key is also a DWORD value named DSB but haven’t tried to duplicate your results. However, you can rewrite the previous queries to point instead to the policy keys within the HKLM hive to first discover their contents (using Get-ChildItem) then use Get-ItemPropertyValue to check their value names/data.

A machine-wide policy setting will override a current user setting every time, irrespective of the user group that the signed-on user is in. That’s its whole purpose.

(I suspect that there may be a way around this restriction on workgroup devices by invoking TrustedInstaller [i.e. my TI status trumps your System status] but I haven’t yet had to try this. I have no idea about domain-joined devices where the managed landscape is fundamentally different… I was always desktop support, not domain admin.)

Hope this helps…

Reply | Quote

Rick Corbett wrote:

I suspect the sub-key is also a DWORD value named DSB but haven’t tried to duplicate your results. However, you can rewrite the previous queries to point instead to the policy keys within the HKLM hive to first discover their contents (using Get-ChildItem) then use Get-ItemPropertyValue to check their value names/data.

They are a little hard to follow, because 1) I couldn’t put more than 4 images in a post, although I needed to post 9. So, I broke up the post into 3 parts. But, when posted, the order of the 3 posts was 1, 3, 2 instead of 1, 2, 3. In a subsequent post at I outlined the reading order of the posts, so that you could follow without twists and turns.

In regard to the quote above, if there’s not enough info in those images (viewed in the order 1, 2, 3) what would the rewritten queries look like? I am reluctant to get into the Registry because I’ve never done that before and I know that monkeying around with it when you don’t know what you are doing can cause havoc.

A PS query is harmless, right? If it queries correctly, you get the info you are looking for. This is better than digging in the Registry to find the info, at least for me, because I am Registry-lame and injury prone.

Reply | Quote

Rick Corbett wrote:

A machine-wide policy setting will override a current user setting every time, irrespective of the user group that the signed-on user is in. That’s its whole purpose.

I am wondering if the value of the ‘DisabledReason’ property as ‘DisabledPolicy’ is (#1) the reason that Search highlighting is not highlighting, even though ‘Show search highlights’ is checked in the Taskbar ‘Search’ and set to be allowed in GP and (#2) the reason that ‘Open on hover’ is greyed out.

Search highlights was rolled out in waves and maybe the ‘DisabledReason’ property was how my device wasn’t eligible for any of the first waves. But, I think everyone’s device is eligible by now. Maybe a device eventually became eligible via a Windows Update that got rid of the ‘DisabledReason’ property altogether. And if that’s the case, my device, although always current with Windows updates, never had a chance to be eligible because the ‘DisabledReason’ property was never eliminated. That’s my speculation on why Search Highlights is not working and why ‘Open on hover’ is greyed out. The actual settings in the Taskbar, in GP, and in the “Feed” query don’t jibe with what I am seeing: no highlighting and no hovering. That’s why I think the ’DisabledReason’ property is the cause of this.

Reply | Quote

A question of my own… and a suggestion.

Q – If you have two devices and Search Highlights works as you want it to on one but not on the other… have you considered just copying the relevant registry settings from the working one and merging them on the none-working one?

I understand your reticence about the registry… but IMO using PowerShell is overkill for what’s required and is also prone to mistakes. Besides, you would still be working with the registry but using an overly-complex method of accessing it via PowerShell.

There’s been a lot of ‘here be dragons’ warnings over the years about not touching the registry. IMO this hasn’t been particularly helpful… a lot of Windows settings under the hood can *only* be changed via the registry.

IMO the Registry Editor is the most appropriate tool to use here, not PowerShell. If you restrict yourself to only working on the registry keys that pertain to Search Highlights *and* export a copy of the keys before making changes then I cannot see how you can possibly go wrong.

Suggestion – I can attach the relevant registry settings (and *only* the relevant registry settings) as a .REG file. You’ll be able to open the .REG file in Notepad and read the settings (and any included comments). I can add instructions how to merge the .REG file into the registry. This will save you even having to open the Registry Editor on either device. Would this help?

Reply | Quote

I forgot to mention… a screenshot shows a machine-wide setting has been enabled in the Local Group Policy Editor (LGPE).

This changed setting has had the effect in the registry of creating a new Windows Search key under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows and added an EnableDynamicContentInWSB DWORD entry:

This is why the PowerShell query Get-ChildItem -Path ‘HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\ shows a result of DisabledbyPolicy for Feeds > DSB.

You can check this policy setting yourself without opening the Registry Editor by using the following PowerShell query:

Get-ChildItem -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\'

This will show a result similar to this screenshot:

A machine-wide group policy setting within the HKEY_LOCAL_MACHINE registry hive overrides related settings within the HKEY_CURRENT_USER registry hive. It looks like this LGPE setting has had an unexpected/unintended side-effect of disabling the Open on hover entry in the Toolbar Context Menu > Search dialog.

You will need to open the LGPE again and reset that entry from Enabled back to the default Not Configured. Once you’ve done that and applied the change, restart the device then re-run the following query:

Get-ChildItem -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\'

The result should no longer show the policy entry for Windows Search. This is probably all you have to do to resolve your issue on the problem machine.

Hope this helps…

Reply | Quote

Rick Corbett wrote:

The result should no longer show the policy entry for Windows Search. This is probably all you have to do to resolve your issue on the problem machine.

Here are the results of that Get-ChildItem command — one with ‘Allow search highlights’ Enabled and the other with it Not configured.
You are correct about the ‘EnableDynamicContentInWSB’ — the property has a value of ‘1’ in the former, but the property isn’t even listed in the latter.

BUT, in BOTH policies for ‘Allow search highlights’ (Enabled or Not configured), the Taskbar Search settings are the same — ‘Show search highlights’ is checked AND ‘Open on hover’ is greyed out. And in both policies, there is no highlighting in the Taskbar Searchbox.

Reply | Quote

That’s a bit strange. I did the same on my test machine and ‘Open on hover’ was enabled again when I changed ‘Allow search highlights’ from ‘Enabled’ to ‘Not configured’ in the LGPE.

Q. After changing ‘Allow search highlights’ from ‘Enabled’ to ‘Not configured’ in the LGPE, did you restart the machine? (Policies changed using the LGPE *should* be refreshed automatically when the ‘Apply’ button is clicked… but a restart is a failsafe method of forcing the registry to be read in its entirety.)

Q. Was ‘Allow search highlights’ the only LGPE entry that was changed from its default ‘Not configured’ to ‘Enabled? (… in case another related policy is in effect.)

Q. Can you run the following two queries again (now the ‘Allow search highlights’ entry has been changed in the LGPE)?

Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\DSB -Name ShowDynamicContent

Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings -Name IsDynamicSearchBoxEnabled

Removing the LGPE policy should show the following results for each query:

Q. If I attach a .REG file of how the taskbar settings for ‘Search Highlights’ *should* be configured with default values, are you happy to double-click on the file and merge it into the registry? (This will prevent any need for you to open the Registry Editor either on your ‘working’ machine to export settings or on the non-working machine.)

Reply | Quote

Yes, I restarted and yes, the ‘Allow search highlights’ was the only thing I have changed. Here is the order of my efforts listed as Step 1 (done Feb 13, 5:17 pm), Step 2 (done Feb 13, 5 :35 pm), and Step 3 (this post), which you asked me to do:

Step 1. ‘Allow search highlights’ is ‘Enabled’: Image #1 and Image #2 are at #2534106

Step 1, image #1 :Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\DSB -Name ShowDynamicContent Result is ‘1’

Step 1, image #2:ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings -Name IsDynamicSearchBoxEnabled. Result is ‘1’

Step 1, image #3:at #2534120.
Get-ChildItem -Path ‘HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\ : ‘DisabledReason’ is set to ‘DisabledByPolicy’.

Step 2. I posted the results of 1 other PS command: Get-ChildItem -Path ‘HKLM:\SOFTWARE\Policies\Microsoft\Windows\’. I ran it twice, the 1st time with ‘Enabled’ and the 2nd time with ‘Not configured’. The results are at #2534432.

a. Step 2, image #1: ‘Allow search highlights’ is ‘Enabled’: ‘EnableDynamicContentInWSB’ has a value of ‘1’

b. Step 2, image #2: ‘Allow search highlights’ is ‘Not configured’ and a restart: There is no information about ‘EnableDynamicContentInWSB’ at all.

Step 3. ‘Allow search highlights’ is ‘Not configured’: Now I am posting the results of the same 3 PS commands as those in Step 1:
Step 3, image #1:Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\DSB -Name ShowDynamicContent

This is the same as the result in Step 1, Image #1, when the setting was ‘Enabled’

Step 3, image #2:ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings -Name IsDynamicSearchBoxEnabled

The is the same as the result in Step 1, Image #2, when the setting was ‘Enabled’

Step 3, image #3. You didn’t ask me to run this PS command, but I thought I would anyway, to see what resulted.
Get-ChildItem -Path ‘HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\

Nothing seems to be happening with this command, maybe because ‘Allow search highlights’ is ‘Not configured’??

Reply | Quote

Here’s the screenshot of the Get-ChildItem -Path ‘HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\’ command with the ending apostrophe —
when ‘Allow search highlights’ is ‘Not configured’. It’s the same as the one where the ‘Allow search highlights’ is ‘Enabled’. No surprise, here.

========================================

Rick Corbett wrote:

This means that there should have been no need to change the default ‘Not configured’ setting to ‘Enabled’… they both should have exactly the same effect.

‘Not configured’ and ‘Enabled’ have the same effect, but though the effect is the same, the effect is not the right effect.
========================================

Rick Corbett wrote:

I asked you to change this back from Enabled to Not configured… although this should have made no difference.

It actually did NOT make a difference. For ‘Not configured’, the two DWORDS are ‘1’ and ‘Feed’ has a ‘DisabledByPolicy’. Same goes for ‘Enabled’: the two DWORDS are ‘1’, and ‘Feed’ has a ‘DisabledByPolicy’.

=========================================

Rick Corbett wrote:

AFAIK the only thing that could have stopped Search Highlights working is a policy set to Disabled by either 1) manually editing the registry using RegEdit, 2) a .REG file, 3) the Local Group Policy Editor or 4) a third-party tweaking utility.

1) I have never been in the Registry at all. 2) I have never run a .REG file. 3) The only LGPE change I made for Search was changing ‘Allow search highlights’ from ‘Not configured’ to ‘Enabled’ right before I did a feature update to 22H2 on Feb 3. It had always stayed at ‘Not configured’ before that and wasn’t working right then, either. 4) I use 7+ Taskbar Tweaker, installed June, 2021, when I was on 20H2. But, it was installed on the “good machine” at the same time in the same Win 10 version.
======================================
Corrupt-profile?
Over time, I have noticed some differences in how the two machines behave. One that quickly comes to mind is what the Search flyout looks like when searching for an app. In the two images below, both are searching for the ‘Defragment and Optimize Drive’ app. I’ve always thought this difference was due to the fact that the “good” machine was newer than the “bad” machine and that they are not completely identical — same vendor, both x64, but different models, processors, BIOS, system SKU, etc,

On this “good” machine, there’s a right and left panel. The right panel lists options up front.

versus

On this “bad” machine, I have to right-click on the app icon to see the options.

I’ll see what happens when I create a new user account on the “bad” machine. I might not be able to do this until Friday, though.

Reply | Quote

Moderator Edit: See #2534799 and #2534812.

Reply | Quote

If it might be easier to put your comments on a word document and attach them rather than post in the forum?  Bbpress can’t quite handle all of the highlighting, formatting and everything else you are trying to do here.

Susan Bradley Patch Lady

Reply | Quote

Susan Bradley wrote:

Bbpress can’t quite handle all of the highlighting, formatting and everything else you are trying to do here.

It seemed to handle the highlighting OK in post 2534777, but it is not doing well with an ordered list inside an unordered list, although it worked when I tested it out at 2534813 in the Testing Forum.

I’ve taken your suggestion and have put the list in a pdf file and attached it.

Thanks for helping me out with this!!

Reply | Quote

Actually it didn’t work. The code in 2534813 broke the thread the same as the one in your previous thread 2534786 because you made the same coding errors in both. It only looks right because I corrected the coding errors in both as explained in 2534799 in your first attempt. And you made the same errors again in the post in this thread that was removed.

Please look at the correction so you know what the problem was. It may help you in your quest to learn coding.

Reply | Quote

I have some questions about the .REG file. See the attachment.
Questions-about-the-REG-file

Reply | Quote

WCHS wrote:

Nothing seems to be happening with this command, maybe because ‘Allow search highlights’ is ‘Not configured’??

The >> in the result just shows that the console is waiting for more input. Looks like you missed off the closing single quote.

As for ‘Allow search highlights’, remember the description in the Local Group Policy Editor?

“Enabling or not configuring this setting turns on search highlights in the taskbar search box and in search home.”

This means that there should have been no need to change the default ‘Not configured’ setting to ‘Enabled’… they both should have exactly the same effect.

To recap, AFAIK there’s only two settings which control the display of Search Highlights… ShowDynamicContent (under Feeds > DSB) and IsDynamicSearchBoxEnabled (under Search Settings).

Step 3 of your last post shows the results of 2 PowerShell queries which confirm that both these settings have DWORD values of 1, i.e. enabled.

AFAIK the only thing that could have stopped Search Highlights working is a policy set to Disabled by either 1) manually editing the registry using RegEdit, 2) a .REG file, 3) the Local Group Policy Editor or 4) a third-party tweaking utility.

You’ve made it clear that you’re not au fait with the registry (which is fair enough), so that rules out 1) RegEdit and 2) a .REG file. You *have* used 3) the Local Group Policy Editor but only to set a machine-wide setting of Search > Allow search highlights > Enabled. (There is no corresponding setting in User Configuration, only Machine Configuration.) I asked you to change this back from Enabled to Not configured… although this should have made no difference.

That leaves 4) a third-party tweaking utility. Have you by any chance used one?

Actually, there is another possibility… but it’s fairly rare – a corrupt user profile. The best way to check for this is to create another account and sign in with it to check whether the Search Highlights issue still occurs. If it does then it’s most likely a machine-wide issue. If, however, the issue isn’t present then this means it’s a user profile issue.

It looks like the next step is to compare the registries of both your working and non-working machines. I’m working on a list of commands to run that will avoid having to use RegEdit or PowerShell.

Hope this helps…

Reply | Quote

WCHS wrote:

I have some questions about the .REG file. See the attachment.

I understand your reticence about the registry as a whole. (There’s a learning curve.) If I end up supplying a .REG file then I’ll also provide instructions about using it.

(The Local Group Policy Editor is just a front-end to selected areas of the registry… so also needs to be handled with care.)

Right this moment I’m trying to think of the easiest way to compare the registries of your working and non-working machines… without actually opening RegEdit (the registry editor). 🙂

It’s doable… and I’m testing a solution at the moment. It just takes a bit of work because, unfortunately, Microsoft doesn’t keep related settings together in the registry… there’s no single place to go to see all the settings related to, for example, just the taskbar. So far I’ve found 8 registry ‘branches’ which can contain keys and sub-keys related to Search Highlights, the Search bar and/or taskbar settings.

 

Reply | Quote

WCHS wrote:

I’ll see what happens when I create a new user account on the “bad” machine. I might not be able to do this until Friday, though.

OK, I’ll wait until you post again after creating another user account.

In the meantime I’ll have a quick look at 7+ Taskbar Tweaker, although its webpage suggests its tweaks are not implemented as policies (only settings in  HKEY_CURRENT_USER\Software\7 Taskbar Tweaker) and the screenshot doesn’t show anything related to Search or Search Highlights.

I’ve finished testing a BAT file that will export result from both machines for comparison. If the new user account doesn’t help then I’ll post the BAT file and instructions.

Hope this helps…

Reply | Quote

Update: I’ve had a quick look at 7+ Taskbar Tweaker. It works by injecting DLLs into existing system processes (which can sometimes cause unreliability and stability issues).

You used a feature update to go from 20H2 to 22H2 rather than a clean-install. If you installed 7+ Taskbar Tweaker on both machines whilst 20H2 then there’s a good chance registry changes were added by it to HKEY_CURRENT_USER\Software\7 Taskbar Tweaker and are still there. However, because of the way it works, it doesn’t look like they’ll be used unless 7+ Taskbar Tweaker is actually running in the background.

Apps that are invoked automatically at startup are usually recorded in the \Software\Microsoft\Windows\CurrentVersion\Run keys of either HKEY_CURRENT_USER and HKEY_LOCAL_Machine so can easily be reported on. However, they can also be called from shortcuts in either user and/or system startup folders… and that’s less easy to script in a BAT (with my poor BAT-scripting skills).

I’m going to suggest you use a small, free, portable utility like Sysinternals/Technet’s Autoruns to check whether 7+ Taskbar Tweaker is running from startup. It will be much quicker than me trying to add the same functionality into my BAT file, should it need to be used.

Hope this helps…

Reply | Quote

Info for today:
I think 7+ Taskbar Tweaker is working in the background. I say this because I see its effect when I start up or restart because it’s set to reduce the space between icons on the Taskbar. Also, anytime I hover over an icon on the Taskbar (Word or Excel or Firefox or Quick Access/File Explorer), there’s a popup that lists the open documents controlled by that program. It’s running with the same settings on the “good” and the “bad” machine.

P.S. I just checked the settings for 7+ Taskbar Tweaker and it IS set to run at startup. That is the default and I’ve never changed it.

But, I did just now uncheck ‘run on startup’ and then restarted. Then I looked to see what the Taskbar Search Settings would look like. No change, problem still there: ‘Show search highlights’ is checked and ‘Open on hover’ is greyed out. No highlighting of the Taskbar Searchbox shows up. But, maybe this is NOT a good test because if this problem was created by 7+ Taskbar Tweaker by (inappropriately) changing things in the registry, maybe the inappropriate changes are still there, even though it not now working in the background.

Planning on getting back to you Friday after I set up a new user account.

Also, I keep getting unsubscribed to this topic, so I don’t get e-mails that there’s been a reply. I’ve now let Susan know about this. But I’ve also just re-re-re-re-subscribed. Nevertheless, I will keep checking and won’t depend on an e-mail notice.

Reply | Quote

OK, today is Friday and I have created a new account. In that new account,
I clicked on the Taskbar and hovered over ‘Search’. Here are the search settings that popped up!!

Reply | Quote

I thought I would look at the Search Flyout results when searching for an app on the new account on the “bad” machine. It looks like it does on the “good” machine. It doesn’t look like the Search Flyout in my regular account on the “bad” machine. My regular account is an administrative account and I log in with my Microsoft Account. The new account is a standard, local account

new account, standard local, “bad” machine
I didn’t set an accent color in this new account, so the left panel is some default color.

versus

regular account, administrative-log-in-to-Microsoft-Account, “bad” machine

I first noticed this ‘odd’ result on the Search Flyout on the “bad” machine in November, 2021. I know this because I had asked about it at How can I change configuration. I was in 21H1 at the time. I had feature-updated to 21H1 about 3 months before that on August 5, 2021 by setting TRV to 21H1.

Search Highlights was introduced in late March 2022 and I was on 21H2 at the time. I had feature-updated to 21H2 about 2 months before that on January 31, 2022 by setting TRV to 21H2.

So, the Searchbox result when searching for an app predates the Taskbar Search Highlights problem.

Reply | Quote

So… new account on the ‘bad’ machine shows the same grayed-out Open on hover control within Taskbar > Search, suggesting – at first glance – that it’s *not* a profile issue but, instead, a machine-wide issue.

Unfortunately, looking more closely at your new post, it appears that you’re not actually comparing ‘apples’ to ‘apples’… either between sign-in accounts nor machines.

1. Your default account on ‘bad’ is apparently a Microsoft Account (MSA) in the Administrators group (probably the first account created during OOBE), yet the new account you created on ‘bad’ is apparently a local standard account… correct?

2. You now mention a taskbar ‘flyout behaviour’ visual display anomaly, present for 15 months (since November 2021)… correct?

3. You’re running third-party software on ‘bad’ (and ‘good’) which injects its DLLs into running system processes to manipulate the taskbar… but have no idea what changes it makes under the bonnet other than its visual display effects (nor whether the installations/settings/behaviour on each machine are identical)…. correct?

4. You haven’t mentioned how you sign in to ‘good’, whether MSA vs local (or standard account vs administrators group). It matters for a number of reasons, not least that you’re using third-party installed ‘taskbar tweaker’ software which ‘fools’ the OS, often depending on how it starts and/or the privileges of the signed-in user.

Hmm… I’ll admit that I have absolutely no idea how to compare these two very disparate machine/account configurations effectively. It’s like asking why apples don’t taste like oranges, when the only common growing medium is soil… which may or may not be on the same farm, let alone the same orchard.

I’m stumped… I really can’t think of an effective way forward right this moment, apart from the very obvious (restore from backup, remove ‘taskbar tweaker’, clean install, etc.).

If anyone else has suggestions then please feel free to contribute…

Reply | Quote

No, the new account on the “bad” machine shows a bright ‘Show on hover.’ A checked ‘Show search highlights’ shows the highlights on the Searchbox. I can check the bright ‘Show on hover’ and it will show on hover. So, all in all, this new account on the “bad” machine is working exactly like it should.

1. Yes, on the “bad” machine, the default account is an MSA and I am the administrator (yes, first account created OOBE). The new account is a local account, standard account. On this new account a). the Search settings work the way they should; b) the Searchbox flyout, when searching for an app, has two panels in it.

2. Yes, I commented on this ‘odd’ searchbox flyout behavior on the “bad” machine in an earlier post. It started behaving oddly way back in Nov 2021, under 21H1. This is the odd behavior: when searching for an app, the flyout has one panel displayed, but it should have two panels. But, in the new account on the “bad” machine, the flyout has two panels, like it should.

3. 7+ Taskbar Tweaker is displaying identically on the “bad” and “good” machines. Installations on the the two machines were done in the same way, at the same time, same settings, same versions, etc.

4. I sign into the “good” machine on a local account as administrator. That was how it was set up OOBE. There’s only this one administrator account on the “good” machine.

If I need to make a new account on this “bad” machine so that it is an apple and not an orange, I could remove this new account and add another one, instead, that is tied to my MSA account. But, I don’t know if I can make it administrator, too — can there be more than one adminstrator account on a machine? Maybe, it’s not possible for the two accounts on the “bad” machine to both be apples.

I could uninstall 7+ Taskbar Tweaker on the “bad” machine to see what happens. But, if it did something to make the machine “bad”, would there will be something there is the Registry that didn’t get removed after uninstalling it? I know that sometimes when something is uninstalled, there’s sometimes stuff left behind.

Reply | Quote

Multiple accounts can be an administrator on Windows 10 or 11.

But if you can make an /additional\ set of backups now before trying it, one thing that fixes many problems is the “in-place upgrade” also called repair install of windows.  https://www.tenforums.com/tutorials/16397-repair-install-windows-10-place-upgrade.html

1 user thanked author for this post.

WCHS

Reply | Quote

Energy Saver wrote:

one thing that fixes many problems is the “in-place upgrade” also called repair install of windows.

I’ve read the Ten Forum link. It says there that “an in-place upgrade repair uses the same basic mechanism as when you upgrade.”

If this is true, then if something in Window 10’s code was causing Search Highlights to misbehave when 21H2’s KB5013942 introduced it, my Feb 5 Feature Upgrade to 22H2 should have fixed that. But, it didn’t. So, I don’t see that an in-place upgrade repair is going to do any better.

Reply | Quote

21H2 to 22H2 was an enablement package, not an upgrade.

Windows 11 Pro version 22H2 build 22621.1413 + Microsoft 365 + Edge

Reply | Quote

b wrote:

21H2 to 22H2 was an enablement package, not an upgrade.

I think my reply to this will take this discussion about my “bad” machine’s “Search Highlights” on a left turn. So, I’ve posted a new topic with questions at #2535722.

Reply | Quote

Energy Saver wrote:

“in-place upgrade” also called repair install of windows

An in-place upgrade will just muddy the water further, IMO.

Yes, it might possibly mitigate OP’s issues… but won’t explain what caused the issue in the first place.

If I read it right, OP wants an understanding and possible fix for the issue, not a ‘blat and start over’ solution.

I can understand this. If you can’t work out what went wrong in the first place, how are you ever going to ensure it won’t go wrong again?

Reply | Quote

WCHS wrote:

No, the new account on the “bad” machine shows a bright ‘Show on hover.’ A checked ‘Show search highlights’ shows the highlights on the Searchbox. I can check the bright ‘Show on hover’ and it will show on hover. So, all in all, this new account on the “bad” machine is working exactly like it should.

That suggests that the issue is corruption of the profile you normally use to sign in. (IMO it also suggests progress in your conundrum.)

Yes/No?

Reply | Quote

Rick Corbett wrote:

That suggests that the issue is corruption of the profile you normally use to sign in. (IMO it also suggests progress in your conundrum.)

Yes/No?

I agree with you here — on the point that maybe a bad profile is the culprit. And I am wondering how it might have become bad. I keep a pretty good record of app installations, changes I have made to things in the LGPE, Windows updates installed, the CUs that introduced features (e.g., the ‘News and interest’ feature and the ‘Search Highlights’ feature, for example), the CUs where those introduced features actually showed up on my machine, when Feature Updates/Upgrades/enablement packages (i.e..2xHx versions) were released, the date I installed them, things I did to prepare for them, the effect that they had on settings (if any).

I am wondering if it turns out that a bad profile IS the culprit, how that can be fixed.

But, first I want to try some other things to get a complete picture of this problem.

Reply | Quote

WCHS wrote:

But, first I want to try some other things to get a complete picture of this problem.

Another alternative is to uninstall 7+ Taskbar Tweaker on the “bad” machine, restart, and see if Taskbar Search settings work right. And see what the those 3 PS-commands in #2533036 produce.

I really depend on this utility, though, because I have never been able to navigate well between and among different app screens without it. When I click on an app icon on the Taskbar, it brings up an Explorer-like name list of documents that the app has open. I can re-order the list by dragging, I can close a document in the list, I can locate the last one I looked at easily, etc, etc. I can’t deal with thumbnails (they can look the same since one document may be a modification of another) – I have to know the names. Alt-Tab (or TaskView) can show me what I have open, and the title bars show the document names, but the thumbnail are not grouped by app – they are all over the place.

But, I can uninstall it just to see what happens and then re-install it.

However, I am not sure that uninstalling it would change it from a “bad” machine to a “good” machine. Maybe, there’s refuse left in the Registry that still makes it “bad”. Just where did this ‘DisabledReason: DisabledbyPolicy’ come from, anyway? See #2534120. Changing the LPGE setting for ‘Allow search highlights’ from ‘Enabled’ to ‘Not Configured’ did not convert it to a “good” machine (as you see in Step 3 of #2534777) — it is still ‘DisabledReason: DisabledbyPolicy’.

I think that is what is making the “bad” machine “bad”. And if so, if I could get rid of it, that might make the “bad” machine “good”. Changing the LPGE setting to ‘Not configured’ did not get rid of it; maybe, uninstalling the tweaker will.

Reply | Quote

I’m not making any assumptions but do you use Notepad++ and, more, importantly, its ‘Compare’ add-in?

I can post a rudimentary BAT file (I’m really not very good at programming) that will dump info from your ‘good’ and ‘bad’ device’s registries into .REG files that Notepad++’s Compare can parse for differences.

I have no idea whether this would be helpful… but I’m kinda running out of suggestions… (except perhaps not ever use third-party OS-diddler tools that use undocumented API interfaces… but that’s obviously open for discussion) 🙂 ).

Reply | Quote

Rick Corbett wrote:

I’m not making any assumptions but do you use Notepad++ and, more, importantly, its ‘Compare’ add-in?

I can post a rudimentary BAT file (I’m really not very good at programming) that will dump info from your ‘good’ and ‘bad’ device’s registries into .REG files that Notepad++’s Compare can parse for differences.

Yes, I have NotePad++ installed and I have used it a couple of times – but have not used the Compare add in. I also use Word and it has a ‘compare documents’ feature that I have used many times.

I take it that the .BAT file produces a .txt document? If so, I could use Word (which reads and saves .txt files) to compare them, since I am more familiar with that. Or I could better learn NotePad++ and use the Compare add in; I’m open to that, too.

The .BAT file will only ‘read’ the Registry, right, and produces a file of what it reads? (i.e. it won’t make ANY changes in the Registry)?

On the “bad” machine, I now have a second account (first, an MSA administrative account and now a local, standard account). On the “good” machine, I have only one account (only a local, administrative account). That difference (local on both, but standard on one and administrative on the other) is going to show up when comparing the two .BAT files, right? And maybe the critical differences won’t be easy to locate? Maybe,on the “good” machine, I should create a local, standard account? This way both machines will have a local, standard account. Then, on the “good” machine, make sure the Taskbar Search context menu settings are the same as they are for the administrative account. THEN, run the .BAT file on both the “good” machine and the “bad” machine?

Or alternatively, on the “bad” machine, delete the local, standard account and create a local, administrative instead. Then the two machine will both have a local, administrative account. THEN, run the .BAT file on both the “good” and the “bad” machine? Here is a schematic of what I mean.

I don’t know what the results of the .BAT file would look like (I will find that out, won’t I?) but if the comparisons can be made between the Registries on the two machines, I imagine that, especially if the local accounts are BOTH either standard or administrative), I might be able to isolate what pertains to the local accounts on both, and then see where the “good” machine and the “bad” machine differ.

Reply | Quote

A thought occurs to me… and here I have to admit to my complete avoidance (and thus ignorance) of ever signing in ever with an MSA (Microsoft Account).

What, if any, differences are apparent if you sign in to ‘good’ and ‘bad’ machines with local accounts instead of using an MSA to sign in?

[Disclaimer: I don’t ‘sign in’ to Windows, ever. I never use MSA. Instead, I try to adapt Windows 10 how it works best for me, no-one else.]

Reply | Quote

Back in in the fall of 2016 when I first opened this “bad” machine, I was really, really dumb about Windows 10. It came with 1607 (Anniversary Update). I just did what it told me to do when I opened it up (or maybe a DELL agent helped me set it up) and the MS Account route was what I got.

I just set up a local account on the “bad” machine two days ago, so I will have to play around with it to see what differences I see between the local accounts on the two. Right now they both perform the same with regard to the Taskbar Search context menu and with regard to the results of ‘Show search highlights” (ie., clicking on the left side of the Taskbar Searchbox versus clicking on the right side of the Taskbar Search box) with ‘Open on hover” checked or unchecked. So, I have focused just on this one feature and its similarities between the two machines, and not the differences.

One question here: does the LGPE editor limit itself to whatever account brings it up? I think not — on the contrary, I think it dominates both the local account and the MSA account. But, I want to be sure about this.

Reply | Quote

Is the ultimate aim here to get a slice of pizza on the taskbar without risking a peek at the registry?😕

Windows 11 Pro version 22H2 build 22621.1413 + Microsoft 365 + Edge

Reply | Quote

b wrote:

Is the ultimate aim here to get a slice of pizza on the taskbar without risking a peek at the registry?😕

The aim is to get a slice of pizza on the Taskbar Searchbox on a machine what won’t do it and to be able to hover over it – this despite LGPE’s ‘Allow search highlights’ being set to either ‘Not configured’ or ‘Enabled’. The “bad” machine won’t do it in its OOBE (2016) MSA, administrative account; that’s why it’s “bad”: ‘Show search highlights’ is checked, but nothing happens. ‘Open on hover’ is greyed out. But, it will do it in an added local, standard account when ‘Search highlights’ is checked. ‘Open on hover’ is NOT greyed out — you can check it and get the expected hoverable results. So the “bad” MSA machine is behaving like it should in this added local, standard account, but not behaving like it should in the OOBE account.

I have another machine which I am calling the “good” machine. It was set up OOBE as a LA (local account {not MSA}, adminstrative account. It is newer (2019). Currently, there is only this one account on the “good” machine. And it’s called “good” because when the LGPE setting is either ‘Not configured’ or ‘Enabled’, you get a slice of pizza and you can hover over it when the ‘Show on hover’ is checked; you can check this, because it’s not greyed out like it is on the “bad” machine.

In all other respects when comparing the “good” 2019 Windows/Pro machine and the “bad” 2016 Windows/Pro machine, the vendor is the same, LGPE settings are the same, the Windows versions are the same, the Windows updates are the same and occurring on the same date, the apps are the same and installed on the same date, the Desktops are the same, the data files are the same, etc., etc.

Reply | Quote

WCHS wrote:

So the “bad” MSA machine is behaving like it should in this added local, standard account, but not behaving like it should in the OOBE account.

I need to add this info: It has to do with whether +7 Taskbar Tweaker is installed on not)
On the “bad” MSA machine — the OOBE account (MSA, administrative), it is installed and I don’t get the slice of pizza (although the ability to show it is checked) and the hovering ability is greyed out, but the LGPE settings say these both are allowed to work. In the added local, standard account, the tweaker is not installed and I do get the slice of pizza and hovering ability (the LGPE setting is still the same, set to ‘Allow search highlights’ = get the slice of pizza).

On the “good” LA machine, which presently has only one account (local, administrative), the tweaker is installed and I get the slice of pizza and the hovering ability (LGPE setting is to ‘Allow search highlight’ = get the slice of pizza).

Reply | Quote

When search highlights arrived last spring the vast majority seemed to want the pizza slice du jour to disappear from the taskbar a.s.a.p.:

This Windows 10 Search Bar Feature Freaked People Out

Windows 11 has never had any graphics in the taskbar search box (even with search highlights on).

Is this quest for the holy grail pizza slice really worth all the effort?

I don’t understand your reluctance to look at the registry in any case.

Windows 11 Pro version 22H2 build 22621.1413 + Microsoft 365 + Edge

Reply | Quote

b wrote:

Is this quest for the holy grail pizza slice really worth all the effort?

I read all those comments early on. I’m just trying to understand what is not going right. While I might not want the slice of pizza, clicking on the search box when looking for an app is not working right, either. And whatever is causing the slice-of-pizza problem is causing the search-for-an-app flyout.

The search-for-an-app-flyout problem is described in #2535432.

Reply | Quote

b wrote:

I don’t understand your reluctance to look at the registry in any case.

#1. I don’t know where to look for the problem. It seems to be connected to the presence of ‘DisabledReason: DisabledbyPolicy’ on the “bad” machine and its absence on “good” machine, but where in Registry you would find this on the “bad” machine and correct it, I don’t know.

#2 And then, if I found it (even by happenstance), I wouldn’t know what to change it to or how to change it.

Ignorance on both of these fronts tells me ‘stay out of the Registry’

Reply | Quote

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/search-highlights-coming-to-windows-11/ba-p/3545572

Windows 11 also has search highlights.  I turned them off last week and had to find out they are in a TOTALLY different spot.

Susan Bradley Patch Lady

Reply | Quote

Susan Bradley wrote:

Windows 11 also has search highlights.

As I said, but no graphics in the taskbar search box (the original issue here).

Windows 11 Pro version 22H2 build 22621.1413 + Microsoft 365 + Edge

Reply | Quote

WCHS wrote:

The .BAT file will only ‘read’ the Registry, right, and produces a file of what it reads? (i.e. it won’t make ANY changes in the Registry)?

The BAT file makes *no* changes at all. Instead it exports settings from various areas of the registry (so you don’t have to open it in RegEdit) and also produces an HTML report of any Local Group Policies in effect.

Download the attached 2023_gather_info.zip file to your desktop, *right*-click on it, select Properties then unblock it.

Unzip the file to your non-working desktop, *right*-click on gather_info.bat and select Edit. This will open it (usually in Notepad) for you to read the contents.

• Section 1 just gets computername, Windows edition and version.
• Section 2 exports from HKCU the only 2 registry branches that *should* affect Search Highlights.
• Section 3 exports from HKCU a registry key that contains Search settings.
• Section 4 exports from HKLM a registry branch that contains machine-wide settings about Feeds, i.e. dynamic content used by Search Highlights (and News and interests).
• Section 5 is a local group policy check… it exports an HTML report that will show if any user- or machine-wide policy settings are in use.

When you’re happy with what you see, close the BAT file then *right*-click on it and choose Run as administrator… then click on the Yes button to accept the UAC prompt that will appear.

A CMD window will open briefly then close again, leaving 5 new files on the desktop:

You can open any of the .REG files in Notepad to assure yourself that you’re happy with the content. The HTML file can be opened in any browser… click on show all (in the top-right of the webpage) to expand all sections then look for sections labelled Computer Details and User Details. These correspond to the two sections in the Local Group Policy Editor.

Do the same on your working machine then compare the ‘non-working’ vs ‘working’ files for differences.

2023_gather_info

Hope this helps…

1 user thanked author for this post.

WCHS

Reply | Quote

Thanks. I’ll work through this and report back.
The instructions look very clear. It may take me a couple days.

I’m very curious to see what’s there and what I can find out.

By “non-working machine”, I take it that you mean the “bad machine” and by “the desktop”, you mean the desktop of MSA-login, administrative account, i.e. *not* the desktop of the local, standard account on the “bad” machine — *not* the account I added several days ago, right? And by “working machine” you mean the “good” machine, which currently has only *one* desktop, because it has only one account on it — the OOBE local, administrative account.

Won’t this be comparing apples and oranges? Did you see my post at 2435693, especially the schematic. The “What I have now” section shows that I have accounts that are like apples and oranges. The “What I need” section shows an added account either on the “good” machine or on the “bad” machine so that an apple can be compared to an apple or B. an orange can be compared to an orange. Or does the type of account that’s signed into *not* make a difference when doing the file comparisons?

A couple of things:
1. about the 5 files that will appear on the desktop. They correspond to the 5 sections you describe here, right? Four .REG files and one .html file, right?
2. I have lots of icons on my desktop. What does the icon of a .REG file look like – so that I can better spot it on the desktop?
3. What does the icon of an .html file look like to better spot that one?
Probably silly questions, but this will be my first experience with .REG files and .html files so I’d best ask and not worry about looking silly.

Reply | Quote

WCHS wrote:

By “non-working machine”, I take it that you mean the “bad machine” and by “the desktop”, you mean the desktop of MSA-login, administrative account, i.e. *not* the desktop of the local, standard account on the “bad” machine — *not* the account I added several days ago, right?

Yes, by ‘non-working machine’ I mean ‘bad machine’. By ‘desktop’ I mean the desktop of the account you’re signed in with, irrespective of whether you use a local account or a MSA. So, the idea is to compare the account you usually use on the ‘bad machine’ with the account you usually use on the ‘good machine’, not any other accounts you may have created for testing.

The .REG files on the desktop will look like this:

The HTML file will use an icon for whatever browser you use.

The easiest method IMO is to open File Explorer and choose Desktop in the left-hand navigation pane then select Details view then click on the column header to sort on the last files created.

WCHS wrote:

1. about the 5 files that will appear on the desktop. They correspond to the 5 sections you describe here, right? Four .REG files and one .html file, right?

Yes, the files correspond to the sections in the BAT file.

WCHS wrote:

Won’t this be comparing apples and oranges? Did you see my post at 2435693, especially the schematic. The “What I have now” section shows that I have accounts that are like apples and oranges.

It won’t matter that one account is in the administrators group whilst the other is a standard account. For all intents and purposes it’s just a comparison of the ‘Search Highlights’ registry settings primarily of the ‘current user’. However, it’s important to know whether there are any policies applied, and if so, whether it/they are ‘per user’ or ‘per machine’.

If you want, zip the files up into two zip files – one called ‘bad_machine’, the other called ‘good_machine’ – and attach them to a post. I’ll have a look at them for you. None of the exported info is private/confidential/identifying, with the sole exception of the 1st file which shows the computername… which you can remove if you want.

Hope this helps…

1 user thanked author for this post.

WCHS

Reply | Quote

Thanks for the latest info … I’ll get started. Everything is very clear (I think).
Ready for the ride!

Reply | Quote

I’ve downloaded 2023_gather_info.zip to my desktop and have removed the Mark-of-the-Web. I’ve unzipped it and have read the contents of the .bat file.

I’m wondering about the remark in the .bat file about the .html file that says ““rem Section 5 – LGPO policies (could potentially disrupt expected operation)”.

What does that mean … what is the “expected operation”? What would result if there were a disruption?

Thanks.

Reply | Quote

WCHS wrote:

I’m wondering about the remark in the .bat file about the .html file that says ““rem Section 5 – LGPO policies (could potentially disrupt expected operation)”.

What does that mean … what is the “expected operation”? What would result if there were a disruption?

I didn’t explain it very well in the brief BAT comment but it’s because many people are surprised by a regular side effect of using group policy (or some third-party tweaking tools)… the appearance of a banner and a sudden inability to use controls that have become grayed out.

For example:

Another surprise if you’re not careful is not finding the setting you want in the User area of the Local Group Policy Editor so changing it in the Machine area instead… then finding that the setting affects all accounts on the device, not just the account of the person who made the change.

The LGPE setting for Search Highlights is a good example… ‘cos it *only* exists in the Machine area, not the User area.

As a result I added the HTML report so it was easy to see whether any policy settings in effect were ‘per user’ or ‘machine-wide’… because otherwise the result could be unexpected.

That’s what I meant by “expected operation”, i.e. expecting x to happen… but finding out y and even z happens too, unexpectedly. So, a “disruption” would be any unintended side effects.

Hope this helps…

Reply | Quote

I am getting myself re-acquainted with Notepad++. I have both the ‘Compare’ and the ‘ComparePlus‘ plugins installed, and I’ve run .bat on the ‘bad’ machine.

What type of comparison should I be making when I post the comparison results?
1. I can post screenshots with the complete files compared. There would be 5 screenshots of ‘bad’ in the left panel and ‘good’ in the right panel (pertaining to the 4 .reg files and the 1 .txt file). Here is an example, to show what the screenshot would look like.

2. I could post screenshots of comparisons that show only the differences (ComparePlus will do this).
Here is a sample posting of a comparison showing only the differences in the two example files being compared; there are 10 different lines from the two files and the differences are all displayed.

3. I could forget about posting any screenshots and just zip all the files and put a link to the zipped folder in a post. You could run Compare and ComparePlus on them and see for yourself. (I would redact certain things, though, such as foldernames, filenames, complete URLs, my computername, my personalname, my email address {shows up on in the .html report file}, or anything else that might be compromising – that would be the case for the screenshots, too, )

4. I could just describe what I found to be informative and put a link to those zipped files in a post or alternatively, make screenshots, or do both. I say “found to be useful” because the 3hkcu_search.reg file , for example, has a lot of lines that pertain to app files. Much of that info is going to be intrinsically different between the 2 machines (mostly because the computername and personalname are different), and such things as AppID, AppPath, DisplayName, for MS apps like Word, Excel, Paint, and Acrobat Reader, as well as https AppIDs are *not* going to have any bearing on the problem, I don’t think.

I’m still going uphill on this ride. Now ready to run the .bat file on the ‘good’ machine and to start making comparisons with Notepad++ after that, probably with the ComparePlus plugin. I had read online that one feature of the ComparePlus Plugin is that you can make a pdf file of the differences, but I don’t see that option yet. It just came out in Oct, 22, so the choices for reporting back seem to me those listed above.

If you have other suggestions, please let me know.

Reply | Quote

WCHS wrote:

What type of comparison should I be making when I post the comparison results?

Screenshots won’t work.

The comparison technique is to load both the equivalent ‘bad machine’ and ‘good machine’ registry exports alongside each other in Notepad++ then quickly prune them to only compare differences that relate *specifically* to Search Highlights, Search and possibly Feeds… and nothing else.

No personal info, no apps, no foldernames nor filenames – none of that is relevant to your issue with Search Highlights.

It’s probably easier if you create good_machine and bad_machine zip files and attach them.

Hope this helps…

 

 

Reply | Quote

Rick Corbett wrote:

then quickly prune them to only compare differences

You had suggested the Compare plugin in #2535638. The newer plugin ComparePlus has an option to prune so that you are left with only differences (matches are hidden). Do you know about this new plugin — came out in Oct ’22, in Version 1.1.0 now {Nov 2, 2022}? I’ll use that new one — does a lot of work for you.

I’ll then cull out the personal-info-app-foldername-filename differences and make new files with only differences that relate *specifically* to Search Highlights, Search and Feeds.

Thanks for this guidance on what to do with the .bat file results.

Reply | Quote

Instead of comparing the good machine and the bad machine (too many differences IMO), I would first promote the second limited account on the bad machine to be an admin.  This only takes a few clicks.  Login to the admin, and then change the account to admin. Here is full screenshots https://www.howtogeek.com/739981/how-to-change-a-user-account-to-administrator-on-windows-10/

Then, you should have a bad admin account on the bad machine and a good admin account on the bad machine.  Use the batch files to compare those.

Reply | Quote

Energy Saver wrote:

Then, you should have a bad admin account on the bad machine and a good admin account on the bad machine.

Sounds like a good idea, but I’m going to keep going with looking into the 1) current MSA admin account on the ‘bad’ machine, where Search Highliights (SH) is messed up and 2) the ‘good’ machine’s local, admin account where SH is OK. Per your idea, I aleady have on the ‘bad’ machine an MSA admin account with a -SH and an local account with a +SH. If I changed this local account to admin, I would still have to change it (the local) to MSA to end up with only one difference. Then I would have on this ‘bad’ machine two MSA admin accounts. I am pretty sure that the 2nd MSA admin account would be +SH. I say this because the local, standard account I created is +SH. Changing this account (not adding a new one) to admins should still leave it +SH. Changing it to MSA would likely leave it +SH. {Is it possible to change a MSA account from standard to admin?}
Here’s a schematic to illustrate the process. See new changes to 2nd acct on ‘bad’ machine.JPG

Then, I would have to make sure that ALL of Windows and GP settings on the 2nd account on the ‘bad’ machine were identical. Do the GP settings automatically transfer when a new account is added or changed? Do all of the Windows settings automatically transfer, too when a new account is added or changed? (I haven’t looked at them all in new account that I just added — at the time, I was only interested in what happened to SH.)

The MAJOR job in this plan would be that of mirroring the folder structure and folder content in account #1 and account#2, making sure I have all of the same apps in #1 and #2 (including all of those I have brought in), making sure the Desktops are the same, etc, etc, and at the end, when everything is identical (except for the -SH of acct #1 and the +SH in acct #2), then remove #1. Of course, I have to make sure I have enough space when making the two identical. My SSD is now about 50% full.

If there is an easier way to get +SH on the ‘bad’ machine’s acct #1, I would rather do that.

Reply | Quote

Energy Saver wrote:

Then, you should have a bad admin account on the bad machine and a good admin account on the bad machine. Use the batch files to compare those.

OP has confirmed that “this new account on the “bad” machine is working exactly like it should”, thus suggesting profile corruption of the original account…  so one could argue that there’s really little or no point in pursuing comparisons anyway.

I’ll leave it up to OP to decide whether to just elevate the new standard account to the administrators group and call it a day. 🙂

Reply | Quote

Rick Corbett wrote:

I’ll leave it up to OP to decide whether to just elevate the new standard account to the administrators group and call it a day. 🙂

I have outlined in #2536504 the MAJOR job of making acct #2 like #1 on the bad machine, even leaving out the step of changing it from local to MSA, but doing the step of changing it from standard to admin.

So, what about this approach?

Tactic 1:
7+ Taskbar Tweaker predates the SH problem on the ‘bad’ machine.

What if I were to completely uninstall 7+ Taskbar Tweaker on the ‘bad’ machine to see if it gets rid of the -SH problem in ‘bad’ machine, acct 1?.

Tactic 2:
I have an inkling that the ‘DisabledReason: DisabledbyPolicy’ was introduced when SH was rolled out, but not to every machine. SH was introduced in a Preview KB5011543 on May 22, 2022. I did not install this Preview. On April 12, 2022 it started rolling out to non-Insiders with KB5012599. I installed this KB on May 2, 2022 on both machines but there was no SH on either one. I figured that this was the first wave of the rollout and my machines were not yet eligible for SH (and so I am guessing that this KB introduced the ‘DisabledReason’ property, intending to remove it when MS decided that the machines WERE eligible). On May 10, 2022, KB5013942 was introduced with SH in it. I am guessing that this KB removed the ‘DisabledReason’ property. I installed this KB on May 29, 2022 on both the ‘good’ and ‘bad’ machine. SH worked on the ‘good’ machine, but not the ‘bad machine. ‘DisabledReason’ is still on the ‘bad’ machine’s acct 1 [hightlight] and acct 2, but SH works in acct 2, but not acct 1[/highlight]. Really odd.

So, if Tactic 1 does not work but the tweaker is still uninstalled, then what if I re-installed KB5013942 (designed to allow SH and first installed on both machines on May 29, ’22)? Can you re-install an old KB?? .

Tactic 3:
If Tactic 1 does not work (and the tweaker is left uninstalled), and if Tactic 2 doesn’t work, either because it can’t be done or if it can be done, but it doesn’t work, then make ‘bad’ machine, acct 2 exactly like acct 1 (probably doubles the SSD used space) and then remove acct 1. See changing 2nd acct on ‘bad’ machine to admin.JPG.

So, reject Tactic 3 because of the problems in the orange square.

Tactic 4 (in place of Tactic 3): See if, then.JPG.

what is Tactic 4? How can I uncorrupt the profile for ‘bad’ machine, acct 1?

Reply | Quote

WCHS wrote:

I don’t know where to look for the problem.

That’s the purpose of the BAT file I provided and the offer to look at the results for you. You have no experience of the registry; I do.

WCHS wrote:

It seems to be connected to the presence of ‘DisabledReason: DisabledbyPolicy’ on the “bad” machine and its absence on “good” machine, but where in Registry you would find this on the “bad” machine and correct it, I don’t know.

Unfortunately that’s just a guess. However, if it’s correct then the HTML report generated by the last section of the BAT file will not only show you the policy/policies in effect but also whether it/they are ‘machine-wide’ or ‘per user’ (or even both), i.e. you’ll know where to look in the Local Group Policy Editor.

I’ve looked at your tactics and the first thing which strikes me is that they’re not based on any evidence.

For example, Tactic 1 of uninstalling 7+ Tweaker is unlikely to do anything to resolve the issue unless it implements a registry change that effects Search Highlights. Much quicker IMO would be to use the Sysinternals/Technet Autoruns tool and just temporarily disable 7+ Tweaker from autostarting. If it doesn’t autostart then it can’t inject any DLLs into system processes nor read the registry for settings.

In Tactic 2 you wonder whether reinstalling KB5013942 may fix the issue. It might… but you don’t know.

You’ve already discounted Tactic 3.

Tactic 4 asks how to uncorrupt the profile for ‘bad’ machine. Nobody can answer that, not even Microsoft. However, the registry exports and policy report from the BAT file, which you’ve apparently already gathered, *might* provide a clue. Why not post them?

Reply | Quote

My mind has been working on two fronts.

FRONT 1:
I proposed Tactic 1 because you had suggested early on that a third-party app might be interfering. We talked about this in #2535131 and in #2535187.

7+ TaskTweaker was working on both machines, but whereas the ‘good’ machine does not have any SH problems, the ‘bad machine’ does. It goes into effect at start up on both. But, as noted in #2535187, I have prevented it from starting at startup, restarted, and still no SH. Is AutoRuns going to tell me anything more? If so, perhaps, run it before the tweaker is blocked and then run it after it is blocked. Or just forget about Tactic 1 altogether? Or hold off on it until later?

FRONT 2:

Rick Corbett wrote:

However, the registry exports and policy report from the BAT file, which you’ve apparently already gathered, *might* provide a clue. Why not post them?

I have yet to run the .bat file on the ‘good’ machine, but I’ve run it on the ‘bad’ machine. Let me explain a bit. I have a confession to make. I made a mistake when I went to inspect the .bat file. I went to the wrong one (the one inside the zip folder), and the context menu did not have an ‘edit’ choice nor an ‘run as administrator’ choice, but it did have ‘Open’. I thought ‘Open’ meant ‘Open for editing’. So, I clicked on ‘Open’ and it ran (not as administrator and not encountering the UAC), so I got the wrong.REG files. Then, I ran the .bat file again (after having accessed the .BAT file in the extracted folder, where the context-menu DID give me the choice of ‘edit’ and ‘run as administrator’. When I clicked on the latter, I got the right files. So, then, I practiced/became familiar with Notepad++ comparing the files from the wrong run and from the right run.

Now, since I’ve become familiar with Notepad++ and since you’ve answered my questions about what to cull out of the Notepad++ comparisons, I know where to go next.

(How much hair do you have left ? 🙂 🙂 )

Reply | Quote

b wrote:

Is this quest for the holy grail pizza slice really worth all the effort?

IMO that’s *really* condescending. Isn’t that the sole purpose of this forum? For people to ask questions?

b wrote:

Windows 11 has never had any graphics in the taskbar search box (even with search highlights on).

And the relevance to this query in the Windows 10 area of the forum is? Why go off-topic? Isn’t there a forum rule about that? (Yes, it’s no. #1 under General Rules.)

b wrote:

I don’t understand your reluctance to look at the registry in any case.

The OP has made it very clear more than once that, for whatever reason(s), it’s his/her choice to avoid the registry. Why not respect that, rather than query it with your own opinion?

Reply | Quote

Rule of nntp that got beat into my head years ago.  It is not for us to question why the original question-er wants to do something. Remember to answer the question.  You can also then opine and say “Hey you know there is another way….” but always remember to answer the original question.

Susan Bradley Patch Lady

Reply | Quote

Rick Corbett wrote:

The OP has made it very clear more than once that, for whatever reason(s), it’s his/her choice to avoid the registry. Why not respect that, rather than query it with your own opinion?

Like you did?

Rick Corbett wrote:

Overall the registry isn’t something to be feared IMO. At the end of the day it’s just a very simple repository (in, basically, a flat-file format) for storing settings. (As your original query suggests, lots of settings are just binary DWORD toggle values to turn stuff ‘on’ or ‘off’. Quite often it’s that simple.)

IMO the ‘trick’ is to treat the registry with a modicum of respect and back up whatever areas you’re going to work on *before* making any changes, then use the right tools with it… not necessarily the built-in registry editor (RegEdit).

I understand your reticence about dipping your toes in the water (given the almost constant drip feed of ‘here be dragons’ warnings) but, despite the fearmongering, becoming confident (yet prudent) about even rudimentary operations using the registry is, IMO, a necessary evil and very useful skill these days.

I only commented on looking at the registry.

Windows 11 Pro version 22H2 build 22621.1413 + Microsoft 365 + Edge

Reply | Quote

WCHS wrote:

Now, since I’ve become familiar with Notepad++ and since you’ve answered my questions about what to cull out of the Notepad++ comparisons, I know where to go next.

It’s good to hear that I’ve answered your questions about the comparisons…. although step 5 in the BAT file doesn’t really produce a file that lends itself to being compared easily.

 

Reply | Quote

Rick Corbett wrote:

although step 5 in the BAT file doesn’t really produce a file that lends itself to being compared easily.

But, I see that. However, each provides important information about any user- or machine-wide policy settings in use, from which non-Notepad++ comparisons can be made, right?

Reply | Quote

WCHS wrote:

Thanks for the latest info … I’ll get started. Everything is very clear (I think).
Ready for the ride!

I’m not sure what further help I can provide. Perhaps just follow the steps I’ve provided?

Reply | Quote

Rick Corbett wrote:

Perhaps just follow the steps I’ve provided?

Yes, for sure. I’ll stay away from this thread in the meantime.

Reply | Quote

WCHS wrote:

However, each provides important information about any user- or machine-wide policy settings in use, from which non-Notepad++ comparisons can be made, right?

Correct. Each of the first 4 steps exports a registry ‘branch’ which contains keys and their sub-keys which may be of relevance. (The fifth step presents a multitude of special ‘policy’ branches in an ‘easy-to-read’ web format.)

Unfortunately, pruning registry ‘branches’ quickly to leave only relevant keys/sub-keys  for text comparison tools like Notepad++’s Compare and ComparePlus to be able to parse accurately is where the learning curve comes in. I don’t know of a way to circumvent that… although tools like Nirsoft’s small, free, portable RegScanner help to make looking for needles in a haystack easier. (For example, I used RegScanner to search for key/value/data instances of the phrase Search Highlights… only to find no results.)

Overall the registry isn’t something to be feared IMO. At the end of the day it’s just a very simple repository (in, basically, a flat-file format) for storing settings. (As your original query suggests, lots of settings are just binary DWORD toggle values to turn stuff ‘on’ or ‘off’. Quite often it’s that simple.)

IMO the ‘trick’ is to treat the registry with a modicum of respect and back up whatever areas you’re going to work on *before* making any changes, then use the right tools with it… not necessarily the built-in registry editor (RegEdit).

I understand your reticence about dipping your toes in the water (given the almost constant drip feed of ‘here be dragons’ warnings) but, despite the fearmongering, becoming confident (yet prudent) about even rudimentary operations using the registry is, IMO, a necessary evil and very useful skill these days. 🙂

Hope this helps…

Reply | Quote

I’ve been learning A LOT in this project thanks to your guidance. Maybe, I’ll dig into the Registry after I learn a lot more about it. I tend to survey the landscape and learn about what I see without actually traversing it. In a way, I feel like I’m doing surgery without the required medical background for it, and if I were to open up the patient, it would likely to kill it. And I need for this patient to stay alive. But, maybe it will turn out to be more like taking a sliver out of your finger!!

In addition, heretofore, I haven’t actually NEEDED to look at the Registry, so it’s been a bit abstract.
———————–
I’ve got two big things on the front burner tomorrow, so I’ll get back to you on Friday or Saturday with a zip file.

Reply | Quote

WCHS wrote:

I’ve been learning A LOT in this project thanks to your guidance. Maybe, I’ll dig into the Registry after I learn a lot more about it. I tend to survey the landscape and learn about what I see without actually traversing it. In a way, I feel like I’m doing surgery without the required medical background for it, and if I were to open up the patient, it would likely to kill it. And I need for this patient to stay alive. But, maybe it will turn out to be more like taking a sliver out of your finger!!

In addition, heretofore, I haven’t actually NEEDED to look at the Registry, so it’s been a bit abstract.
———————–
I’ve got two big things on the front burner tomorrow, so I’ll get back to you on Friday or Saturday with a zip file.

At the end of the day, this is *your* topic and, IMO, thus driven at your own pace.

Do whatever feels OK and comfortable to you; don’t do anything that you’re not comfortable with.

Reply | Quote

WCHS wrote:

I’ve got two big things on the front burner tomorrow, so I’ll get back to you on Friday or Saturday with a zip file.

Whatever/Whenever… it’s *your* topic. Reply or… don’t. 🙂

Reply | Quote

OK, here is a table of results after running the .bat file on the ‘bad’ machine and the ‘good’ machine. I have used the ComparePlus plugin in Notepad++ to make the comparisons summarized here. You can see where the results are the same between the 2 machines and where the results are different. Comparing the files themselves (which are in the attached zip folder) will allow the results to be viewed in a more complete fashion. There are 12 files in the zip folder, 6 when the .bat file ran on the ‘bad’ machine and 6 when it ran on the ‘good’ machine. I’ve also included a .jpg file of the table.

I am wondering if there are any critical differences in the output files themselves that tells you something??

As summarized in the table, some of the differences seem, to me, to be inconsequential. For example the ‘good’ machine has a fingerprint mechanism, and the ‘bad’ one does not; the ‘bad’ machine is older and was once configured for HomeUsers; the ‘bad’ machine is tied to a MS account and therefore my email address (redacted) shows up in the User Details of the gpo report.

I don’t know why there is nothing in the gpo report’s Computer Details section for the ‘good’ machine. GP-settings at “Local Computer Policy > Computer Configuration > Administratrative Templates > System/FileSystem“ and at “>Windows Components” are the same on both machines (..e., those ‘Enableds’) are REALLY there on the ‘good’ machine and they are working. The “User Details > General > Security Group Membership” listing is in a different order, but does this make a material difference??

Comparing bad and good.jpg

FYI, for 2hkcu_feeds.reg,
the two exclusive lines on the ‘bad’ machine (‘bad’ has it but ‘good’ does not) are:
2hkcu_feeds-bad – 2 exclusive.JPG

The one exclusive line on the ‘good’ machine (‘good’ has it, but ‘bad’ does not) is:
hkcu_feeds-good-1 exclusive.JPG

Does this difference provide a clue as to why the SH problem exists?

2023-_GATHER_INFO_RESULTS

Reply | Quote

WCHS wrote:

I am wondering if there are any critical differences in the output files themselves that tells you something??

A good question, not helped by lack of documentation.

Some results can be ignored. For example, section 1 was just a check that Windows on both devices was the same edition, version and build – they are. The exports of 2hkcu_searchsettings and 4hklm_feeds from each device are identical so can be discounted.

The exports of 3hkcu_search differ from each other but refer to Cortana… so can also be discounted IMO.

The results of 5gpo_report are interesting. You say that they *should* show as identical but they’re very different. The only relevant setting though is that ‘bad machine’ shows Enable news and interests on the taskbar as Enabled. Previously you mentioned setting Allow search highlights to Enabled and I suggested setting it back to Not configured.

According to the description in the Local Group Policy Editor there should be no difference between Enabled and Not configured. However, as I proved back in post #2534432 and you subsequently confirmed, there *is* a subtle difference between the 2 states. I suspect it’s that difference which is reponsible for the DisabledByPolicy value that appears in both good and bad machines.

That leaves the export of 2hkcu_feeds and, in particular, the differences between the 2. The value for DeviceTier is different but I believe that’s irrelevant.

I’ve searched high and low yet cannot find a description of what Gleam is, let alone UseDefaultGleam. I could be wrong but the binary value of 0 (zero, i.e. ‘off’) on the good machine suggests that it too is irrelevant.

That leaves 2 entries on the ‘bad’ machine which don’t appear on the ‘good’ machine. It also doesn’t explain the DisableReason entries on both machines, with one machine working as expected and the other not. This more or less bears out what the new account you created confirmed… there’s an element of profile corruption. However, it might be fixable.

Here’s what I suggest. You use LGPE to change News and interests > Enable news and interests on the taskbar back from Enabled to Not configured.

I’ll write up some step-by-step instructions and provide 2 .REG files in a Zip attachment for the bad machine. The first .REG file will be based on the 2hkcu_feeds export and will make a couple of changes to OpenOnHover settings. You’ll see when you open the .REG file in Notepad exactly what it does, ‘cos I’ll document the changes.

The second .REG file will be an undo file and will revert the changes made by the first .REG file if it doesn’t work.

Let me know if you’re happy to do this and I’ll start creating the .REG files and testing them.

Hope this helps…

Reply | Quote

To @Rick-Corbett
This post is a reply to #2537252. I’m couple of steps behind your latest post with the new ‘maybe-fix-it’.REG file and its companion ‘undo the-might-fix-it’.REG file (in the ‘2023_search_highlights’ zip folder). You can reply as you see appropriate. This post has a number of sections, all in response to post #2537252.

ABOUT THE RESULTS OF 5GPO_REPORT

Rick Corbett wrote:

The results of 5gpo_report are interesting. You say that they *should* show as identical but they’re very different.

Let’s say that I expected them to show as identical, i.e., I expected for there to be a Computer Details section in the gpo report on the ‘good’ machine, because both machines have the same LGPE ‘Enabled’ or ‘Disabled’ settings. See the attached LGPE settings on both machines.JPG.

But, no Computer Details section is in the ‘good’ report. Whether it ‘should’ be there or not, I don’t know. Maybe, it’s not there because there’s only 1 acct (local, admin) on the good machine?

The point I had wanted to make in my study of both gpo reports is that whether it’s in the gpo report or not, everything that is ‘Enabled’ on the ‘bad’ machine is ‘Enabled’ on the ‘good’ machine (and vice versa).

ABOUT SEARCH HIGHLIGHTS

Rick Corbett wrote:

Previously you mentioned setting Allow search highlights to Enabled and I suggested setting it back to Not configured.

If a setting is ‘Not configured’, it doesn’t look like the gpo report will say anything about it. But, to make it clear, I DID set ‘Allow search highlights back to ‘Not configured,’ as you have suggested. It is that way on both machines. As a matter of fact, everything at Search in the LGPE is ‘Not configured’. See the attached LGPE settings for Search.JPG

ABOUT DEVICE TIER

Rick Corbett wrote:

The value for DeviceTier is different but I believe that’s irrelevant.

What is “Device Tier”? On the ‘bad’ machine, the dword is ‘2’ and on the ‘good’ machine, the dword is ‘1’. Does it have anything to do with the number of accounts on the machine (the ‘bad’ machine has 2 accounts and the ‘good’ machine has 1 account’). {Just trying to learn more about what the Registry says}

ABOUT YOUR TEST MACHINE

Rick Corbett wrote:

That leaves 2 entries on the ‘bad’ machine which don’t appear on the ‘good’ machine.

What does a run of your .bat file on your test machine produce? Is there any resemblance between what you get on your test machine and a) what I get on the ‘bad’ machine and/or b) what I get on the ‘good’ machine, for example, does your test machine have these pink and/or green lines in 2hkcu_feeds.reg ? See the attached ‘bad’ and ‘good’ 2hkcu_feeds.JPG.

ABOUT ‘NEWS AND INTERESTS’

Rick Corbett wrote:

Here’s what I suggest. You use LGPE to change News and interests > Enable news and interests on the taskbar back from Enabled to Not configured.

The current LGPE setting for ‘News and interests’ is in the attached LGPE settings for N and I and Taskbar Settings.JPG
I think ‘Enabled’ means that “News and interests” is configured to be an entry on the Taskbar Context Menu, and this then allows the user to turn it ‘on’ or ‘off’. Because I have it ‘Enabled’ in the LGPE, it is showing up on the context menu, but I have the “Turn off” setting checked.

I have noted your request that if I run your new .REG files I should first use LGPE to change News and interests > Enable news and interests on the taskbar back from Enabled to Not configured. Can you tell me the reason for that? The Taskbar settings for both Search and for News and interests have an ‘Open on hover’ setting. I am guessing that the Registry has two OpenOnHover settings/keys/ (or whatever you call them) somewhere, one that pertains to Search and the other that pertains to News and interests. What does changing the LGPE setting for News and interests to ‘Not configured’ do for the task at hand, i.e., finding out if change(s) in the Registry will fix the SH problem?

ABOUT THE NEW REG FILES

Rick Corbett wrote:

I’ll write up some step-by-step instructions and provide 2 .REG files in a Zip attachment for the bad machine. The first .REG file will be based on the 2hkcu_feeds export and will make a couple of changes to OpenOnHover settings. You’ll see when you open the .REG file in Notepad exactly what it does, ‘cos I’ll document the changes.

The second .REG file will be an undo file and will revert the changes made by the first .REG file if it doesn’t work.

A. ABOUT THE ‘MIGHT-FIX-IT’.REG FILE
1. I understand that the ‘might-fix-it’.REG file will make some changes to the Registry that might fix the problem. The fix, if it works, would have this effect, right?
a) a checkmark on the Taskbar Search setting for ‘Show search highlights’ will actually work, i.e., there will be a graphic/gleam at the right end of the Taskbar Searchbox.
b) the Taskbar Search setting for ‘Open on hover’ will be bright, instead of greyed out (as it is now).
c) a checkmark on the Taskbar Search setting for ‘Open on hover’ will actually make the ‘hover’ work when hovering on the graphic/glean.

2. Will this ‘might-fix-it’.REG file have any effect elsewhere? I know that you have addressed this question now in #2537544, but I want to ask this: Is there a chance that the Registry will be discombobulated because the change(s) made do/does not jibe with some expected setting elsewhere in the Registry and so things are thrown out of whack?

3. If it works, can I change LGPE ‘News and interests’ back to ‘Enabled’?

B. ABOUT THE ‘UNDO THE-MIGHT-FIX-IT’. REG FILE
1. Do I understand that the undo.REG file will put things back to where they were before running the ‘might-fix-it’ .REG file? Is running this undo.reg files the recommended course of action, if the ‘might-fix-it’.REG file didn’t fix the SH problem? Note: I have noticed, too, in #2537547 (see below) that you have added an additional important step: run 2hkcu_feeds-bad.reg afterwards.

ABOUT POST #2537544 and #2537547
I have some questions about #2537547, but I’ll post those later.

Thanks!!

Reply | Quote

I found out what a ‘gleam’ is. It’s just Microsoft subverting common English terms for its own amusement. It really just means ‘graphic’ or ‘image’ (in SVG format) that appears in the taskbar Search Bar:

The two default ‘gleams’ I looked at – one for light themes and one for dark themes – are 76KB and stored in:

%localAppData%\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\LocalState\ShellFeeds\

There’s also an IDX_CONTENT_TASKBARHEADLINES.json file containing all the links to what appears to be the headline feeds of the news tiles which appear when you hover over the ‘gleam’. I counted 173 URLs in the file I looked at. (I wonder how much personal bandwidth all those feeds would consume if I actually had Search Highlights turned on normally instead of just for testing for this topic?)

Reply | Quote

The ‘bad’ and ‘good’ machines have C:\Users\personalname\AppData\Local\Packages\Microsoft.Windows.Search_cw5n1h2txyewy, too. The folder is stamped with the date on which 20H2 was installed. {I went from 1909 to 20H2 by setting TRV to 20H2, i.e., I skipped over 2004 aka 20H1–the first in the 2xHx series.}

Here are the contents of …\ShellFeeds for both of the machines. The folder contents are not the same for the two. See ‘bad’ machine gleam folder.JPG and ‘good’ machine gleam folder.JPG

Look for more tomorrow, in reply to 2537252. In the meantime, perhaps your ‘maybe-fix-it.REG’ file and its companion ‘undo-maybe-fix-it.REG’ file will need to take these folder-content differences into account??

Reply | Quote

Have you given consideration that perhaps our computer overlords haven’t turned on search highlights on that machine?  Are we certain that it’s been rolled out for all for sure?

Susan Bradley Patch Lady

Reply | Quote

Susan Bradley wrote:

Are we certain that it’s been rolled out for all for sure?

It’s been 9 months since Search Highlights (SH) started to roll out in 21H2 (April 12, 2022 Patch Tuesday KB5012599). Neither machine got it then. The ‘good’ machine got it the following month in the May 10 21H2 KB5012599 release, installed May 29, 2022. SH worked. The ‘bad’ machine installed this same KB on the same date, but SH did not work.

3 weeks ago, I installed 22H2 via TRV=22H2 on both machines. SH is still working on the 22H2 ‘good’ machine and still not working on the 22H2 ‘bad’ machine.

It’s difficult to believe that the rollout is not complete – it’s been 9 months worth of monthly CUs. When I will install the Feb CU KB5022834, it will be 10 months. Can the SH rollout be taking THIS long???

Besides that, last week I observed on the ‘bad’ machine that SH worked right away when a new account was added. So, that account (local, standard) is functioning under the aegis of the rollout. And if the added account is under the aegis of the rollout, the OOBE account (MSA, admin) is too, right? Because CUs are installed on the machine as a whole (and not just some accounts), right? From this, it has to be that something is not letting the rolled-out SH work right on the OOBE (MSA, admin) account, whereas there is not anything that is interfering with SH working right on the added (local, standard) account.

Reply | Quote

Susan Bradley wrote:

Are we certain that it’s been rolled out for all for sure?

The first screenshot in the OP shows Search Highlights checked but Open on hover grayed out, i.e. it’s rolled out, but full functionality is only partially available.

The ‘create new account’ test already carried out shows that Search Highlights works as fully expected on OP’s ‘bad machine’, just not with the usual account. This suggests profile corruption of the original (OOBE) account used for day-to-day use. The grayed out Open on hover option suggests a policy restriction IMO… and there are indeed anomalies between the ‘bad’ and ‘good’ machines when HTML reports of ‘Group Policy results’ are examined.

IMO the easiest solution would be to elevate the newly-created standard account to the Administrators group then migrate data from the ‘old’ (OOBE) account to the new account. If wanted, this new account could then also be switched from a local account to MSA to duplicate functionality of the original OOBE account that shows corruption.

However, that’s a little bit more work than just applying a very simple .REG file that may have the desired result of switching on Open on hover in the presumed corrupt account on the ‘bad’ machine.

Hope this helps…

Reply | Quote

WCHS wrote:

In the meantime, perhaps your ‘maybe-fix-it.REG’ file and its companion ‘undo-maybe-fix-it.REG’ file will need to take these folder-content differences into account??

The dynamic contents of those folders should catch up if the Feeds are fixed, provided there are no ‘machine-wide’ policy restrictions in place for either Search Highlights or News and interests (see post #2534432), as these will override any corresponding ‘per user’ settings in the registry. Unfortunately you don’t know if the existing ‘gleams’ (images) are dynamic (0) or static (1), so I wouldn’t copy them over.

I’ve supplied the fix and undo .REG files in an attached ZIP file (see the link near the end of this post) but I’ve posted the contents of the ‘fix’ .REG file below, with comments to explain:

Windows Registry Editor Version 5.00

; Next section is for 'News and interests' on the taskbar
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds]
; Next setting deletes the 'DisabledReason' entry, if still there
"DisabledReason"=-
; Next setting determines the 'OpenOnHover' state (0=Off/1=On)
"ShellFeedsTaskbarOpenOnHover"=dword:00000001
; Next setting determines the 'News and interests' state
; (0=Show icon and text/1=Show icon only/2=Turn off)
"ShellFeedsTaskbarViewMode"=dword:00000000

; Next section is for 'DSB' ('Desktop Search Box'?) on the taskbar
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\DSB]
; Next setting deletes the 'DisabledReason' entry, if still there
"DisabledReason"=-
; Next setting determines the 'OpenOnHover' state (0=Off/1=On)
"OpenOnHover"=dword:00000001
; Next setting determines whether dynamic content is shown (0=Off/1=On)
"ShowDynamicContent"=dword:00000001
; Next setting determines the display state of the 'gleam' image(s)
;  (0=Dynamic/1=Static default)
"UseDefaultGleam"=dword:00000000

Note that the two .REG files in the ZIP file don’t do anything that can’t be undone. They only make minor changes to a Feeds branch in the registry for the current logged on user, nowhere else. There is *no* risk of them affecting anywhere else in the registry other than Search Highlights and News and interests for the current logged on user.

The effect of the changes should be dynamic, although you may need to wait for a few seconds for the data Feeds to update.

The files are:

1. 2023_search_highlights_fix.reg – Merge this to enable the changes I suggest.
2. 2023_search_highlights_undo.reg – Merge this to remove the entries changed by 2023_search_highlights_fix.reg.

Important: If you end up merging 2023_search_highlights_undo.reg then you need to finish off the ‘undo’ operation by subsequently merging the 2hkcu_feeds-bad.reg file you supplied previously. This will get your machine back to the exact same state before 2023_fix.reg was merged.

2023_search_highlights

My next post will contain step-by-step instructions about merging .REG files.

Let me know if you have any questions

Hope this helps…

Reply | Quote

1. Download, unblock then unzip the 2023_search_highlights zip file (see the attachment link near the bottom of the previous post) using the account you want to fix. (The .REG files work on just the ‘current user’ profile.)

2. Double-click on the 2023_search_highlights_fix.reg file.

3. A User Account Control dialog will appear:

Click on the Yes button to accept and dismiss it.

4. Another dialog will appear:

Click on the Yes button to accept and dismiss it.

5. You should now see a final dialog showing the contents of the .REG file have been successfully merged into the registry:

That’s it.

In theory any changes should take place dynamically. However, the Feeds show timer entries in the registry so you may need to wait for the next update interval (or just restart the machine).

Hope this helps…

Reply | Quote

Ok, I’ve avoided contributing to this thread because Windows Search on my PC’s is completely disabled (I use 3rd party S/W for searches) but felt I should point this out.

• Search Highlights using the new “local account” on the effected PC works as expected.
• Search Highlights using the old “MS account” on the effected PC doesn’t work.

That tells us whatever is causing the problem is either some setting located somewhere in the HKEY_CURRENT_USER registry tree (settings in the HKEY_LOCAL_MACHINE registry tree would effect all users) or it’s a program that’s only installed/running for the “bad” account (like 7+ Taskbar Tweaker which you inidcated is not running for the new “good” local account.)

First, lets deal with 7+ Taskbar Tweaker which @WCHS has indicated is not running for the new “good” local account but is for the old “bad” MS account.

I also use 7+ Taskbar Tweaker and all it’s settings are located in the registry at the following location:

HKEY_CURRENT_USER\SOFTWARE\7 Taskbar Tweaker

And while there’s no option to “save” it’s current settings, it can be done by saving that registry key and then it can be deleted to “remove” all the changes 7+ Taskbar Tweaker made (note: you’d need to “uncheck” the 7+ Taskbar Tweaker setting Run at startup before doing this or it’ll still auto-run when that user logs in.)

So you could login using the old “bad” MS account, save the settings, then delete them, and see if that lets Search Highlights work as expected.

@WCHS, I’ve got 2 batch files that do this if you’re interested in trying it.

Second, I checked and there are some “user policy” settings under…

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Explorer

… that “might” be at fault for only the old “bad” MS account if they’ve been set; especially one called DisableSearchBoxSuggestions.

While logged in with the old “bad” MS account, use this Powershell command to see these settings and determine their status:

Get-ChildItem -Path HKCU:\SOFTWARE\Policies\Microsoft\Windows\

If any exist and is set to 1, then deleting them and/or setting them to 0 “might” restore Search Highlights for that account.

Reply | Quote

alejr wrote:

While logged in with the old “bad” MS account, use this Powershell command to see these settings and determine their status:

Get-ChildItem -Path HKCU:\SOFTWARE\Policies\Microsoft\Windows\

If any exist and is set to 1, then deleting them and/or setting them to 0 “might” restore Search Highlights for that account.

To @Alejr:
This is the result of running that PS command on the ‘bad’ macine. Same results on the ‘good’ machine, too. Looks like there’s nothing to see.

Reply | Quote

WCHS wrote:

The point I had wanted to make in my study of both gpo reports is that whether it’s in the gpo report or not, everything that is ‘Enabled’ on the ‘bad’ machine is ‘Enabled’ on the ‘good’ machine (and vice versa).

There are obvious discrepancies between what you see in the LGPE (which is just a front-end to Policy branches in the registry) and the Group Policy Results report (which is supposed to amalgamate queries of the registry and present the results in an easy-to-view format.

Ultimately the purpose of 5gpo_report was to show whether any policy affecting Search and/or Feeds was in place. In that respect the report did its job.

WCHS wrote:

What is “Device Tier”?

Basically, it’s a ranking. In cell/mobile phone parlance, a ‘Tier 1’ device is a flagship model. It may not be the most popular (like ‘Tier 2’) but purchasers have paid a premium for it so the devices receive updates before ‘Tier 2’ devices do. ‘Tier 3’ devices are beginning to age and receive updates after ‘Tier 2’ devices. ‘Tier 4’ devices are legacy/niche models. Whether a ‘Tier 4’ receives any updates at all is debatable.

Unfortunately I’ve been unable to find any documentation about what ‘DeviceTier’ means in terms of dynamic data feeds to Windows devices… but it’s still no doubt going to be an arbitrary ranking on Microsoft’s part about in which order devices get dynamic feeds first. I’m going to guess that Microsoft Surface devices are in ‘Tier 1’. 🙂

WCHS wrote:

What does a run of your .bat file on your test machine produce? Is there any resemblance between what you get on your test machine and a) what I get on the ‘bad’ machine and/or b) what I get on the ‘good’ machine, for example, does your test machine have these pink and/or green lines in 2hkcu_feeds.reg ?

My test machine is a clean install of Windows 10 Pro 22H2, build 19045.2604, with no ‘tweaks’ done to it at all. (It takes just 3 minutes to re-image it with a clean install.) I used it to test development of the .BAT file and compare results to the .REG exports you provided.

In the absence of any relevant Microsoft documentation that I could find, I used it – together with Process Monitor – to test and monitor changes to Search, Search Highlights and News and interests so I could better understand the links between them.

To answer your question, yes, my test machine showed the same values for ShellFeedsTaskbarContentUpdateMode, ShellFeedsTaskbarOpenOnHover and  UseDefaultGleam. I subsequently changed the values manually in the registry so I could understand the effects of toggling the state of each entry. For example, it’s how I created the screenshot of the differences between UseDefaultGleam states.

I also used it to test operation of the fix/undo .REG files so I knew that adding comments (which is not usual in a .REG file) wouldn’t cause any problems.

WCHS wrote:

I have noted your request that if I run your new .REG files I should first use LGPE to change News and interests > Enable news and interests on the taskbar back from Enabled to Not configured. Can you tell me the reason for that?

Quite simply because it has a similar effect to how LGPE handles Search Highlights… it creates a ‘machine-wide’ key/value policy entry in the registry that takes precedence over standard ‘per user’ settings, provided they are related.

In post #2534145 I wrote:

A machine-wide policy setting will override a current user setting every time, irrespective of the user group that the signed-on user is in. That’s its whole purpose.

In post #2534432 I wrote:

I forgot to mention… a screenshot shows a machine-wide setting has been enabled in the Local Group Policy Editor (LGPE).

This changed setting has had the effect in the registry of creating a new Windows Search key under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows and added an EnableDynamicContentInWSB DWORD entry

In post #2537544 I wrote:

The dynamic contents of those folders should catch up if the Feeds are fixed, provided there are no ‘machine-wide’ policy restrictions in place for either Search Highlights or News and interests (see post #2534432), as these will override any corresponding ‘per user’ settings in the registry.

Some info:

• The ‘registry’ is a catch-all term for the amalgamation of several different databases in which ‘settings’ are stored. (RegEdit – or Registry Editor, as it’s more correctly called – presents a front-end to the amalgamation of all those databases, viewed together in one window.)
• Search Highlights and News and interests are very closely linked, relying on a shared stream of dynamic data.
• The registry stores the settings for these dynamic data feeds, including their display, in a ‘per user’ area of the registry called the HKEY_CURRENT_USER hive.
• LGPE is a front-end to Policy branches, i.e. collections of specific settings split between ‘machine-wide’ and ‘per user’ areas.
• There’s a heirarchy within settings in the registry. A ‘policy’ setting takes precedence over a ‘standard’ setting (providing it’s related) and a ‘machine-wide’ policy takes precedence over a ‘per user’ policy (again, provided it’s related).

So, to put it all together, Search Highlights and News and interests share the same dynamic data feeds and similar settings to display them, controlled by registry key/value entries that can be toggled for both ‘display’ and ‘hover’, all stored as ‘standard’ settings in the ‘per user’ registry hive.

Here they both are, shown visually:

Search Highlights

News and interests

As you can see, the LGPE creates policies that, depending on the toggle values, can keep both Search Highlights and News and interests from displaying.

This is the reason why I suggested keeping News and interests > Enable news and interests in the Not configured state in the LGPE… to remove this ‘machine-wide’ policy setting so there is no possible chance of corruption to the key/value pair it creates in the registry if Enabled.

(Before you ask… no, I cannot explain why this policy doesn’t show in the 5gpo-report-good-R.html report if both machines have the exact same changes made in LGPE.)

WCHS wrote:

I am guessing that the Registry has two OpenOnHover settings/keys/ (or whatever you call them) somewhere, one that pertains to Search and the other that pertains to News and interests.

Yes – Both settings are shown in the 2hkcu_feeds-bad.reg and 2hkcu_feeds-good.reg exports.

WCHS wrote:

What does changing the LGPE setting for News and interests to ‘Not configured’ do for the task at hand, i.e., finding out if change(s) in the Registry will fix the SH problem?

Because Microsoft has linked them both to a single ‘per user’ Feeds branch in the registry that controls source, update interval, view mode, *display*, etc. (and hover) of dynamic data, but which can be overridden by a related but conflicting ‘machine-wide’ policy.

WCHS wrote:

A. ABOUT THE ‘MIGHT-FIX-IT’.REG FILE
1. I understand that the ‘might-fix-it’.REG file will make some changes to the Registry that might fix the problem. The fix, if it works, would have this effect, right?
a) a checkmark on the Taskbar Search setting for ‘Show search highlights’ will actually work, i.e., there will be a graphic/gleam at the right end of the Taskbar Searchbox.
b) the Taskbar Search setting for ‘Open on hover’ will be bright, instead of greyed out (as it is now).
c) a checkmark on the Taskbar Search setting for ‘Open on hover’ will actually make the ‘hover’ work when hovering on the graphic/glean.

The 2023_search_highlights_fix.reg file does exactly what its content and comments show if you read it in Notepad or equivalent. It makes 5 changes, reverting settings back to the default values that exist in a machine with working Search Highlights. It also removes 2 DisabledReason entries, should they still exist after using LGPE as I suggested.

I have found no documentation or settings that control the visibility of the currently grayed-out ‘hover’ option nor can I duplicate this condition on my test machine, even using LGPE (which, I suspect, may be the cause), so… no, the .REG file doesn’t address this unfortunately. I am however still looking for the setting that controls the graying-out of this option.

WCHS wrote:

Is there a chance that the Registry will be discombobulated because the change(s) made do/does not jibe with some expected setting elsewhere in the Registry and so things are thrown out of whack?

No, there is no chance. The 2023_search_highlights_fix.reg file makes changes to the Feeds key and Feeds/DSB sub-key as they relate to the display of dynamic content and ‘gleams’ on the taskbar, nothing else.

WCHS wrote:

3. If it works, can I change LGPE ‘News and interests’ back to ‘Enabled’?

Yes. Perhaps remember that the description in the LGPE describes Enabled as the functional equivalent of Not configured.

WCHS wrote:

1. Do I understand that the undo.REG file will put things back to where they were before running the ‘might-fix-it’ .REG file? Is running this undo.reg files the recommended course of action, if the ‘might-fix-it’.REG file didn’t fix the SH problem? Note: I have noticed, too, in #2537547 (see below) that you have added an additional important step: run 2hkcu_feeds-bad.reg afterwards.

Think of the *current* state of the Feeds key in your registry as ‘A’. If you merge the 2023_search_highlights_fix.reg file then the state becomes ‘A+’. If you then merge the 2023_search_highlights_undo.reg file then the state becomes ‘A-‘… but that’s still different to the original state of ‘A’. So, you then merge 2hkcu_feeds-bad.reg to bring it back to its original state of ‘A’. That’s why I made it a 2-step undo… to ensure you had a way of getting back to your original starting point.

Hope this helps…

Reply | Quote

I’ve continued testing, trying to find the setting that grays-out the Open on hover option in the context menus for Search Highlights and News and interests. I’ve been unsuccessful so far.

However, I *have* experienced an issue with the Local Group Policy Editor and its interaction with News and interests.

I have no idea how I did it… but – irrespective of whether Enable news and interests on the taskbar is set to Enabled or back to Not configured state – I lost both the News and interests ‘gleam’ on the taskbar *and* the News and interests context menu option that *should* be between Search and Show Cortana button.

As the description in the LGPE for News and interests clearly shows, the ‘gleam’ (and context menu option, and sub-options) *should* be there with either toggle state… but isn’t.

I tried everything I could think of within LGPE to make them appear then tried merging .REG files I had exported… but I couldn’t get News and interests to reappear back on the taskbar or context menu… until I decided to restart Explorer.exe from Task Manager. Success!

So… my experience has shown me that the relatively new ‘Feed’ controls – Search Highlights and News and interests – are not exactly resilient to fiddling.

1 user thanked author for this post.

WCHS

Reply | Quote

Rick Corbett wrote:

I tried everything I could think of within LGPE to make them appear then tried merging .REG files I had exported… but I couldn’t get News and interests to reappear back on the taskbar or context menu… until I decided to restart Explorer.exe from Task Manager. Success!

Did ‘everything I could think of’ include RESTARTING? Or maybe you didn’t want to lose everything with that move?

hmmm… I’ll keep that in mind. I assume that you clicked on the Task Manager > Processes tab, then right-clicked on Windows Explorer, and clicked ‘Restart’ from the context-menu?

Reply | Quote

Still searching for a setting that’s responsible for graying-out the Open on hover option of either Search Highlights or News and interests… unsuccessfully.

However, I’ve come across another anomaly with the Local Group Policy Editor. I Disabled the entry for Enable news and interests on the taskbar to see the effect and applied the change.

Clicking on Apply should have forced LGPE to run gpupdate.exe in the background to actually implement the change. I was expecting the ‘gleam’ to disappear from the taskbar… but nothing happened. I clicked on OK, closed LGPE and re-opened it, then took take this screenshot of the Disabled entry… with News and interests running (and updating) quite happily in the taskbar:

Just for interest I then Disabled the entry for Allow search highlights and applied the change. Again, I was expecting the ‘gleam’ to disappear from the taskbar Search Box. Again, nothing happened… the ‘gleam’ remained:

… and I could hover the mouse pointer over it for the Search Highlights feed to appear:

This is really bizarre.

1 user thanked author for this post.

WCHS

Reply | Quote

Rick Corbett wrote:

with News and interests running (and updating) quite happily in the taskbar

You say “running (and updating).” I wonder about the “(and updating)”. It looks to me that New and interests is still running as ‘Enabled’ because you see it in the Taskbar Context-menu and you see the “gleam”, so it didn’t update, as you thought it would.

On my ‘good’ machine I’ve gone through the same steps you have. The same thing happens with regard to editing the policy setting in the LGPE for ‘News and interests’ and for ‘Search>Allow search highlights’ (i.e., changing the setting from Enabled to Disabled and then clicking ‘Apply’ or clicking ‘Apply’ & OK and then closing the LGPE.) The change doesn’t happen for me either.

Rick Corbett wrote:

This is really bizarre.

Is it bizarre?? I have always thought that you have to RESTART in order for the changes like this to take effect. Simply clicking a) ‘Apply’ or b) ‘Apply’ & ‘OK’ or c) ‘Apply’, ‘OK’, and closing the LGPE will not do it.

After I restart, then I see the effect of the new policy setting, both in the Taskbar Context-Menu and the “gleaming” (and hovering, if checked).

Speaking of anomalies, the LGPE says that for ‘Search>Allow search highlights’, setting the group policy to ‘Not configured’ or ‘Enabled’ makes no difference in what you see regarding either the “gleam” or “hovering over the “gleam”. The behavior is the same, i.e. “gleam” behaves the same way with either group policy setting and “hovering over gleam” behaves the same way with either setting, too.

I’ve tested out ‘News and interests’ on the ‘good’ machine … one time as ‘Enabled’ and another time as ‘Not configured (making sure to RESTART). The behavior here is the same as it is with Search>Allow search highlights … ‘Not configured’ is tantamount to ‘Enabled’, as far as what one sees for the Taskbar ‘gleaming’ and in the Taskbar Context-Menu (if ‘turned off’, ‘Open on hover’ is greyed out; if either of the two ‘Show ..’ is checked, then ‘Open on hover’ is bright, and you can check ‘Open on hover’ or not.) As far as ‘News and interests’ goes, it works this way on the ‘bad’ machine, too. (Ignore thinking about ‘Search Highlights’ on the ‘bad’ machine in this discussion; as we know, it’s screwed up).

So, my observation here is that for ‘News and interests’ there is no on-the-surface-difference between a group policy setting of ‘Enabled’ and ‘Not configured’. I say ‘no on-the-surface-difference‘ here, because as I discovered and posted at 2534520, there is an “under the hood” difference between the two, at least for Search>Allow search highlight ‘Not configured’ vs ‘Enabled’. Those screenshots at #2534520 were from the ‘bad’ machine, but the ‘good’ machine shows the same results. I am assuming that the same “under the hood” differences between ‘Not configured’ and ‘Enabled’ that I found for ‘Search>Allow search highlight’ obtain for ‘News and interests’ as well, even when Search Highlights is not working right on the ‘bad’ machine.

I understand now your reasoning, though, for setting ‘News and interests’ to ‘Not configured’ before running search_highlights_fix.reg — i.e, to keep it from being a‘machine-wide’ policy setting, if it were ‘Enabled’.

Reply | Quote

I installed 7x Taskbar Tweaker and didn’t find any settings that would affect just the taskbar. (There’s two settings that affect the ‘tray’ – a.k.a. ‘Notification Area’ – where the clock resides, but not the taskbar nor Search Box themselves.) I’m confident 7x Taskbar Tweaker has nothing to do with the ‘missing gleams’ and grayed-out ‘Open on hover’ taskbar options that the OP is experiencing.

(Thinking about the last tests where I *disabled* entries in the LGPE to see what the effects were… the results were suspiciously like gpupdate.exe didn’t fire when I clicked on Apply. I’ll have to bear this in mind  – and perhaps run gpupdate.exe manually – if I do any more tests. For the moment though I need my test laptop for something else so have clean installed.)

1 user thanked author for this post.

WCHS

Reply | Quote

Rick Corbett wrote:

I installed 7x Taskbar Tweaker and didn’t find any settings that would affect just the taskbar.

I un-installed 7+ Taskbar Tweaker on the ‘bad’ machine’s MSA, admin account. It didn’t make a difference. SH is still misbehaving. {It wasn’t installed on the 2nd, local, standard account on the ‘bad’ machine. so I was only un-installing it on the one account.}

It could be the case that some debris was left behind, even though un-installing it, but it certainly looks like this 3rd party app is not the culprit.

I’ve installed it again on the ‘bad’ machine’s MSA, admin account and I’ll leave it the way it was before — with all of my customized settings and including the default ‘run at start up’. (I really depend on it)

As an aside, you probably know that you haven’t heard from me for more than a few days … end of the month matters to take care of AND then a big storm that knocked out power.

I’m getting ready to run search_highlights_fix.reg In your instructions at 2537547, you didn’t say anything about extracting from the .zip folder. Will the file (and its companion UNDO file) run without extracting??

Anything that has changed your mind about how the search_highlights_fix.reg file might fix things, now that you’ve done some more investigating??

Reply | Quote

WCHS wrote:

I wonder about the “(and updating)”. It looks to me that New and interests is still running as ‘Enabled’ (you see it in the Taskbar Context-menu) and you see the “gleam”, so it didn’t update, as you thought it would.

WCHS wrote:

I have always thought that you have to RESTART in order for the changes like this to take effect.

That’s not been my experience.

Unlike Group Policy changes in a domain environment (where I believe there’s a 90 minute delay for gpupdate to kick in, with a load-spreading offset of approx. 30 minutes so not all machines are instructed to update at once), I’ve often seen immediate changes after clicking on Apply in the Local Group Policy Editor so assumed that it carries out a gpupdate /force, i.e. immediately.

However, you know what they say about assumptions… I may be wrong. Unfortunately I haven’t found any documentation to clarify whether LGPE‘s Apply uses gpupdate with or without the /force switch, or even just a randomised timer.

The Microsoft documentation I found shows “Some security policy settings require that the device be restarted before the setting takes effect.”… but I doubt a taskbar Search Box ‘gleam’ comes under the umbrella of a security setting.

I did find an article about Group Policy in a domain environment that stated “A reboot is necessary to be sure that all settings are applied.” but that’s not been my experience with the LGPE. Another article showed “Click “Enabled” and then “Apply,” and your change happens on this local computer.” which gives the impression the change is immediate (unless, as the Microsoft documentation states, it’s a security setting. However, it then went on to show “GPO updates occur at some time interval on computers throughout the network differently or on a reboot.“… which to me suggests a randomised timer when you click on Apply.

Yes, a restart means the entire registry will be read in its entirety but an LGPE change is often just a single toggle value, so if the change isn’t immediately apparent after clicking Apply then entering gpupdate /force in a console should do the job… unless it’s a security setting.

1 user thanked author for this post.

WCHS

Reply | Quote

Rick Corbett wrote:

Still searching for a setting that’s responsible for graying-out the Open on hover option of either Search Highlights or News and interests… unsuccessfully.

The greying-out of the Open on hover option seems to be contingent on some kind of IF-THEN. And the IF-THEN does not work for News and interests in the same way it works for Search. I say this because
1) for News and interests, it gets greyed out, if ‘Turn off’ IS checked. Otherwise (if either of the two ‘Show …’ options are checked), it’s bright and available for marking with a check.
2) for Search highlights, it gets greyed out, if ‘Show search highlights’ is NOT checked. And if you check ‘Show search highlights’, then the Taskbar Search Menu disappears altogether and you have to open the Taskbar Context Menu again, go to Search, and you will find the ‘Open on hover’ bright and available for marking with a check.

Reply | Quote

I have run the 2023_search_highlights_fix.reg file on the ‘bad’ machine. I restarted afterwards.

FOR SEARCH HIGHLIGHTS – OOBE, MSA, Admin account ( … fix.reg did not work )
For the main account (OOBE, MSA, Admin), here is a screenshot of the Taskbar, the Taskbar Context-Menu>Search, and the LGPE setting for ‘Search Highlights’.

The Taskbar Searchbox still does not show a ‘gleam’. The Taskbar Context-Menu >Search still shows the ‘Open on hover’ setting greyed out.

In other words, for Search, the ….fix.reg file did not make the changes that were expected. It’s the same as it was before running …fix.reg. See Search ‘bad’ – after Search_Highlights_fix.JPG

FOR NEWS AND INTERESTS – OOBE, MSA, Admin account (changes)
For the main account (OOBE, MSA, Admin), here is a screenshot of the Taskbar, the Taskbar Context-Menu>News and interests, and the LGPE setting for ‘News and interests.’

After running the …fix..reg file, the News and interests icon appeared on the Taskbar, showing the icon and temp text, as indicated in the screenshot. It opens on hover, too, in accordance with the checkmark beside ‘Open on hover’.

However, BEFORE I ran the …fix.reg file, ‘Turn off’ was checked, and so no icon was on the Taskbar. But, I can still turn it off and it works. See News and interests ‘bad’ – after Search_Highlights_fix.JPG

In a subsequent post, I will show the results of those 3 PS commands from #2533036.

Perhaps, the reason Search_Highlights_fix.reg did not fix things can be discerned there.

Reply | Quote

The 3 PS Commands:
A. Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\DSB -Name ShowDynamicContent There are no changes from Before to After.

B. Get-ItemPropertyValue -Path HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings -Name IsDynamicSearchBoxEnabled There are no changes from Before to After).

See PS A ‘bad’ & PS B ‘bad’ – before & after.JPG

C. Get-ChildItem -Path ‘HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\’ There ARE changes from before to after. See PS C Feeds ‘bad’ – before & after.JPG

FEEDS: ‘GOOD’ MACHINE VERSUS ‘BAD’ MACHINE, both BEFORE and AFTER …fix.reg

The Feeds ‘good’ screen is a bit different from the Feeds ‘bad’ after screen (apart from the difference in the order of properties). The property list for the‘good’ machine shows 10 properties. See PS C Feeds ‘good’.JPG

I have summarized those differences in the ‘Feeds’ PS command (i.e., Get-ChildItem -Path ‘HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\’) You can see the property that was added and the property that was removed in the ‘bad’ – after’ column. See Comparison of PS C Feeds for bad before, bad after, good.JPG

The keys/values in the bad -after column conform to what I am reading in the comments in the …fix.reg file. But, I wonder … should the DisabledbyReason: have a missing value?? I ask because the value is *NOT* missing on the ‘good’ machine.

Could this explain why Search_Highlights.reg did not work?

I haven’t run the UNDO reg file yet. I thought I’d wait to hear what you have to say about the PS C Feeds bad after results versus the PS C Feeds good results.

Reply | Quote

In the post, I clicked on the two PS C .JPG files and it says something about the wrong format or the files are corrupted. I will try to post them again here. I’ll take the apostrophes out of the file name and use ‘and’ instead of ‘&’ to see if that fixes the problem.

Reply | Quote

WCHS wrote:

In the post, I clicked on the two PS C .JPG files and it says something about the wrong format or the files are corrupted.

Well, I clicked on those two PS C.JPG files again in the #2541878 post and now they will open.

So, I guess there really wasn’t a problem with them. But, you have the images showing now in #2541889.

Reply | Quote

My difficulty is that I can’t find any documentation nor can I duplicate the grayed-out Open on hover option.

I’ve tried multiple times to ‘break’ the option on my test machine but to no avail. That makes it difficult, if not impossible, to make comparisons between ‘good’ and ‘bad’. Your results are suspect because a new account doesn’t show the same issues.

Broadly speaking, the ‘Feeds‘ key in the registry appears to relate solely to News and interests whilst the Feeds/DSB sub-key appears to relate solely to Search Highlights. There’s a Feeds/FeedRepositoryState sub-key which appears to relate to both which I haven’t yet looked at.

I think it’s time to make a comparison between the Feeds key (and sub-keys) of your current MSA account with the Feeds key (and sub-keys) of the new local account, both on the ‘bad’ machine. One doesn’t ‘work’, the other does. What I’d like to do is have you export both Feeds keys in their entirety, i.e. sub-keys as well (for example, as bad.reg and good.reg) and post them in a zip file.

If I then merge bad.reg in my test machine and Open on hover suddenly becomes grayed-out then we’ll know we’re on the right track with Feeds and/or its sub-keys so can then compare the two in their entirety, including the Feeds/FeedRepositoryState sub-key.

If nothing changes with Open on hover then it looks like I’ll have to look elsewhere in the registry (even though I’ve already scanned the registry for Open on hover, OpenOnHover and Hover settings).

To export the Feeds key (including sub-keys), do this:

1. Sign in with your usual MSA account.

2. *Right*-click on Start and select Windows PowerShell – not Windows PowerShell (Admin).

3. When the PowerShell console opens, type cmd into it then press RETURN/ENTER. (This will change the console from PowerShell to commandline mode and will prevent a ‘file write’ error.)

4. Copy/paste the following command into it then press RETURN/ENTER:

reg export HKCU\Software\Microsoft\Windows\CurrentVersion\Feeds %userprofile%/desktop/bad.reg

5. Sign out of your MSA account and sign on with the new local account.

6. Do steps 2-4 again but change the filename to good.reg. You can then close the console and sign-in to your MSA account.

7. Zip both .REG files and attach to a post.

WCHS wrote:

But, I wonder … should the DisabledbyReason: have a missing value?? I ask because the value is *NOT* missing on the ‘good’ machine.

I cannot find any relevant documentation for DisabledReason=DisabledByPolicy… but my test machine (which works perfectly) doesn’t have a DisabledReason entry, nor should it with no relevant policy restrictions set in the LGPE. As a result, it’s not that it should have a missing value… IMO the entry itself shouldn’t be there.

The fact that the entry (and value) is present on your ‘good’ machine creates doubt… why is News and interests apparently working if a registry setting shows an apparent and relevant policy restriction? Where is the apparent restriction coming from if it’s not apparent in the LGPE, what does the restriction affect (nothing, apparently) and why isn’t it working?

Hope this helps…

1 user thanked author for this post.

WCHS

Reply | Quote

Rick Corbett wrote:

I think it’s time to make a comparison between the Feeds key (and sub-keys) of your current MSA account with the Feeds key (and sub-keys) of the new local account, both on the ‘bad’ machine.

OK. How about if when I run the reg export on the MSA account, I make it produce a Desktop/bad-badMSA.reg file? And when I run reg export on the local account, I make it produce a Desktop/bad-goodlocal.reg file? This will make it clear that these pertain to the two accounts on the ‘bad’ machine. Will a hyphen in the file name be OK? If not, I will omit the hyphen.

I say this because I want to keep the first part of the file name reserved for the ‘bad’ machine, so that it’s not confused with the other ‘good’ machine.

And, just to be clear, I haven’t done any UNDO steps.

Reply | Quote

MY QUESTION in #2541878:

WCHS wrote:

The keys/values in the bad -after column conform to what I am reading in the comments in the …fix.reg file. But, I wonder … should the DisabledbyReason: have a missing value?? I ask because the value is *NOT* missing on the ‘good’ machine.

YOUR ANSWER in #2541902:

Rick Corbett wrote:

I cannot find any relevant documentation for DisabledReason=DisabledByPolicy… but my test machine (which works perfectly) doesn’t have a DisabledReason entry, nor should it with no relevant policy restrictions set in the LGPE. As a result, it’s not that it should have a missing value… IMO the entry itself shouldn’t be there.

Shouldn’t it be “As a result, it’s not that it shouldn’t have a missing value … IMO the entry itself shouldn’t be there”??

In 2023_search_highlights_fix.reg, there are two commands/statements: (is this what you call them?):
1) In the section for “News and interests” on the taskbar, it says
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds]
And following that, it says
“DisabledReason”=-

2) In the section for DSB on the taskbar, it says
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Feeds\DSB]
And following that, it says
“DisabledReason”=-

Isn’t it in either of these places (or in both of them) in the .reg code that after running 2023_search_highlights_fix.reg on the ‘bad’ machine, that the DisabledReason property has a missing value? But, it shouldn’t have a missing value, but should *not* be there at all? Or, should it have a “DisabledByPolicy” value, because that’s what the ‘good’ machine has (albeit in a different place in the list of ‘Feeds’ properties: it is ordered last in the “Feeds” list on the ‘good’ machine, but comes after the ‘DynamicTextTruncated’ property on the ‘bad’ machine – is this difference in order significant?).

Thinking out loud here.

Reply | Quote

Rick Corbett wrote:

I think it’s time to make a comparison between the Feeds key (and sub-keys) of your current MSA account with the Feeds key (and sub-keys) of the new local account, both on the ‘bad’ machine. One doesn’t ‘work’, the other does. What I’d like to do is have you export both Feeds keys in their entirety, i.e. sub-keys as well (for example, as bad.reg and good.reg) and post them in a zip file.

Will I need to edit out personal info before posting the zip folder?

Reply | Quote

WCHS wrote:

Will I need to edit out personal info before posting the zip folder?

Personal info has no relevance to the issue so please edit it out using a placeholder, e.g.  substituting XXXXXXXX.

Reply | Quote

WCHS wrote:

How about if when I run the reg export on the MSA account, I make it produce a Desktop/bad-badMSA.reg file? And when I run reg export on the local account, I make it produce a Desktop/bad-goodlocal.reg file?

That’s absolutely fine. It’ll still be clear to me which .REG file to merge to see if I can break Open on hover on my test machine. 🙂

Reply | Quote

WCHS wrote:

Shouldn’t it be “As a result, it’s not that it shouldn’t have a missing value … IMO the entry itself shouldn’t be there”??

Yes… I was tired and fat-fingered.

WCHS wrote:

And following that, it says “DisabledReason”=-

See the Deleting Registry Subkeys and Values section in Microsoft’s How to add, modify, or delete registry subkeys and values by using a .reg file article.

It shows that placing a minus sign (Microsoft calls it a hyphen) after the equals sign following what Microsoft calls a DataItemName (and which I call an entry for ease-of-use and understanding) should have the effect of deleting both the entry and its data.

Your first 2 ‘before’ and ‘after’ screenshots of ‘bad’ PC in post #2541889 show that this was successful.

I have no idea why your ‘good’ PC works even though it shows the DisabledReason = DisabledByPolicy result.

Reply | Quote

MY MIS-STATEMENT:

WCHS wrote:

isn’t it in either of these places (or in both of them) in the .reg code that after running 2023_search_highlights_fix.reg on the ‘bad’ machine, that the DisabledReason property has a missing value?

I should have said, “that the DisabledReasonProperty is missing”. Big difference.

YOUR HELPING ME UNDERSTAND THE DIFFERENCE:

Rick Corbett wrote:

It shows that placing a minus sign (Microsoft calls it a hyphen) after the equals sign following what Microsoft calls a DataItemName (and which I call an entry for ease-of-use and understanding) should have the effect of deleting both the entry and its data.

AND YES, IT WAS SUCCESSFUL, AND NOW I’M CLEAR ON THE PURPOSE OF THE ENTRY.

Rick Corbett wrote:

Your first 2 ‘before’ and ‘after’ screenshots of ‘bad’ PC in post #2541889 show that this was successful.

🙂

Reply | Quote

Here are the two export files from the ‘bad’ machine after running “reg export …” at the prompt.
1) On the MSA, admin account (SH does not work): The file produced on the account’s Desktop is bad_badMSA.reg
2) On the local, standard account (SH works): The file produced on the account’s Desktop is bad_goodlocal.reg

Here are the Taskbar Search and News-Interests settings at the time the two export files were produced.

I see differences in the two export files. See Comparison of PS C Feeds for bad machine (MSA vs local) and good machine.JPG. (You’ve seen columns 1, 2, and 4 before in #2541878.) The yellow cells indicate differences I’ve observed in bad_badMSA.reg, where SH does not work vs bad_goodlocal.reg, where SH does work.

I hope you can make something of the differences in the two export files and can discover the cause of the SH problem on the MSA account. I’m stumped!!

Exported_HKCU_Feeds

Reply | Quote

Now that I have posted a zip folder with the results of the “reg export … ” commands in the MSA account and the local account …

I am wondering if I can do the February 22H2 Windows 10 updates. I’m updated as far as 22H2’s Jan patches (19045.2486, etc) and I need to update to 22H2’s Feb patches (19045.2604, CU (KB5022834), along with KB5022729 (Net Framework), KB5023288 (.NET 6.0.14), and Feb’s MSRT … this before March’s Patch Tuesday, Mar 14, whose patches I usually hide until DEFCON 3+. I’d like to get this new patching done this weekend.

Please let me know if this will interfere down the road with any SH investigations, possible fix(es) for it, etc. I hope not.

Reply | Quote

WCHS wrote:

I hope you can make something of the differences in the two export files and can discover the cause of the SH problem on the MSA account. I’m stumped!!

I was hoping the bad_badMSA.reg file would break both Search Highlights and News and interests on my test machine when merged, or at least one of them. It didn’t.

Search Highlights (i.e. Feeds\DSB section):
After rebooting, the ‘gleam’ remains visible in the taskbar Search Box and the Open on hover option remains active/not grayed out. The only 2 differences I can see between the Feeds\DSB section of the ‘bad’ and ‘good’ .REG files is:

‘Bad’ machine:
“IsBigGleam”=dword:00000001
“OpenOnHover”=dword:00000001

‘Good’ machine:
No entry for “IsBigGleam” at all
“OpenOnHover”=dword:00000000

News and interests (i.e. Feeds section):

This is apparently turned off on your ‘bad’ machine. When I merged the bad_badMSA.reg file, News and interests disappeared from the taskbar and Open on hover was grayed out in the context menu (although it remained checked). However, when I used the context menu to change it from Turn off to Show icon and text, the Open on hover option stopped being grayed out (and the News and interests ‘gleam’ re-appeared), i.e. all worked normally/as expected.

Looking at differences between the ‘bad’ and good .REG files, IMO it’s easier to compare visually:

I believe the data marked as a just reflects the difference between the MSA used on the ‘bad’ machine compared to the local account used on the ‘good’ machine. As such, I believe the differences can be discounted.

The 3 entries marked as b only exist in the ‘bad’ machine but only the ShellFeedsTaskbarOpenOnHover entry appears relevant.

The ‘good’ machine has a IsLocationTurnedOn entry c which doesn’t exist in the ‘bad’ machine.

That’s as far as I’ve got. Later today I’ll re-image my test machine and start playing with permutations of b and c.

Hope this helps…

Reply | Quote

WCHS wrote:

Please let me know if this will interfere down the road with any SH investigations, possible fix(es) for it, etc. I hope not.

Updating should have no effect on your end or mine (my test machine has just updated itself automatically… ‘cos I forgot to disable Windows Update).

Reply | Quote

Rick Corbett wrote:

The only 2 differences I can see between the Feeds\DSB section of the ‘bad’ and ‘good’ .REG files is:
‘Bad’ machine account:
“IsBigGleam”=dword:00000001
“OpenOnHover”=dword:00000001

‘Good’ machine account::
No entry for “IsBigGleam” at all
“OpenOnHover”=dword:00000000

Let’s call them ‘accounts’, instead of ‘machines’. There’s the ‘bad’ account and the ‘good’ account (both on the ‘bad’ machine).

Yes, I noticed those differences, too, and that’s why I posted screenshots of the Taskbar’s Content-Menu for ‘Search’ along with an image of the Taskbar Searchbox.

I did that because the ‘bad’ account’s Searchbox does *not* show a gleam (although the dword for the “IsBigGleam” entry is ‘1’) and of course, since the gleam does not show, it’s impossible to hover over it (although the dword for the “OpenOnHover” entry is ‘1’). And besides that, the Taskbar’s Context-Menu has ‘Show on hover’ greyed out, so you cannot check ‘Show on hover’, even if you wanted to. In other words, what you see on the Taskbar’s Context-Menu for ‘Search’ doesn’t jibe with what the dwords are.

And the ‘good’ account’s Searchbox does show a gleam (although there is no entry for “IsBigGleam”. This doesn’t seem to make sense, either. Unless, no entry means {take the default, which seems to be ‘show the gleam on the Searchbox’}.

What does “IsBigGleam” mean, anyway?? On the ‘bad’ account, the dword ‘1’ seems to mean {don’t gleam on the Searchbox, i.e, you don’t see gleaming there}?? Say what – the dword is ‘1’??? On the other hand, on the ‘good’ account, no entry for “IsBigGleam” seems to mean {gleam on the Searchbox, i.e., you see gleaming there}. So, does no entry mean ‘take the default, which is {gleam on the Searchbox}?

On another note, I checked AppData>Local>Packages>Microsoft.Windows.Search_cw…wy>Local State>Shell Feeds on both accounts. The bad account still looks like it does at #2537468, but the ‘good’ account looks like the image for the ‘good’ machine’!!

What would happen on your test machine, if ‘Show search highlights’ on the Taskbar Search Context-Menu were checked, but there were no GLEAM-LIGHT.svg and GLEAM-DARK.svg files?

+++++++++++++++++++++++++++++++

Rick Corbett wrote:

News and interests (i.e. Feeds section):
This is apparently turned off on your ‘bad’ machine. ….. i.e. all worked normally/as expected.

Yes, ‘News and interests’ is turned off. But, if were not turned off (i.e., either ‘Show icon and text’ or ‘Show icon only’ were checked), the News and interests icon would show up on the Taskbar , and if ‘Show on hover’ were also checked, you would be able to hover over the icon and see hovering results. So, in sum, ‘News and interests’ is working OK in both accounts.

++++++++++++++++++++++++++++++
About the red b) section: (which pertains to News and interests) The behavior is the same in both accounts.
1. If I check either ‘Show icon and text’ or ‘Show icon only’, then ‘Open on hover’ is automatically checked. Maybe, that’s what “ShellFeedsTaskbarOpenOnHover”=dword:1 means.
2. I could manually uncheck ‘Open on hover’, if I want to, but I’ve left it checked, so hovering produces a hover screen, hence, “ShellFeedsTaskbarOpenOnHover”=dword:1.
3. If I check either ‘Show icon and text’ or ‘Show icon only’, I have not also checked ‘Reduce taskbar updates’. Maybe, that’s what “ShellFeedsTaskbarContentUpdateMode”=dword:0 means, i.e., ‘Reduce taskbar updates’ is unchecked.
4. The hover screen has icons at the top – the reverse circle is for ‘Refresh feed’ and the greater-than-caret is for ‘See more news’. Maybe, the presence of either of these icons at the top of the hover screen is what “ShellFeedsTaskbarPreviousViewMode”=dword:1 is for.

++++++++++++++++++++++++++++++
About the red c) section: “IsLocationTurnedOn”. Where is this in the Windows Settings?? If it is under Settings>Privacy>Apps permissions>Location, the settings are identical for both accounts.
1. Allow access to location on this device: ON
2. Allow apps to to access your location: ON
3. Choose apps which can access your precise location: only Maps and Weather are ON. All other listed apps are OFF.
I have no idea why the ‘good’ account has this registry entry, but the ‘bad’ account does not, even though the Windows location settings are identical for the two accounts.

Reply | Quote

WCHS wrote:

Let’s call them ‘accounts’, instead of ‘machines’.

You’re quite right, my mistake.

WCHS wrote:

I did that because the ‘bad’ account’s Searchbox does *not* show a gleam (although the dword for the “IsBigGleam” entry is ‘1’)

Here’s the problem… I think I’ve proved that the ‘display/not display’ result is controlled by an LGPE policy setting  (post #2537804), e.g. Search Highlights:

… yet you’ve changed the LGPE entries back to Not configured. Your ‘bad’ account is behaving as if the LGPE entry for Allow search highlights was still in use, set to Enabled and with EnableDynamicContentInWSB set 0. This makes no sense and I have no explanation for this behaviour other than I believe account profile corruption is involved.

WCHS wrote:

What does “IsBigGleam” mean, anyway??

Who knows? There’s no documentation that I can find and the only relevant Google results are, funnily enough, images from this topic. 🙂

I had assumed at first that IsBigGleam was linked to whether the taskbar was showing normal-sized ‘buttons’ or small ‘buttons’ . For example: If small ‘buttons’ is ON then IsBigGleam is 0 and vice versa… but no, toggling small ‘buttons’ on and off makes no change to the IsBigGleam setting.

Here’s what I’ve tried this morning to Search Highlights (Feeds\DSB in the registry). The default Search Highlights entries – in registry order – are as follows… so I’ve tested them in that order:

"DynamicText"="" 
"DynamicTextTruncated"=""
"IsBigGleam"=dword:00000001 
"IsDynamicContentAvailable"=dword:00000001 
"IsEnabledByServer"=dword:00000001
"OpenOnHover"=dword:00000001
"ShowDynamicContent"=dword:00000001
"UseDefaultGleam"=dword:00000000

(I’ve excluded the entry for ExpirationTime as I don’t believe it has any relevance to toggle states of 0, 1 or ‘not present’.)

1 and 2. DynamicText and DynamicTextTruncated
There are no data values for either of these two string entries by default. Deleted both entries, refreshed taskbar. Result:  The ‘gleam’ disappeared for a moment then returned. I refreshed the registry and both entries had been re-added automatically. I did it again with the same result… the behaviour is consistent.

3. IsBigGleam
Deleted the IsBigGleam entry, refreshed the taskbar (by restarting explorer.exe). Result: No change, ‘gleam’ still there.

4. IsDynamicContentAvailable
Changed IsDynamicContentAvailable from 1 to 0, refreshed taskbar. Result: The ‘gleam’ disappeared for a moment then returned. I refreshed the registry and the IsDynamicContentAvailable setting had been changed back to 1. I did it again with the same result… the behaviour is consistent.

Deleted the IsDynamicContentAvailable entry completely, refreshed the taskbar. Result: The ‘gleam’ disappeared for a moment then returned. I refreshed the registry and the IsDynamicContentAvailable entry had been re-added automatically. I did it again with the same result… the behaviour is consistent.

5. IsEnabledByServer
Changed IsEnabledByServer from 1 to 0, refreshed taskbar. Result: The ‘gleam’ disappeared for a moment then returned. I refreshed the registry and the IsEnabledByServer setting had been changed back to 1. I did it again with the same result… the behaviour is consistent.

The ‘gleam’ disappeared for a moment then returned. I refreshed the registry and the IsEnabledByServer entry had been re-added automatically. I did it again with the same result… the behaviour is consistent.

6. OpenOnHover
Changed OpenOnHover from 1 to 0, refreshed taskbar. Result: Hovering over the ‘gleam’ no longer opens the dynamic content.

Changed OpenOnHover from 0 to 1, refreshed taskbar. Result: Hovering over the ‘gleam’ opens the dynamic content.

Deleted the OpenOnHover entry completely, refreshed taskbar. Result: Hovering over the ‘gleam’ opens the dynamic content. Entry was not added back automatically.

Re-added OpenOnHover entry from backup .REG file, changed entry from 1 to 0 (i.e. no OpenOnHover), refreshed registry, deleted entry completely, refreshed taskbar. Result: Entry was not added back automatically and hovering over the ‘gleam’ opened the dynamic content. It’s apparent that the default is always 1 unless toggled to 0 and no entry at all also uses the equivalent of an OpenOnHover setting of 1.

7. ShowDynamicContent
Changed ShowDynamicContent from 1 to 0, refreshed the taskbar. Result: The ‘gleam’ disappeared. Problem: I already knew this entry was important, hence why  the  2023_search_highlights_fix.reg file included “ShowDynamicContent”=dword:00000001… so I don’t think it can be that in your ‘bad’ account. There must be something else in play.

Changed the ShowDynamicContent setting back to 1, refreshed the taskbar. Result: The ‘gleam’ returned.

Deleted the ShowDynamicContent entry completely, refreshed the taskbar. Result: The ‘gleam’ remained.

Re-added the ShowDynamicContent entry with default setting of 1, refreshed taskbar. Result: No change, the ‘gleam’ remains.

8. UseDefaultGleam
Changed UseDefaultGleam from 0 to 1, refreshed taskbar. Result: The ‘gleam’ changed to the static ‘gleam’… then changed back again to a dynamic ‘gleam’. I refreshed the registry and the UseDefaultGleam setting had been changed back to 0. I did it again with the same result… the behaviour is consistent.

There are no more Search Highlights entries to test… and I still haven’t managed to change the Open on hover option to grayed out in the context menu.

WCHS wrote:

About the red c) section: “IsLocationTurnedOn”. Where is this in the Windows Settings??

I have no idea. In Settings I have Allow access to location on this device, Allow apps to access your location, Default location and Location history all set to OFF based on the choices I made during OOBE setup for this first account.

I’m taking a break for a family visit. I’ll be back fairly soon to test News and interests settings.

Hope this helps…

1 user thanked author for this post.

WCHS

Reply | Quote

WCHS wrote:

On another note, I checked AppData>Local>Packages>Microsoft.Windows.Search_cw…wy>Local State>Shell Feeds on both accounts. The bad account still looks like it does at #2537468, but the ‘good’ account looks like the image for the ‘good’ machine’!!

What would happen on your test machine, if ‘Show search highlights’ on the Taskbar Search Context-Menu were checked, but there were no GLEAM-LIGHT.svg and GLEAM-DARK.svg files?

I’m wondering if the ‘Open on hover’ would be greyed out. Maybe, there’s something in the code (not the registry) that says “if GLEAM-LIGHT.svg/GLEAM-DARK.svg has an older date, then update to the current date. If there are no .svg files at all, then grey-out ‘Open on hover’/make it inactive”. So, if these .svg files were removed, then what happens to ‘Open on hover’?

Reply | Quote

WCHS wrote:

What would happen on your test machine, if ‘Show search highlights’ on the Taskbar Search Context-Menu were checked, but there were no GLEAM-LIGHT.svg and GLEAM-DARK.svg files?

A very good question… and I’m now able to get round to testing it. I did this:

1. I confirmed Show search highlights was checked in the taskbar context menu for Search.
2. I *moved* the two .SVG files from %localAppData%\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\LocalState\ShellFeeds\ to the desktop.
3. I used Task Manager to restart explorer.exe in order to refresh the taskbar.

Result:

1. The Search Box ‘gleam’ remained.
2. The Open on hover context menu option in Search did not gray out.
3. Two new GLEAM-DARK.svg and GLEAM-LIGHT.svg files were created in the %localAppData%\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\LocalState\ShellFeeds\ folder automatically.

This obviously poses the question… why does your ‘bad’ account not do the same? On my test machine there’s obviously something monitoring the running state of Search Highlights and correcting what it sees as missing and/or misconfigured. That much is obvious from my previous testing of each Search Highlights entry in the registry. So what does the monitoring?

So, here’s the logical next step IMO… copy the two .SVG files from your ‘good’ account to your ‘bad’ account then restart and see what happens.

After that it may come down to listing running processes and/or services on both your ‘good’ and ‘bad’ accounts then comparing them.

Hope this helps…

1 user thanked author for this post.

WCHS

Reply | Quote

COPYING .SVG FILES
I made sure that the two .svg files in the ‘good’ account had the current day’s date on them. I did that by going to the ‘good’ account, clicking on the ‘Taskbar>News and interest’ setting and choosing to ‘Show icon only’ {It had been ‘Turn off’} **The date on the two files immediately changed to the current day and time. Then, I right-clicked on each .svg file, chose ‘copy’, and then pasted them into the ‘bad’ account at the %localAppData%\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\LocalState\ShellFeeds location. As a result, an exact copy of the two .svg files appeared there in the ‘bad’ account, exactly where they are in the ‘good’ account.

I looked at Taskbar>Search to see if the settings had changed. They had not. ‘Show search highlights’ was still checked and ‘Open on hover’ was still greyed out. (I didn’t really expect a dynamic change, and indeed, there wasn’t one.)

Then, a restart. Unfortunately, the two .svg files that I had pasted into the ‘bad’ account’s %localAppData%\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\LocalState\ShellFeeds folder are no longer there. They disappeared at/after the restart. { I checked the Recycle Bin and they are not there.} ‘Taskbar>Search’ settings did not change: ‘Search highlights’ is still checked and ‘Open on hover’ is still greyed out.

**OF INTEREST:
1) There definitely is some connection between Search Highlighta and News and Interest. I say this because *IF* the .svg files are old because the ‘good’ account has not been used for sometime and because the ‘News and interests’ has been turned off for some time, then when you either ‘Show icon and text’ or ‘Show icon only,’ (which is a News and interest setting), the .svg files for the Search Highlight gleam are refreshed to the current day’s gleam.

There must be some documentation of this refresh in ‘Events’, don’t you think? If so, would this provide some clue as to how/where the currency of the gleam is being monitored?

2) I have also noticed that if the ‘good’ account has not been used for some time, when the account is opened, the gleam does not automatically change to the gleam-of-the-day. It is the gleam that was current on the day the account was last used. However, it will change to the gleam-of-the-day, if you click on the old gleam in the Searchbox. Would this action be recorded in Events and if so, would Events provide a clue as to what process(es) is/are involved in refreshing the gleam? (I’m not sure if the old gleam in the Searchbox would have automatically updated itself, given some time to do so.)

But, on the ‘good’ machine, the gleam will change to the gleam-of-the-day as soon as the clock moves past midnight.

3) It’s clear that merely putting those .svg files where they should be in the ‘bad’ account isn’t going to fix anything.
The difference in those two registry entries for the ‘bad’ account versus the ‘good’ account (#2542353) still prevails. Could one or both of these be responsible for populating (or not populating) %localAppData%\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\LocalState\ShellFeeds?

Reply | Quote

WCHS wrote:

There must be some documentation of this refresh in ‘Events’, don’t you think? If so, would this provide some clue as to how/where the currency of the gleam is being monitored?

I turned on my test machine and it opened the last folder I had been viewing, the ShellFeeds one with both .SVG files in. I noticed that they (and the .JSON file) had all been modified at the time I turned the machine on.

I used Nir Sofer’s FullEventLogView to search *all* event levels of *all* Event logs created at the time the 3 files were updated. There was no mention of any of the files and only one possible backgroundTaskHost.exe process event that may be relevant (although I discovered new telemetry events that I wasn’t previously aware of and have made a note of the Microsoft-owned endpoint).

So, as Event logs didn’t help, the next step is going to have to be Process Monitor (ProcMon), configured to filter for changes to the ShellFeeds folder. It will be a good test of ProcMon as it’s just been updated a few days ago.

1 user thanked author for this post.

WCHS

Reply | Quote

This looks like it’s getting deep. I hope I can hang in there with you!!

Reply | Quote

WCHS wrote:

This looks like it’s getting deep. I hope I can hang in there with you!!

Up until now we’ve just been looking at the registry… a database of recorded changes already made. It’s also been useful trying to understand the interactional relationship of Search Highlights to News and interests.

Even though many changes to the HKEY_CURRENT_USER registry hive are dynamic (i.e. make a change and the results often show immediately after the change, possibly prompted by a refresh of explorer.exe to update the taskbar), the registry isn’t a change mechanism itself. It needs outside assistance to effect change (for example, the front-end LGPE which fires gpudate.exe when you click on the Apply button).

ProcMon will, hopefully, show what’s actually making the changes. It records (nearly) every event that occurs in Windows as it happens, dozens and dozens a time every second. (I write ‘nearly’ because there’s a way to make ProcMon look even lower into the depths of what’s going on… but it’s not necessary for what we want here.)

 

1 user thanked author for this post.

WCHS

Reply | Quote

So, I prepped ProcMon with a filter that, in English, meant ‘Show me only events that make changes to the %localAppData%\Packages\Microsoft.Windows.Search_cw5n1h2txyewy\LocalState\ShellFeeds\ folder’… and let it capture events.

I was more than surprised that it’s explorer.exe making changes to the folder and, specifically, updating the .SVG image files:

That’s the core ‘in-your-face’ OS shell… and it’s monitoring/changing what is, IMO, essentially a frippery. Not even the background ‘Windows Shell Experience Host’ process which I would have understood more.

I don’t actually know how to progress this any further.

1 user thanked author for this post.

WCHS

Reply | Quote

I’ve been thinking about this… and I don’t understand the mindset of making a core process –  so important to Windows’ stability and functionality – monitor/change such a bunch of nonsense IMO as Search Highlights/News and interests.

It makes no sense whatsoever. I must have made a mistake somewhere in my test methods.

Reply | Quote

I suppose there’s a small possibility of system file corruption. Have you considered opening the PowerShell console (as Admin) and entering sfc /scannow to check?

Have a look at Option 3 of How to Repair System Files with SFC Command in Windows 10 for more info.

Hope this helps…

1 user thanked author for this post.

WCHS

Reply | Quote

Rick Corbett wrote:

I suppose there’s a small possibility of system file corruption. Have you considered opening the PowerShell console (as Admin) and entering sfc /scannow to check?

I had thought of doing that check early on because I am familiar with that PS command, since I always run sfc /scannow after I install the monthly Windows 10 Tuesday Patches. I just ran it again and the result is, as usual, “Windows Resource Protection did not find any integrity violations”.

I also just ran DISM /Online /Cleanup-Image /ScanHealth to see if Windows processes have reported errors when trying to run from the Windows components store. The result is “No component store corruption detected”.

Since this is the result of /ScanHealth, I am guessing that it wouldn’t do any good to run DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\Sources\install.wim where D: is the drive letter of a mounted iso file. (I have an iso file for 21H2, but not for 22H2).

Also, I have always had Fast Startup turned OFF.

Reply | Quote

WCHS wrote:

Since this is the result of /ScanHealth, I am guessing that it wouldn’t do any good to run…

I don’t think so. The System File Checker results answered my query.

There are no more registry settings to check so I don’t really know what to suggest next, other than use the new account and change it to MSA and copy data from the ‘bad’ account to the ‘good’ account.

Reply | Quote

Rick Corbett wrote:

so I don’t really know what to suggest next,

Going back to #2542353,

1) you don’t think making the “IsBigGleam” entry go missing and changing the dword for the “OpenOnHover’ entry to 0 will do any good? (See #2542353, in particular the differences between the orange and the yellow columns in Comparison of PS C Feeds for bad account and good account on bad machine.JPG )

2) Did you find anything out when playing with the differences in (b) and (c) of #254353?
+++++++++++++++++++++++++++++++

Reply | Quote

WCHS wrote:

1) you don’t think making the “IsBigGleam” entry go missing and changing the dword for the “OpenOnHover’ entry to 0 will do any good?

I deleted the IsBigGleam entry and changed the DWORD value for OpenOnHover to 0 then restarted Explorer to refresh the taskbar. As you can see, both ‘gleams’ are still there:

… but hovering now does nothing, as expected. So, no, it didn’t do any good.

WCHS wrote:

2) Did you find anything out when playing with the differences in (b) and (c) of #254353?

ShellFeedsTaskbarPreviousViewMode – This entry isn’t relevant.

ShellFeedsTaskbarContentUpdateMode – This entry records the speed of updating, the equivalent of using the context menu to Reduce taskbar updates, i.e. the refresh interval. Again, not relevant.

ShellFeedsTaskbarOpenOnHover – This entry doesn’t appear on your ‘good’ machine yet is set to a DWORD value of 1 on your ‘bad’ machine… which is exactly the same value as on my fully working test machine. As a result it’s safe to say that the section of 3 entries I marked as b have no effect on the issue.

The ‘good’ machine has a IsLocationTurnedOn entry (c) which doesn’t exist in the ‘bad’ machine. The entry on the ‘good’ machine has a DWORD value of 1; my test machine has a DWORD value of 0. That’s because the choices I made during OOBE turned off all entries in Settings > Privacy > Location. (As a result, my machine makes a guess that it’s in the north of England when it’s actually in the south-west.) So, not relevant to the issue.

I *have* found an additional ‘per user’ Search setting called IsDynamicSearchBoxEnabled that is apparently relevant to the display of Search Highlights. Well, I didn’t find it… I read about it on TenForums. My only reservation about suggesting trying it is that my test machine doesn’t have the entry at all, yet works perfectly… so I’m wondering how relevant it is.

(The same TenForums article describes an ‘all users/per machine’ policy setting called EnableDynamicContentInWSB which should be removed. However, this would have shown up in the Group Policy results report if it had been configured so, again, not relevant.)

1 user thanked author for this post.

WCHS

Reply | Quote

This is a reply (and clarification) to #2543314.

A REMINDER FOR READERS: There are two accounts on the ‘bad’ machine – a ‘bad’ account and a ‘good’ account. Whenever the word ‘machine’ is used here in post #2543314, it really means ‘account’.

TO RECAPITULATE FOR READERS:
BACKGROUND: In the LGPE, A) at Local Computer Policy|Computer Configuration|Administrative Templates|Windows Components|Search > the ‘Allow search highlights’ policy setting is ‘Not configured’. (’Not configured’ is tantamount to ‘Enabled’). B) …| Windows Components|News and interests>the ‘Enable news and interests on the taskbar’ policy setting is ‘Not configured’. ( Here, too, ‘Not configured’ is tantamount’ to ‘Enabled’).

1)The ‘bad’ account was set up in the OOBE routine as MSA, administrative. A) It has three problems with Search Highlights: i) when the Taskbar>Search>Show search highlights is checked, the ‘slice of pizza’ does *not* appear on the Taskbar Searchbox (unexpected). When it UNchecked, the ‘slice of pizza’ does not show on the Searchbox (expected). ii) the Taskbar>Search>Open on hover is greyed out (unexpected). iii) when searching from the Taskbar Searchbox, the flyout has one panel (unexpected). B) The ‘bad’ account has no problems with Taskbar>News and interests (expected).

2)The ‘good’ account was later added. It was set up as local, standard. A) It has no problems with Search Highlights: i) when the Taskbar>Search>Show search highlights is checked, the ‘slice of pizza’ appears on the Taskbar Searchbox (expected). When it is Unchecked, the ‘slice of pizza’ does not show on the Searchbox (expected). ii) the Taskbar>Search>Open on hover is bright, and can be checked or unchecked (expected). iii) when searching from the Taskbar Searchbox, the flyout has two panels (expected). B) The ‘good’ account has no problems with Taskbar>News and interests (expected).

I think I’m ready to throw in the towel. It looks to me that it’s a crack in the wall, signalling a angled stud in the wall and not signalling a sinking footer in the foundation. (For the reference to a crack in the wall, see last paragraph of #2543408.)

Reply | Quote

From the peanut gallery.  First off the two of you have infinite loads of patience.

Personally I do not like search highlights, turn it off and in fact wonder why in Windows 11 the dang settings has moved to permissions (which IMHO make zero sense).  Whenever I remote into a client’s machine and see search highlights still on – either by choice or not knowing where to turn it off, I get itchy fingers wanting to turn it off for them.

At this point in time even the developers of 11 would probably go “wow, I didn’t know that”.

Susan Bradley Patch Lady

1 user thanked author for this post.

WCHS

Reply | Quote

Susan Bradley wrote:

First off the two of you have infinite loads of patience.

And loads and loads of curiosity, maybe more than patience.

Susan Bradley wrote:

At this point in time even the developers of 11 would probably go “wow, I didn’t know that”.

This is Windows 10. This ‘bad’ machine doesn’t support Windows 11. And, yes, @rick-corbett has become the guru of these two Windows 10 Taskbar settings (= Search Highlights and News and Interests). I really appreciate everything he has done to try to get to the bottom of the problem. In the process, he has illuminated just how quirky and/or surreptitious these two settings are.

Susan Bradley wrote:

I get itchy fingers wanting to turn it off for them.

There are actually TWO problems, one which is affecting ‘Show search highlights, such that even though checked, it does not show the gleam on the Taskbar Searchbox and shows a grey-out ‘Open on hover’. This, despite the fact that ‘Allow search highlights’ is ‘Not configured’ /’Enabled’ in the GP.

The other problem is that when searching for an app in the Taskbar Searchbox, the resulting flyout has one panel and not two. (See the images of the correct and the incorrect flyouts in #2534888). The two problems are somehow related in that because the ‘Allow search highlights’ is not configured property, no matter whether set to ‘Not Configured’/’Enabled’ or to ‘Disabled’ in the GP and no matter whether ‘Show search highlights’ is checked (turned on) or not checked (turned off) in the Taskbar settings, the flyout doesn’t have the two panels.

It’s like a crack in the wall of one room, which a) could signal a small problem in that particular place in the wall (maybe a stud is slightly angled) OR b) could signal a significant problem in the foundation (i.e, the footer is sinking and the entire side of the house is out of line and putting pressure on the entire structure). I was intent in whether b) was happening, and not particularly wanting to see the ‘slice of pizza’.

Reply | Quote

It feels like the 11 devs are different than the 10 which is why I said they’d be educated.

Often when someone finds weirdness even the developers weren’t aware of something.

Susan Bradley Patch Lady

1 user thanked author for this post.

WCHS

Reply | Quote

Susan Bradley wrote:

Personally I do not like search highlights, turn it off

I don’t have search highlights option on my Windows 10 Pro 22H2

Reply | Quote

That’s not where the option appears on Windows 11 (as Susan indicated):

Option One: Turn On or Off Search Highlights for Current User in Settings

Windows 11 Pro version 22H2 build 22621.1413 + Microsoft 365 + Edge

1 user thanked author for this post.

WCHS

Reply | Quote

Alex5723 wrote:

I don’t have search highlights option on my Windows 10 Pro 22H2

Is this because you have ‘Allow search highlights’ disabled in the GP??

Reply | Quote

You must have disabled it some other way.  I see it *all* the time on computers I remote into.

Susan Bradley Patch Lady

Reply | Quote

Susan Bradley wrote:

Personally I do not like search highlights, turn it off and in fact wonder why in Windows 11 the dang settings has moved to permissions (which IMHO make zero sense).

I dislike both Search Highlights and the related News and interests.

IMO their purpose is to add easily-trackable ‘user behaviour’ elements. It’s now all too easy to track 1) how many people turn the dynamic content ‘gleams’ off and, IMO much more importantly, 2) what specific articles are clicked on as a result of the default Open on hover panel behaviour. I think that this helps build up a ‘user interests’ profile (linked to MSA or even local account username), probably to better target additional ‘helpful and relevant’ dynamic content. IMO when the Open on hover panels appear, they’re like regular multiple choice questionnaires where you don’t even realise that you are being profiled.

I think this is why the entries have been moved to Windows 11’s Settings > Privacy umbrella… because ‘you are now the product‘.

How’s that for a tinfoil hat theory? 🙂

1 user thanked author for this post.

WCHS

Reply | Quote

WCHS wrote:

(“surreptitious” was used in #2543408) i.e., … In the process, he has illuminated just how … surreptitious these two settings are.

For the surreptiousness, see surreptitous

Too late to edit, thus this post.

Reply | Quote

Susan Bradley wrote:

You must have disabled it some other way.  I see it *all* the time on computers I remote into.

Isn’t this the standard search box which I have and is different from Search Highlights ?

Reply | Quote

Alex5723 wrote:

Isn’t this the standard search box which I have and is different from Search Highlights ?

The Windows 10 Search Box has had Search Highlights added to its right-hand side:

Whilst the Search Box concentrates on search results (local, web, etc. depending on how Search is configured), Search Highlights are what Microsoft describe as ‘interesting moments in time’.

Search Highlights display initially as a graphic which Microsoft calls a ‘gleam’. There’s actually several ‘gleams’ involved depending on whether the Search Box is using a light or dark background.

There’s also a difference between ‘types’ of ‘gleam’ – static or dynamic. Dynamic ‘gleams’ change based on ‘locale’ and ‘interval’. The ‘locale’ controls the content shown when the ‘gleam’ is hovered over or clicked on. So, for example, the content I see is based on my en-gb locale which, in turn, determines how a .JSON file is populated with URLS of dynamic content feeds – news, weather, memorable dates (Pancake Day, for example), etc. ‘Interval’ controls how quickly the dynamic content is updated.

Hope this helps…

1 user thanked author for this post.

WCHS

Reply | Quote

To @rick-corbett:
On my ‘good’ account (where SH is working), when Search Highlights is checked, I get this gleam, which celebrates International Pi Day. Is this gleam static? Or dynamic?

Reply | Quote

WCHS wrote:

I get this gleam, which celebrates International Pi Day. Is this gleam static? Or dynamic?

I had the same gleam yesterday for International Pi Day. It’s a dynamic one.

My current dynamic gleam shows ‘Chat with the new Bing’:

1 user thanked author for this post.

WCHS

Reply | Quote

WCHS wrote:

Is this because you have ‘Allow search highlights’ disabled in the GP??

To @Alex5723 et al,

What I mean here is, if it’s working *correctly* on your Windows 10/Pro, when you disable it in the GP editor at Local Computer Policy|Computer Configuration|Administrative Templates|Windows Components|Search by changing the ‘Allow search highlights’ policy-setting to ‘Disabled’ and then restart, the Taskbar>Search context-menu has no ‘Show search highlights’ option to check. And because it’s not there to check, there’s no ‘gleam’ in the Taskbar Searchbox.

So, is this the case for you — i.e., you Disabled ‘Allow search highlights’ in the LGPE?

Also, if you have ‘Allow search highlights’ either ‘Not configured’ or ‘Enabled’ in the LGPE, there will be a ‘Show search highlights’ option in the Taskbar>Search context-menu but the ‘gleam’ only appears in the Taskbar Searchbox if it’s checked — i.e., if it’s unchecked, there’ll be no ‘gleam’ in the Taskbar Searchbox.

These are the only ways I know to disable it so it doesn’t appear in the Taskbar Searchbox.

Reply | Quote

Hi @rick-corbett:
Thank you for your help in looking at this Search Highlights problem and your .REG file to try to fix it. Even though it didn’t work, I learned a lot from you about how to look inside the registry for clues (without actually going into it and rummaging around). This, in addition to using Notepad++ to make comparisons. In the process, you know more about this frippery and its companion, New and Interests, than anyone else on the planet, IMHO. You’ve been amazing in giving your time, patience, willingness, and know-how to look into it and to try to make sense of it.

I’m rather convinced that the problem doesn’t forebode a breakdown in the system and that I can just as well ignore it and consider myself lucky that it doesn’t work, thanks to your investigations!

Reply | Quote

WCHS wrote:

Thank you for your help in looking at this Search Highlights problem

Thank you for your kind words. To be fair, it was only your original question that piqued my interest and your subsequent very prescient questions that encouraged me to dig deeper… otherwise I would never, ever have looked at either Search Highlights nor News and interests.

Until your original question, my only prior experience of them both was working out how to automate turning both fripperies off. 🙂

I regret I was unable to help you solve your issue, but I learned a lot along the way – even about the Local Group Policy Editor (which normally I avoid).

I’ll share one last finding with you (and the many obvious lurkers this topic attracted).

It irked me that I couldn’t find any documentation about whether the LGPE used gpupdate or gpudate /force to force a re-read of policy entries in the registry as an alternative to having to restart the OS… so I created a test.

1. I used LGPE to change the Allow search highlights entry (Computer Configuration > Windows Components > Search) from Not configured to Disabled. Result: Nothing changed… the ‘gleam’ in the taskbar Search Box remained and there was no change to Search’s context menu appearance.

2. I opened an unelevated Windows PowerShell console and entered the command gpupdate. Result: No change to either gleam or context menu although the command executed successfully.

3. I entered the gpupdate /force command in the unelevated PowerShell console. Result: No change to either gleam or context menu although the command executed successfully.

4. I opened an elevated Windows PowerShell (Admin) console and entered the command gpupdate. Result: No change to either gleam or context menu although the command executed successfully.

5. I entered the gpupdate /force command in the elevated PowerShell (Admin) console. Result: No change to either gleam or context menu although the command executed successfully.

6. I used Task Manager to restart Explorer. Result: Changes to both ‘gleam’ (which disappeared) and Search’s context menu (Search Highlights disappeared).

Conclusion: Contrary to my previous belief and assertion, LGPE does *not* apparently use either gpudate nor gpupdate /force in either a ‘user’ or ‘Administrator’ context in this scenario when the Apply button is used to implement the change and dismiss the dialog.

The change appears to exist only in the LGPE UI… so I was wrong about my previous assertion ( #2539577) in this scenario.

The other thing I learned is that, depending on the context of the change, restarting explorer.exe is just as effective as restarting the OS in order to refresh the taskbar elements… and certainly much quicker.

_______________________________________________________________

One last thought: Don’t be afraid of the registry. Treat it with respect, create backups of any branches/keys before making changes to them, ask in places like this if you’re unsure… and you’ll have no problems. IMO it’s a valuable friend, not a foe to avoid.

Hope this helps…

1 user thanked author for this post.

WCHS

Reply | Quote