Search field in Settings no longer works (Windows 11 22H2)

The TLDR here is basically that unchecking the box is probably pointless, unless file attributes have a noticeable effect on file copy speeds. This can easily be benchmarked by anyone if they want to give it a go. Perhaps by adding the I index attribute it slows down how long it takes to copy a bunch of files, like a new game you're installing for example, but there's only 1 way to know--test it and post the results here.

A test you might do would be to copy like 10 gigabytes of lots of small files from a Fat32 drive onto your disk drive that is NTFS with that index box checked, and record how long it takes. Execute "rundll32.exe advapi32.dll,ProcessIdleTasks & pause" in a command prompt before copying so that all your background activities calm down first so they don't interfere. Then delete all those files you just copied from the NTFS drive, uncheck the box, reboot PC, run the background command again, then copy the 10 gigs and record the time. Was there a difference? Can it be replicated, or is it all within the margin of error?
 
Last edited:
Hellbovine said:
The TLDR here is basically that unchecking the box is probably pointless, unless file attributes have a noticeable effect on file copy speeds. This can easily be benchmarked by anyone if they want to give it a go. Perhaps by adding the I index attribute it slows down how long it takes to copy a bunch of files, like a new game you're installing for example, but there's only 1 way to know--test it and post the results here.
Click to expand...
Attributes are stored in the volume's MFT table, they don't have any impact on performance. They're flags to instruct other apps & services what to do when accessing them. If your file operations don't care about them, it won't make a difference.

Updating all the attributes in a volume can be a time consuming process with thousands of files. Not all folders or files will follow inheritance rules from the parent folder, and must be checked individually.
 
Hellbovine said:
The TLDR here is basically that unchecking the box is probably pointless, unless file attributes have a noticeable effect on file copy speeds. This can easily be benchmarked by anyone if they want to give it a go. Perhaps by adding the I index attribute it slows down how long it takes to copy a bunch of files, like a new game you're installing for example, but there's only 1 way to know--test it and post the results here.

A test you might do would be to copy like 10 gigabytes of lots of small files from a Fat32 drive onto your disk drive that is NTFS with that index box checked, and record how long it takes. Make sure you run "Rundll32.exe advapi32.dll,ProcessIdleTasks" before copying so that all your background activities calm down first so they don't interfere. Then delete all those files you just copied from the NTFS drive, uncheck the box, reboot PC, run the background command again, then copy the 10 gigs and record the time. Was there a difference? Can it be replicated, or is it all within the margin of error?
Click to expand...
Thanks for adwices - i will look into it - the only time i see the checked Index box is only on th C drive on NTFS formatted freash install as they are already unchecked on other drives from earlier installs, and my SSD (Samsung PM9A1) never give any probs regarding speed transfering files.
 
garlin said:
Updating all the attributes in a volume can be a time consuming process with thousands of files
Click to expand...
how much time is time? fresh install onto crucial mx500 you prolly looking at 30 seconds, give or take a few.

francis11 said:
the only time i see the checked Index box is only on th C drive on NTFS formatted freash install as they are already unchecked on other drives from earlier installs
Click to expand...
if you disable search/indexing in the image when you untick that box nothing happens because nothing has been indexed.
i have disabled search/indexing in an ltsc 1809 image with no hissyfits during setup.

francis11 said:
my SSD (Samsung PM9A1) never give any probs regarding speed transfering files.
Click to expand...
only once the write buffer is full, ssd to hdd can drastically slow down :(
 
Last edited:
Looks like Cortana is required to have if using search field on windows settings or else it shows no results. It was working without it though.
 
Interesting, windows search works on desktop, but in settings is shows nothing unless i bring back cortana.

VirtualBox_Windows_27_10_2022_17_31_54.png
 
1666936599923.png

don't really have cortana... on turkish its not functional and disabled anyways interesting maybe thats why
 
If I import this & add that reg key to NTLite reg section or post (user/machine) section
HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex from my registry
Click to expand...

Would that work to import the indexing settings (i.e. drives & locations for adding indexing & exclusions) that I used in my original (imported) machine?
 
Some of those exported Search Roots won't work, because they're machine-specific SID's. Those will be ignored since no such SID exists on the target install.

This reg branch must be imported from Post-Setup (and paired with killing Windows Index Service at the same time), because Windows will populate HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager the first time it runs.

The branch is empty in the offline image, which means if you integrated it then Windows will clobber your reg changes.
 
The more I think about, I don't think importing the rules from another PC is straightforward. You'd need a script or tool to replace every SID instance from the exported reg file, with the live system's current values. And I know from your previous posts, you have external drive content indexed too. This may or may not be mapped to the same drive on the new install.

Someone would have to write a tool, since Windows doesn't provide one.
 
garlin said:
The more I think about, I don't think importing the rules from another PC is straightforward. You'd need a script or tool to replace every SID instance from the exported reg file, with the live system's current values. And I know from your previous posts, you have external drive content indexed too. This may or may not be mapped to the same drive on the new install.

Someone would have to write a tool, since Windows doesn't provide one.
Click to expand...
garlin
I tried & tested this, backup up full reg from here
HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex

& add that REG file to everywhere, Ntlite reg section+ Post Setup User & machine section & it worked.
Iinstalled the ISO on the same machine adds all the win search indexing options that I set earlier (including drives to include indexing & driver/folder excluding from indexing).


However, I am unsure about two things

1. Where exactly the REG file need to be put in NTLite. As far as I know the NTLite Registry section & Post Setup (machine) section are the same & add all the regs for machines specific (HKLM) settings, where in other hand, the post (user) section does all the jobs for HKCU section.

So I need to figure this out whether this indexing REG needs to be added on both or only one section.

2. I used The backed up REG file I tested & used, I used in on the same machine/system from where it was imported.
I've to test/ check whether this REG file will work on another (a completely different system) or not.
 
I've written about this a number of times.

Where a reg file should be added is a matter of timing, based on whether a setting needs to exist before a Windows process runs for the first time (to manage it), or after the point Windows writes it (to prevent it from being overwritten).

- Changes added to Registry are integrated into the image. HKLM -> image's hive, HKCU -> Default User's hive.
To prevent some first-run behavior (ie. TamperProtection in Defender), the reg value must be there before the process starts. HKCU changes added here are most likely to get wiped out during new user provisioning.

- Changes added in Post-Setup (Machine) are mostly stable for HKLM, because they're past the point where Windows has completed new install & first-time tasks. HKCU updates don't work here because the "User" is SYSTEM, and not you.

- Changes added to Post-Setup (User) are mostly stable for HKCU, because they're past the point where new user provisioning has written its changes.

There is no guide for informing you whether to try Registry or Post-Setup (Machine) for any HKLM branch, with the exception of features you want to disable or control immediately when Windows restarts in the first reboot stage. Most of the time, Post-Setup is good enough.

Your SID is always different on two different installs. Unless you're naughty and disk cloned a non-generalized image.
Code: 
whoami /user
 
garlin said:
I've written about this a number of times.

Where a reg file should be added is a matter of timing, based on whether a setting needs to exist before a Windows process runs for the first time (to manage it), or after the point Windows writes it (to prevent it from being overwritten).

- Changes added to Registry are integrated into the image. HKLM -> image's hive, HKCU -> Default User's hive.
To prevent some first-run behavior (ie. TamperProtection in Defender), the reg value must be there before the process starts. HKCU changes added here are most likely to get wiped out during new user provisioning.

- Changes added in Post-Setup (Machine) are mostly stable for HKLM, because they're past the point where Windows has completed new install & first-time tasks. HKCU updates don't work here because the "User" is SYSTEM, and not you.

- Changes added to Post-Setup (User) are mostly stable for HKCU, because they're past the point where new user provisioning has written its changes.

There is no guide for informing you whether to try Registry or Post-Setup (Machine) for any HKLM branch, with the exception of features you want to disable or control immediately when Windows restarts in the first reboot stage. Most of the time, Post-Setup is good enough.

Your SID is always different on two different installs. Unless you're naughty and disk cloned a non-generalized image.
Code: 
whoami /user
Click to expand...
I know that & said the same (briefly).
You just described/elaborated it explicitly with all the details

so, as per that, here the discussed REG key path is
HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex
Click to expand...

Therefore, the most appropriate place to add that backed-up REG key is: NTLite Post Setup: Before Logon (Formerly labelled as Machine)

and NO, am not gonna clone anything to replicate the SID.
 
You must log in or register to reply here.
Back
Top