Am curious if there's any downside to wiping out SearchApp.exe?
<1> Open an admin window
<2> cd %windir%\SystemApps
<3> taskkill /f /im SearchApp.exe
The next step has to be done within a second or two.
Otherwise a new SearchApp.exe process is spawned.
Keep trying until you get the timing fast enough.
Best to type the taskkill and paste the move instantly thereafter.
<4> move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.old

Obviously I never use the Windows search feature (it doesn't do anything
useful). Assuming that I don't care for Windows search, is there any
downside that you can think of before I do it for real?
--
Cheers, Rob

On 2/13/2023 12:11 AM, RJH wrote:
> Am curious if there's any downside to wiping out SearchApp.exe?
> <1> Open an admin window
> <2> cd %windir%\SystemApps
> <3> taskkill /f /im SearchApp.exe
> The next step has to be done within a second or two.
> Otherwise a new SearchApp.exe process is spawned.
> Keep trying until you get the timing fast enough.
> Best to type the taskkill and paste the move instantly thereafter.
> <4> move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.old
>
> Obviously I never use the Windows search feature (it doesn't do anything
> useful). Assuming that I don't care for Windows search, is there any
> downside that you can think of before I do it for real?
>

Hopefully, the ownership should stop you. It would not
be Windows, if that did not happen, right ?

Generally, things involving Program installation, they use
the TrustedInstaller account.

*******

You can see in this snippet, the usage of Takeown and ICACLS, to
modify the permissions on the executable. And this assumes when
you're using File Explorer for a look, the OS will let you in there
with the folder permissions. This individual is deleting the thing,
rather than renaming it.

https://www.tenforums.com/windows-updates-activation/175412-stopping-annoying-forced-updates.html

takeown /s %computername% /u %username% /f "%WINDIR%\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\SearchApp.exe"
icacls "%WINDIR%\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\SearchApp.exe" /inheritance:r /grant:r %username%:F
taskkill /im SearchApp.exe /f
del "%WINDIR%\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\SearchApp.exe" /s /f /q

*******

It would be easy to do this from Linux, except for one thing. If the
OS applies "New style Compression" to a file, Linux cannot access
the file and gives "I/O Error". I presume this is all part of a
devious scheme or such.

So let's ask the system, what the attributes are

fsutil usn readdata C:\Windows\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\SearchApp.exe

File Attributes : 0x20

FILE_ATTRIBUTE_READONLY = 1 (0x1)
FILE_ATTRIBUTE_HIDDEN = 2 (0x2)
FILE_ATTRIBUTE_SYSTEM = 4 (0x4)
FILE_ATTRIBUTE_DIRECTORY = 16 (0x10)
FILE_ATTRIBUTE_ARCHIVE = 32 (0x20) <=== Archive bit is set
FILE_ATTRIBUTE_NORMAL = 128 (0x80)
FILE_ATTRIBUTE_TEMPORARY = 256 (0x100)
FILE_ATTRIBUTE_SPARSE_FILE = 512 (0x200)
FILE_ATTRIBUTE_REPARSE_POINT = 1024 (0x400)
FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800) <=== No Old Style Compression
FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000)
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000)
FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000)

sysinternals junction64.exe -s is recurse subdirectory, -q is don't print error messages

junction64.exe C:\Windows\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\SearchApp.exe

No junction, yet nfi.exe will not list the size of the thing, as Administrator.
A reparse point would be used, to signal "New Style Compression", and this
prevents Linux access with an "I/O Error" because the NTFS driver does not
know what to do.

*******

In any case, I did it from Linux,

mv SearchApp.exe SearchApp.exe.old

and it worked.

Now, I reboot to Windows. No pissy notifications on the screen (surprising!).

The side effects include not being able to stick the cursor in
a search box in Windows. The system knows the search agent is
unregistered.

It's possible, in the history of the partition in question,
this was done...

fsutil behavior set disablecompression 1 # disable new compression *machine wide*

I would think this would not survive an OS clean install,
and it would be stored in the Registry. I don't know if
there is a way to mark the partition itself for this FS attribute.

But the ease with which I did this from Linux, is puzzling.
I was expecting a fight.

fsutil behavior query disablecompression

DisableCompression = 0 (so it was not disabled by me)

Really weird, that it was so easy to do.

And I visited Windows Update, and it did not become wobbly. I
was expecting some "feedback" about search.

And while normally, you would just use the Powershell command
to remove an App, the ones with the "In-box bit set" resist
removal. I have tried clearing the In-box bit, on MSEdge,
then tried to remove MSEdge, and just one icon went away :-/
There is a belt and braces protecting those things.

Summary: Clear sailing here. No problemo so far (in my W10 VM).

Paul

On Mon, 13 Feb 2023 05:11:56 +0000, RJH wrote:
>
> Am curious if there's any downside to wiping out SearchApp.exe?
> <1> Open an admin window
> <2> cd %windir%\SystemApps
> <3> taskkill /f /im SearchApp.exe
> The next step has to be done within a second or two.
> Otherwise a new SearchApp.exe process is spawned.
> Keep trying until you get the timing fast enough.
> Best to type the taskkill and paste the move instantly thereafter.
> <4> move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.old

If you really want to turn off search indexing, why not just go to
Services.msc, select Windows Search, stop it, and then set it to
Disabled?

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

On 13 Feb 2023 at 9:59:16 AM, Stan Brown <the_stan_brown@fastmail.fm>
wrote:

> If you really want to turn off search indexing, why not just go to
> Services.msc, select Windows Search, stop it, and then set it to
> Disabled?

Why not? Well. Sir. I'll tell you why not.
You asked bloody why not, right?
Ahem! You sir! You challenged me sir!

(I'm stalling. I'm trying to think of a witty reply while I'm stalling.)

Sheesh. The real answer is that I didn't know how to do that.
Not until you just said so. That's why.

I just did it.
<1> Windows+R services.msc
<2> Windows Search > General > Stop
<3> Windows Search > General > Startup type > Disabled

Thanks! :->

--
Cheers, Rob

On 13 Feb 2023 at 6:58:09 AM, Paul <nospam@needed.invalid> wrote:

> Hopefully, the ownership should stop you. It would not
> be Windows, if that did not happen, right ?

I did it anyway.
I was just wondering what the disadvantages might be.

> In any case, I did it from Linux,
>
> mv SearchApp.exe SearchApp.exe.old
>
> and it worked.

It even worked in Windows when I did it but I had to do it fast.
taskkill /f /im SearchApp.exe
move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.old

> Now, I reboot to Windows. No pissy notifications on the screen (surprising!).

That's a good thing. :->

>
> The side effects include not being able to stick the cursor in
> a search box in Windows. The system knows the search agent is
> unregistered.

I don't even have the cortana box (or whatever you call it) anyway.
I never needed the search feature so why should it index all day.

> But the ease with which I did this from Linux, is puzzling.
> I was expecting a fight.

It was that simple in Windows too!
<1> Open an admin window
<2> cd %windir%\SystemApps
<3> copy (but do not yet paste!) this into your clipboard
move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.old
<4> taskkill /f /im SearchApp.exe
<5> Immediately paste your clipboard contents into the window!

It took a few tries before I realized I had to be fast.
But then it gave up without a fight.

>
> fsutil behavior query disablecompression
>
> DisableCompression = 0 (so it was not disabled by me)
>
> Really weird, that it was so easy to do.

Yup. You didn't even need to go to Linux to do it.
I don't think anyway.

I rebooted this morning and it seemed to be gone.

> And I visited Windows Update, and it did not become wobbly. I
> was expecting some "feedback" about search.

That I haven't done yet.

> Summary: Clear sailing here. No problemo so far (in my W10 VM).

Clear sailing here also but I did add what the other guy suggested.
<1> Windows+R services.msc
<2> Windows Search > General > Stop
<3> Windows Search > General > Startup type > Disabled

Thanks! :->

--
Cheers, Rob

On 2/13/2023 8:23 PM, RJH wrote:
> On 13 Feb 2023 at 9:59:16 AM, Stan Brown <the_stan_brown@fastmail.fm>
> wrote:
>
>> If you really want to turn off search indexing, why not just go to
>> Services.msc, select Windows Search, stop it, and then set it to
>> Disabled?
>
> Why not? Well. Sir. I'll tell you why not.
> You asked bloody why not, right?
> Ahem! You sir! You challenged me sir!
>
> (I'm stalling. I'm trying to think of a witty reply while I'm stalling.)
>
> Sheesh. The real answer is that I didn't know how to do that.
> Not until you just said so. That's why.
>
> I just did it.
> <1> Windows+R services.msc
> <2> Windows Search > General > Stop
> <3> Windows Search > General > Startup type > Disabled
>
> Thanks! :->
>

Check after a reboot and see if that control has
been altered on you.

There is a certain level of aggression around
search. This is why I was expecting trouble,
because it has a history of being aggressive
(infinite services restarts instead of three service restarts).

Because there's a Bing module in that folder (SearchApp folder),
it could be tied into recording the things you do on
the computer, which is why the subsystem should be
aggressive.

And it could be, that SearchApp keeps tabs on Search Service,
and maybe it is the thing that restarts the service. Since
you killed the SearchApp.exe first, maybe that will change
the outcome of the experiment (of disabling the service). Microsoft
uses a tag-team approach, like a malware would, for things
it wants to have running on the machine. They will use a
"second" software, to make sure the "first" software is
running and has not croaked. Scheduled Tasks can be wired up
for this stuff, too.

Paul

Paul wrote:

> RJH wrote:
>
>>   <1> Windows+R services.msc
>>   <2> Windows Search > General > Stop
>>   <3> Windows Search > General > Startup type > Disabled
>
> Check after a reboot and see if that control has
> been altered on you.

Alternatively there's an "Indexing Options" icon within control panel,
you can tell it not to index any folders, then delete and rebuild the
index, which would be empty at that point, and take it no time to run
when it felt like doing so.

In the days of spinning discs, I used to disable it, now I don't notice
it running.

On 14 Feb 2023 at 4:12:54 AM, Andy Burns <usenet@andyburns.uk> wrote:

>> Check after a reboot and see if that control has
>> been altered on you.
>
> Alternatively there's an "Indexing Options" icon within control panel,
> you can tell it not to index any folders, then delete and rebuild the
> index, which would be empty at that point, and take it no time to run
> when it felt like doing so.
>
> In the days of spinning discs, I used to disable it, now I don't notice
> it running.

I rebooted and the Windows search service stayed disabled (thanks to Stan).
I checked and the physical move of the search to the *.old stayed put also.
I also checked in the task manager and the SearchApp.exe is no longer there.

We'll have to see what a Windows Update will do (but that will take time).
With the cp method above, that makes three methods to turn off the indexing.

Recommended solution.
<1> Windows+R services.msc
<2> Windows Search > General > Stop
<3> Windows Search > General > Startup type > Disabled

Permanent solution.
<1> Windows+R cmd {control+shift+enter}
<2> cd %Windir%\SystemApps
<3> copy (but do not yet paste!) this into your clipboard
move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.old
<4> taskkill /f /im SearchApp.exe
<5> Immediately paste your clipboard contents into the window!

Alternative solution.
<1> Windows+R control.exe
<2> All control panel items > View by "Small icons" > Indexing Options
<3> ?

Mine says "Indexing is not running" so I'm not sure the next step.
There's an "Advanced" button with a "Rebuild" button both of which I pressed.
It didn't give an error but it didn't do anything either (which is to be expected).

I've never found Windows search to be of any use at all. Have you?
--
Cheers, Rob

RJH wrote:

> Alternative solution.
> <1> Windows+R control.exe
> <2> All control panel items > View by "Small icons" > Indexing Options
> <3> ?

<3> click Modify, then expand the folder tree and untick every folder
that you don't want indexed (possibly all of them)

<4> click advanced and then click rebuild

> I've never found Windows search to be of any use at all. Have you?

No, because I've used different search tools that don't chang with every
version of windows.

On 14 Feb 2023 at 8:27:04 PM, Andy Burns <usenet@andyburns.uk> wrote:
> <3> click Modify, then expand the folder tree and untick every folder
> that you don't want indexed (possibly all of them)
> <4> click advanced and then click rebuild

Got it. Thanks. This is a perfect example of how this newsgroup works for us!
This is useful for the archives too, so that it's useful for everyone later.
For that, I'll summarize the solution that remained after a Windows Update.

Recommended solution. (survives Windows Update)
<1> Windows+R services.msc
<2> Windows Search > General > Stop
<3> Windows Search > General > Startup type > Disabled

Alternative solution. (survives Windows Update)
<1> Windows+R control.exe
<2> All control panel items > View by > Small icons
<3> Indexing Options > Modify > then expand the folder tree
<4> Untick every folder that you don't want indexed (possibly all of them)
<5> Advanced > Rebuild

Deprecated solution. (does not survive Windows Update)
<1> Windows+R cmd {control+shift+enter}
<2> cd %Windir%\SystemApps
<3> copy (but do not yet paste!) this into your clipboard
move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.old
<4> taskkill /f /im SearchApp.exe
<5> Immediately paste your clipboard contents into the window!
>> I've never found Windows search to be of any use at all. Have you?
>
> No, because I've used different search tools that don't chang with every
> version of windows.

Between you and me, I can't imagine that anyone finds Windows Search useful.
All it does, for me, is annoy me by wasting cpu cycles doing its indexing.

To Paul's concern, I happened to get a Windows Update yesterday.
<1> Windows+R winver (Version 21H2 (OS Build 19044.2604)
<2> Windows+R cmd > ver
Microsoft Windows [Version 10.0.19044.2604]
<3> Windows+R cmd > wmic os get buildnumber,caption,CSDVersion /format:csv
A,19044,Microsoft Windows 10 Pro,
<4> Windows+R cmd > wmic os get Caption,CSDVersion /value

Paul was correct about "funny stuff" happening after a Windows update.
The service remained disabled.
The indexing remained excluded.
But the SystemApps "thing" came back.
Directory of C:\Windows\SystemApps
02/15/2023 06:58 AM <DIR> Microsoft.Windows.Search_cw5n1h2txyewy
01/29/2023 04:56 AM <DIR> Microsoft.Windows.Search_cw5n1h2txyewy.old

BTW, what is this "thing" anyway? Is it an executable?

--
Cheers, Rob

On 15 Feb 2023 at 7:23:25 AM, RJH <patchmoney@gmx.com> wrote:
> BTW, what is this "thing" anyway? Is it an executable?

Apparently it's a "directory" of some sort.
But the more important report is that I spoke too soon.
The Valentines Day Windows Update undid some of the clever subterfuge.

I hadn't expected a hundred "SearchApp.exe" threads in the task manager.
But there they are. https://i.postimg.cc/4drfH6ts/clipboard01.jpg

Why are there a hundred searchapp.exe threads doing anything at all?
If the search is properly disabled, why would they be running?

Let me move it so that at least it won't activate all those threads.

Windows+R cmd {control+shift+enter}
cd %Windir%\SystemApps

C:\Windows\SystemApps> move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.bck
The process cannot access the file because it is being used by another process.
0 dir(s) moved.

C:\Windows\SystemApps> taskkill /f /im SearchApp.exe
SUCCESS: The process "SearchApp.exe" with PID 2384 has been terminated.

C:\Windows\SystemApps> move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.bck
1 dir(s) moved.

The move seems to have killed the hundred SearchApp.exe threads (how?).
https://i.postimg.cc/y8K3QZdL/clipboard02.jpg

All that was left are the following threads (processes?).
procexp64.exe 1096 Key HKLM\SYSTEM\ControlSet001\Services\WSearchIdxPi\Performance
procexp64.exe 1096 Mutant \Sessions\1\BaseNamedObjects\WSearchIdxPi_Perf_Library_Lock_PID_448
explorer.exe 4292 DLL C:\Windows\System32\Windows.Storage.Search.dll
explorer.exe 4292 Key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search
explorer.exe 4292 Key HKLM\SOFTWARE\Microsoft\Internet Explorer\SearchScopes\{0633EE93-D776-472f-A0FF-E1416B8B2E3A}
explorer.exe 4292 Key HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\SearchRoots
explorer.exe 4292 Key HKLM\SOFTWARE\Microsoft\Internet Explorer\SearchScopes

The main conundrum is why there were a hundred SearchApp.exe threads?
It seems the only way to stop them, so far anyway, is the original move.
--
Cheers, Rob

On Wed, 15 Feb 2023 07:23:25 +0000, RJH <patchmoney@gmx.com> wrote:

>On 14 Feb 2023 at 8:27:04 PM, Andy Burns <usenet@andyburns.uk> wrote:
>> <3> click Modify, then expand the folder tree and untick every folder
>> that you don't want indexed (possibly all of them)
>> <4> click advanced and then click rebuild
>
>Got it. Thanks. This is a perfect example of how this newsgroup works for us!
>This is useful for the archives too, so that it's useful for everyone later.
>For that, I'll summarize the solution that remained after a Windows Update.
>
>Recommended solution. (survives Windows Update)
> <1> Windows+R services.msc
> <2> Windows Search > General > Stop
> <3> Windows Search > General > Startup type > Disabled
>
>Alternative solution. (survives Windows Update)
> <1> Windows+R control.exe
> <2> All control panel items > View by > Small icons
> <3> Indexing Options > Modify > then expand the folder tree
> <4> Untick every folder that you don't want indexed (possibly all of them)
> <5> Advanced > Rebuild
>
>Deprecated solution. (does not survive Windows Update)
> <1> Windows+R cmd {control+shift+enter}
> <2> cd %Windir%\SystemApps
> <3> copy (but do not yet paste!) this into your clipboard
> move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.old
> <4> taskkill /f /im SearchApp.exe
> <5> Immediately paste your clipboard contents into the window!
>
>>> I've never found Windows search to be of any use at all. Have you?
>>
>> No, because I've used different search tools that don't chang with every
>> version of windows.
>
>Between you and me, I can't imagine that anyone finds Windows Search useful.

I use Windows search only occasionally, when I want to find and run a
program I don't have a shortcut for, but remember the name of. For
everything else I use everything.exe.

>All it does, for me, is annoy me by wasting cpu cycles doing its indexing.
>
>To Paul's concern, I happened to get a Windows Update yesterday.
><1> Windows+R winver (Version 21H2 (OS Build 19044.2604)
><2> Windows+R cmd > ver
> Microsoft Windows [Version 10.0.19044.2604]
><3> Windows+R cmd > wmic os get buildnumber,caption,CSDVersion /format:csv
> A,19044,Microsoft Windows 10 Pro,
><4> Windows+R cmd > wmic os get Caption,CSDVersion /value
>
>Paul was correct about "funny stuff" happening after a Windows update.
>The service remained disabled.
>The indexing remained excluded.
>But the SystemApps "thing" came back.
> Directory of C:\Windows\SystemApps
> 02/15/2023 06:58 AM <DIR> Microsoft.Windows.Search_cw5n1h2txyewy
> 01/29/2023 04:56 AM <DIR> Microsoft.Windows.Search_cw5n1h2txyewy.old
>
>BTW, what is this "thing" anyway? Is it an executable?

On 2/15/2023 3:30 AM, RJH wrote:
> On 15 Feb 2023 at 7:23:25 AM, RJH <patchmoney@gmx.com> wrote:
>> BTW, what is this "thing" anyway? Is it an executable?
>
> Apparently it's a "directory" of some sort.
> But the more important report is that I spoke too soon.
> The Valentines Day Windows Update undid some of the clever subterfuge.
>
> I hadn't expected a hundred "SearchApp.exe" threads in the task manager.
> But there they are. https://i.postimg.cc/4drfH6ts/clipboard01.jpg
>
> Why are there a hundred searchapp.exe threads doing anything at all?
> If the search is properly disabled, why would they be running?
>
> Let me move it so that at least it won't activate all those threads.
>
> Windows+R cmd {control+shift+enter}
> cd %Windir%\SystemApps
>
> C:\Windows\SystemApps> move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.bck
> The process cannot access the file because it is being used by another process.
> 0 dir(s) moved.
>
> C:\Windows\SystemApps> taskkill /f /im SearchApp.exe
> SUCCESS: The process "SearchApp.exe" with PID 2384 has been terminated.
>
> C:\Windows\SystemApps> move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.bck
> 1 dir(s) moved.
>
> The move seems to have killed the hundred SearchApp.exe threads (how?).
> https://i.postimg.cc/y8K3QZdL/clipboard02.jpg
>
> All that was left are the following threads (processes?).
> procexp64.exe 1096 Key HKLM\SYSTEM\ControlSet001\Services\WSearchIdxPi\Performance
> procexp64.exe 1096 Mutant \Sessions\1\BaseNamedObjects\WSearchIdxPi_Perf_Library_Lock_PID_448
> explorer.exe 4292 DLL C:\Windows\System32\Windows.Storage.Search.dll
> explorer.exe 4292 Key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search
> explorer.exe 4292 Key HKLM\SOFTWARE\Microsoft\Internet Explorer\SearchScopes\{0633EE93-D776-472f-A0FF-E1416B8B2E3A}
> explorer.exe 4292 Key HKLM\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\SearchRoots
> explorer.exe 4292 Key HKLM\SOFTWARE\Microsoft\Internet Explorer\SearchScopes
>
> The main conundrum is why there were a hundred SearchApp.exe threads?
> It seems the only way to stop them, so far anyway, is the original move.
>

Every search box on the machine, likely hooks into the search
system, so there would be a thread for each one.

As for the package folder coming back, it's hard to say for sure
what happened. It could be that search got patched on Patch Tuesday.
Or, the OS decided that the "inventory did not match the goods"
and did some DISM work to fix the package structure.

Windows has a mix of stuff that is protected by signing, and
stuff that is not protected by signing. If you download an App
from the Microsoft App Store, the integrity of those packages are
checked. The manifest file contains info about the package.

But whether the entire WinSxS is protected that way, I couldn't say.
The WinSxS undoubtedly gets scanned enough times during the day,
for that kind of checking to be done. The state of it might be
checked any time a Windows Update run is scheduled.

But so far, I have not been able to detect a completely autonomous
repair scheme. It was my biggest fear, they would design one, and
if they had, there would be "unintended consequences", such as
every Windows computer in the world not able to boot or function
on a certain Wednesday. It's like when your AV (with good intentions)
has a false positive, and quarantines critical OS resources. It's all
fun and games, until it won't boot.

Paul

On 15 Feb 2023 at 4:21:51 PM, Paul <nospam@needed.invalid> wrote:

> Every search box on the machine, likely hooks into the search
> system, so there would be a thread for each one.

Thanks for that assumption because I didn't even look at first because
I thought I had killed it. After moving the search folder, they're gone now.

> As for the package folder coming back, it's hard to say for sure
> what happened. It could be that search got patched on Patch Tuesday.
> Or, the OS decided that the "inventory did not match the goods"
> and did some DISM work to fix the package structure.

If the search was patched, would the date for everyone be the new date?
C:\Windows\SystemApps> dir *Search*
02/15/2023 06:58 AM <DIR> Microsoft.Windows.Search_cw5n1h2txyewy.bck
01/29/2023 04:56 AM <DIR> Microsoft.Windows.Search_cw5n1h2txyewy.old

> Windows has a mix of stuff that is protected by signing, and
> stuff that is not protected by signing. If you download an App
> from the Microsoft App Store, the integrity of those packages are
> checked. The manifest file contains info about the package.

Luckily, I never download any apps from the Microsoft Store.
I certainly don't have a MS account although I know many don't need it.

> But whether the entire WinSxS is protected that way, I couldn't say.
> The WinSxS undoubtedly gets scanned enough times during the day,
> for that kind of checking to be done. The state of it might be
> checked any time a Windows Update run is scheduled.

I remember some kind of "dism" fix for when something gets corrupted.
I don't remember exactly how to run it but if I remember, I'll try it.

If it comes back from that chkdsk/dism sequence, then you're right!
> But so far, I have not been able to detect a completely autonomous
> repair scheme. It was my biggest fear, they would design one, and
> if they had, there would be "unintended consequences", such as
> every Windows computer in the world not able to boot or function
> on a certain Wednesday. It's like when your AV (with good intentions)
> has a false positive, and quarantines critical OS resources. It's all
> fun and games, until it won't boot.

I'm looking to see what's using up CPU resources where SearchApp.exe
was near the top so now I'm digging deeper. I don't know what to do
with the many svchost.exe processes (I've never understood them.)

To me any one of them can be a rogue app since they're all the same name.
https://i.postimg.cc/13W5G7sV/clipboard03.jpg

What do you do to figure out what any one svchost is doing on your PC?
--
Cheers, Rob

On 2023-02-15 08:47:06 +0000, Ken Blake said:

>>Between you and me, I can't imagine that anyone finds Windows Search useful.
>
> I use Windows search only occasionally, when I want to find and run a
> program I don't have a shortcut for, but remember the name of. For
> everything else I use everything.exe.

It's not a surprise at all that you would find something as useless as the
Search feature useful since you only do what others tell you what to do.

You're stupid.

You can't help anyone. You never can. You never could. You never will.

You only prove you're stupid every single time you post to this newsgroup.

On 2/15/2023 11:56 AM, RJH wrote:
> On 15 Feb 2023 at 4:21:51 PM, Paul <nospam@needed.invalid> wrote:
>
>> Every search box on the machine, likely hooks into the search
>> system, so there would be a thread for each one.
>
> Thanks for that assumption because I didn't even look at first because
> I thought I had killed it. After moving the search folder, they're gone now.
>
>> As for the package folder coming back, it's hard to say for sure
>> what happened. It could be that search got patched on Patch Tuesday.
>> Or, the OS decided that the "inventory did not match the goods"
>> and did some DISM work to fix the package structure.
>
> If the search was patched, would the date for everyone be the new date?
> C:\Windows\SystemApps> dir *Search*
> 02/15/2023 06:58 AM <DIR> Microsoft.Windows.Search_cw5n1h2txyewy.bck
> 01/29/2023 04:56 AM <DIR> Microsoft.Windows.Search_cw5n1h2txyewy.old
>
>> Windows has a mix of stuff that is protected by signing, and
>> stuff that is not protected by signing. If you download an App
>> from the Microsoft App Store, the integrity of those packages are
>> checked. The manifest file contains info about the package.
>
> Luckily, I never download any apps from the Microsoft Store.
> I certainly don't have a MS account although I know many don't need it.
>
>> But whether the entire WinSxS is protected that way, I couldn't say.
>> The WinSxS undoubtedly gets scanned enough times during the day,
>> for that kind of checking to be done. The state of it might be
>> checked any time a Windows Update run is scheduled.
>
> I remember some kind of "dism" fix for when something gets corrupted.
> I don't remember exactly how to run it but if I remember, I'll try it.
>
> If it comes back from that chkdsk/dism sequence, then you're right!
>
>> But so far, I have not been able to detect a completely autonomous
>> repair scheme. It was my biggest fear, they would design one, and
>> if they had, there would be "unintended consequences", such as
>> every Windows computer in the world not able to boot or function
>> on a certain Wednesday. It's like when your AV (with good intentions)
>> has a false positive, and quarantines critical OS resources. It's all
>> fun and games, until it won't boot.
>
> I'm looking to see what's using up CPU resources where SearchApp.exe
> was near the top so now I'm digging deeper. I don't know what to do
> with the many svchost.exe processes (I've never understood them.)
>
> To me any one of them can be a rogue app since they're all the same name.
> https://i.postimg.cc/13W5G7sV/clipboard03.jpg
>
> What do you do to figure out what any one svchost is doing on your PC?
>

Hmmm.

On my Windows 11, I try:

tasklist /svc

and I can't find wuauserv now.

More messing around I would guess.

***********************************

Win10 Pro (current)

Image Name PID Services
========================= ======== ============================================
svchost.exe 788 BrokerInfrastructure, DcomLaunch, PlugPlay,
Power, SystemEventsBroker
svchost.exe 904 RpcEptMapper, RpcSs
svchost.exe 964 LSM
svchost.exe 456 gpsvc
svchost.exe 732 lmhosts
svchost.exe 960 CoreMessagingRegistrar
svchost.exe 1064 NcbService
svchost.exe 1072 TimeBrokerSvc
svchost.exe 1080 Schedule
svchost.exe 1192 ProfSvc
svchost.exe 1240 DispBrokerDesktopSvc
svchost.exe 1260 EventLog
svchost.exe 1316 UserManager
svchost.exe 1380 nsi
svchost.exe 1416 Dhcp
svchost.exe 1500 WPDBusEnum
svchost.exe 1564 NlaSvc
svchost.exe 1664 netprofm
svchost.exe 1672 EventSystem
svchost.exe 1680 SysMain
svchost.exe 1700 Themes
svchost.exe 1772 SEMgrSvc
svchost.exe 1816 SENS
svchost.exe 1848 AudioEndpointBuilder
svchost.exe 1868 FontCache
svchost.exe 2000 Audiosrv
svchost.exe 2032 WinHttpAutoProxySvc
svchost.exe 1948 StateRepository
svchost.exe 2040 Dnscache
svchost.exe 2092 DusmSvc
svchost.exe 2100 Wcmsvc
svchost.exe 2196 ShellHWDetection
svchost.exe 2240 DoSvc
svchost.exe 2256 BFE, mpssvc
svchost.exe 2296 wuauserv <=== Windows Update
spoolsv.exe 2396 Spooler
svchost.exe 2508 LanmanWorkstation
svchost.exe 2616 Winmgmt
svchost.exe 2644 iphlpsvc
svchost.exe 2728 CryptSvc
svchost.exe 2748 DiagTrack
svchost.exe 2772 DPS
svchost.exe 2868 LanmanServer
svchost.exe 2928 TrkWks
svchost.exe 2964 WpnService
svchost.exe 3060 WdiServiceHost
svchost.exe 3488 StorSvc
svchost.exe 3752 AppXSvc
svchost.exe 3792 ClipSVC
svchost.exe 4044 RmSvc
svchost.exe 3536 LicenseManager
svchost.exe 4296 wlidsvc
svchost.exe 4620 TokenBroker
svchost.exe 4936 CDPUserSvc_55ea7
svchost.exe 4988 WpnUserService_55ea7
svchost.exe 3988 TabletInputService
svchost.exe 1860 CDPSvc
svchost.exe 5232 camsvc
svchost.exe 5332 WdiSystemHost
svchost.exe 5524 swprv
svchost.exe 5564 cbdhsvc_55ea7
svchost.exe 6008 UsoSvc
svchost.exe 7152 WaaSMedicSvc
svchost.exe 4056 InstallService <=== TrustedInstaller, MSIEXEC ???
svchost.exe 7508 NgcSvc
svchost.exe 7600 Appinfo
svchost.exe 7924 BITS
svchost.exe 8032 SSDPSRV
svchost.exe 856 wisvc
svchost.exe 6908 lfsvc

Win11 Home (Current) stuff is missing!

Image Name PID Services
========================= ======== ============================================
svchost.exe 1232 BrokerInfrastructure, DcomLaunch, PlugPlay,
Power, SystemEventsBroker
svchost.exe 1380 RpcEptMapper, RpcSs
svchost.exe 1432 LSM
svchost.exe 1640 HvHost
svchost.exe 1700 Schedule
svchost.exe 1740 ProfSvc
svchost.exe 1748 NcbService
svchost.exe 1832 UserManager
svchost.exe 1852 TimeBrokerSvc
svchost.exe 1860 CoreMessagingRegistrar
svchost.exe 1868 lmhosts
svchost.exe 1908 nsi
svchost.exe 2000 netprofm
svchost.exe 2180 Dnscache
svchost.exe 2240 EventLog
svchost.exe 2436 Dhcp
svchost.exe 2456 hns
svchost.exe 2544 Themes
svchost.exe 2548 SysMain
svchost.exe 2560 EventSystem
svchost.exe 2628 StateRepository
svchost.exe 2712 WinHttpAutoProxySvc
svchost.exe 2824 DispBrokerDesktopSvc
svchost.exe 2852 SENS
svchost.exe 2964 AudioEndpointBuilder
svchost.exe 2972 FontCache
svchost.exe 3040 NcdAutoSetup
svchost.exe 2216 Winmgmt
svchost.exe 3012 FDResPub
svchost.exe 3664 Audiosrv
svchost.exe 3708 TextInputManagementService
svchost.exe 4064 Wcmsvc
svchost.exe 4072 DusmSvc
svchost.exe 3968 nvagent
svchost.exe 4124 BFE, mpssvc
svchost.exe 4172 SharedAccess
svchost.exe 4368 WlanSvc
svchost.exe 4400 ShellHWDetection
svchost.exe 4660 DeviceAssociationService
svchost.exe 4816 SSDPSRV
svchost.exe 4852 LanmanWorkstation
svchost.exe 5060 DiagTrack
svchost.exe 5068 CryptSvc
svchost.exe 5104 TrkWks
svchost.exe 3316 WpnService
svchost.exe 3476 iphlpsvc
svchost.exe 3288 DPS
svchost.exe 5952 LanmanServer
svchost.exe 6124 Browser
svchost.exe 6308 RmSvc
svchost.exe 6408 NgcSvc
svchost.exe 6452 NgcCtnrSvc
svchost.exe 6912 webthreatdefsvc
svchost.exe 7076 CDPUserSvc_7bf3d
svchost.exe 7104 webthreatdefusersvc_7bf3d
svchost.exe 7128 TokenBroker
svchost.exe 4412 WpnUserService_7bf3d
svchost.exe 5268 CDPSvc
svchost.exe 5440 camsvc
svchost.exe 5504 WdiSystemHost
svchost.exe 7488 cbdhsvc_7bf3d
svchost.exe 7568 Appinfo
svchost.exe 5468 LicenseManager
svchost.exe 8272 UdkUserSvc_7bf3d
svchost.exe 11116 W32Time
svchost.exe 10468 NPSMSvc_7bf3d
svchost.exe 10508 BthAvctpSvc
svchost.exe 5568 lfsvc
svchost.exe 1292 AarSvc_7bf3d
svchost.exe 7892 wcncsvc
svchost.exe 8728 StorSvc
svchost.exe 8012 DoSvc
svchost.exe 9220 PcaSvc
svchost.exe 3832 UsoSvc
svchost.exe 5596 wscsvc
svchost.exe 10548 OneSyncSvc_7bf3d
svchost.exe 5748 DisplayEnhancementService

On 2/15/2023 12:23 PM, gtr wrote:
> On 2023-02-15 08:47:06 +0000, Ken Blake said:
>
>>> Between you and me, I can't imagine that anyone finds Windows Search useful.
>>
>> I use Windows search only  occasionally, when I want to find and run a
>> program I don't have a shortcut for, but remember the name of. For
>> everything else I use everything.exe.
>
> It's not a surprise at all that you would find something as useless as the
> Search feature useful since you only do what others tell you what to do.
>
> You're stupid.
>
> You can't help anyone. You never can. You never could. You never will.
> You only prove you're stupid every single time you post to this newsgroup.

The Search service works.

But you have to set it up.

It's not the epitome of stability. It starts
re-indexing when not commanded to do so. Search
is then degraded until it finishes. It can take
24 hours of computing, to finish a re-index.

Microsoft admits it does not scale above 1 million files.
The test I've carried out on it, was with 1 million files
(on the other computer).

It works sometimes, but depending on what you ask it,
it can take three to five minutes to answer.

Only searches done on a single folder finish with moderate speed.

On Windows 11, the old Windows.edb (JetBlue) has been changed
to Windows.db (Sqlite). But this does not mean that the design
intent (federated search) has changed.

The search uses a search language. Free form English expressions
are the very last thing you should feed it.

mytaxfile <=== don't do this

filename:mytaxfile <=== do this instead

ext:xlsx <=== if you knew the file type

size:huge <=== some keywords present a graphical menu while you type

One of your first chores, is finding the web page with the *current*
search language. This was a problem, even back in Windows XP days!
How can you use a product, if there's no Help ?

Third party searches can be simpler, mainly focused on filenames,
and for many people, this is the most frequent kind of search.

If Windows Search takes 3 seconds one time and 5 minutes the next,
who needs that exactly ??? It all depends what mood it is in,
as to what happens. It is not "Apple Magical". If Jobs were here,
he would kick the ass of the individual who wrote WS.

You can do a Windows Search from a script. Someone posted a chunk of
script code to call Windows Search from powershell. And this avoids
the wasted time when File Explorer tries to draw the results. Part
of the wasted time, is wasted by File Explorer. In 3 minutes,
it can find 50,000 items.

But this is all novelty stuff, when you want to get something done.

If I go back to my Mac G4, I used to whine that it was "slow" on
search. However, compared to Windows Search, it's a cheetah. It
has consistent search times (search 20 partitions in about 20 seconds),
and short of using Everything.exe , you're not going to beat it for
speed. Part of this is likely due to the file table scheme used.
There were likely on the order of a million files on that setup too.

I've done the work. And I'm not impressed. But at least some times,
it settles down. Occasionally, on the more modern Windows, the
search service does not even start in a timely manner, and it
is "not running" when you go to use it. How cool is that ???

Paul

On 15 Feb 2023 at 11:31:24 AM, Paul <nospam@needed.invalid> wrote:

> tasklist /svc

That's a nice command which shows 69 'svchost.exe' related entries.
I like that it tells me /why/ each of those svchost PIDs exist, by name.
Thank you for that keeper of a useful debugging command.

tasklist /svc | findstr svchost.exe
svchost.exe 852 BrokerInfrastructure, DcomLaunch, PlugPlay,
svchost.exe 1040 RpcEptMapper, RpcSs
svchost.exe 1060 netprofm
svchost.exe 1096 LSM
svchost.exe 1312 CoreMessagingRegistrar
svchost.exe 1320 lmhosts
svchost.exe 1376 Schedule
svchost.exe 1400 NcbService
svchost.exe 1416 TimeBrokerSvc
svchost.exe 1424 ProfSvc
svchost.exe 1556 UserManager
svchost.exe 1580 EventLog
svchost.exe 1588 hidserv
svchost.exe 1668 DispBrokerDesktopSvc
svchost.exe 1720 nsi
svchost.exe 1856 Dhcp
svchost.exe 1976 NlaSvc
svchost.exe 2060 Winmgmt
svchost.exe 2180 fdPHost
svchost.exe 2192 IKEEXT
svchost.exe 2296 EventSystem
svchost.exe 2376 hns
svchost.exe 2388 Dnscache
svchost.exe 2400 WpnUserService_2283db
svchost.exe 2508 nvagent
svchost.exe 2568 SENS
svchost.exe 2596 SysMain
svchost.exe 2608 DevicesFlowUserSvc_2283db
svchost.exe 2620 Themes
svchost.exe 2728 AudioEndpointBuilder
svchost.exe 2736 FontCache
svchost.exe 2920 BFE, mpssvc
svchost.exe 3012 SharedAccess
svchost.exe 3052 CDPUserSvc_2283db
svchost.exe 3172 LanmanWorkstation
svchost.exe 3256 Audiosrv
svchost.exe 3300 DeviceAssociationService
svchost.exe 3388 TabletInputService
svchost.exe 3408 StateRepository
svchost.exe 3496 DusmSvc
svchost.exe 3504 Wcmsvc
svchost.exe 3616 MSiSCSI
svchost.exe 3708 ShellHWDetection
svchost.exe 3852 RmSvc
svchost.exe 3888 CDPSvc
svchost.exe 4084 WebClient
svchost.exe 4148 SstpSvc
svchost.exe 4240 WpnService
svchost.exe 4296 TapiSrv
svchost.exe 4432 LanmanServer
svchost.exe 4684 SSDPSRV
svchost.exe 4700 Netman
svchost.exe 4724 RasMan
svchost.exe 4872 TokenBroker
svchost.exe 4996 NcdAutoSetup
svchost.exe 5164 PcaSvc
svchost.exe 5464 cbdhsvc_2283db
svchost.exe 5612 FDResPub
svchost.exe 5664 StorSvc
svchost.exe 5688 UsoSvc
svchost.exe 5808 wscsvc
svchost.exe 5864 BthAvctpSvc
svchost.exe 5948 CryptSvc
svchost.exe 6124 Appinfo
svchost.exe 6424 OneSyncSvc_2283db
svchost.exe 6860 wuauserv
svchost.exe 6888 seclogon
svchost.exe 7148 WinHttpAutoProxySvc
svchost.exe 7908 DevicePickerUserSvc_2283db

> and I can't find wuauserv now.
tasklist /svc | findstr wuauserv
svchost.exe 6860 wuauserv

Am I supposed to kill whatever that is doing?
wuauserv?https://www.google.com/search?q=what+is+wuauserv.exe

https://www.minitool.com/lib/wuauserv.html
"Wuauserv is the Windows Update Service, which is responsible for
automatically downloading and installing software created by Microsoft"

In services.msc my "Windows Update" is set to manual.
What is your recommendation?

The biggest "hog" now in my system is "MSMpEng.exe" but I can't kill that
because it's the antivirus I think. I couldn't even lower the Affinity
because it wouldn't let me change the number of CPUs that it runs on.
--
Cheers, Rob

On 2023-02-15 19:56:20 +0000, Paul said:

> The Search service works.
>
> But you have to set it up.

I used to use the Search Service when I was naive.
But it kept bringing up Bing, which I would never use.
Worse, it brought up Edge even though I would never use that either.

So I removed the search box from the taskbar.
Search still worked as you know if you just started typing something.

> It's not the epitome of stability. It starts
> re-indexing when not commanded to do so. Search
> is then degraded until it finishes. It can take
> 24 hours of computing, to finish a re-index.

Is that re-index file large?
Probably not.

I'm not against the search cpu cycles.
But that the search is for morons.

> Microsoft admits it does not scale above 1 million files.
> The test I've carried out on it, was with 1 million files
> (on the other computer).
>
> It works sometimes, but depending on what you ask it,
> it can take three to five minutes to answer.

Wow.
I generally got rubbish from the search results.
Nothing I couldn't get from googling though it never took five minutes.

> One of your first chores, is finding the web page with the *current*
> search language. This was a problem, even back in Windows XP days!
> How can you use a product, if there's no Help?

I didn't even know there was a search language.
Thanks.

> Third party searches can be simpler, mainly focused on filenames,
> and for many people, this is the most frequent kind of search.

Isn't there a company out there that specializes in searches?
I think it's called Google. Nobody can beat them. Can they?

> If Windows Search takes 3 seconds one time and 5 minutes the next,
> who needs that exactly ??? It all depends what mood it is in,
> as to what happens. It is not "Apple Magical". If Jobs were here,
> he would kick the ass of the individual who wrote WS.

The only thing I can't google for is a file on my system.
But I can do a dir that lists every file (dir has a lot of options).
dir /b/on/a/l/s > files.txt
Of course one problem is that dir /b/on/a/l/s takes a few minutes.

> You can do a Windows Search from a script. Someone posted a chunk of
> script code to call Windows Search from powershell. And this avoids
> the wasted time when File Explorer tries to draw the results. Part
> of the wasted time, is wasted by File Explorer. In 3 minutes,
> it can find 50,000 items.
>
> But this is all novelty stuff, when you want to get something done.

Someday I'll learn how to write a script that does it once a month.
dir /b/on/a/l/s > files_on_{date}.txt
Then I can grep that file for whatever filename or regexp I want to.

> If I go back to my Mac G4, I used to whine that it was "slow" on
> search. However, compared to Windows Search, it's a cheetah. It
> has consistent search times (search 20 partitions in about 20 seconds),
> and short of using Everything.exe , you're not going to beat it for
> speed. Part of this is likely due to the file table scheme used.
> There were likely on the order of a million files on that setup too.

Two things I do negate the need to use the Windows search.

The first is I use Google and the second is I can run that dir /b/on/a/l/s.
dir /b/on/a/l/s > my_files_on_20230215.txt

The third is I learn how to use the command line to run commands.
> I've done the work. And I'm not impressed. But at least some times,
> it settles down. Occasionally, on the more modern Windows, the
> search service does not even start in a timely manner, and it
> is "not running" when you go to use it. How cool is that ???

What might be nice is a monthly scheduled file listing of the format
dir /b/on/a/l/s > all_my_files_on_{date}.txt

On Mon, 13 Feb 2023 21:47:25 -0500, in alt.comp.os.windows-10, Paul
wrote:

>On 2/13/2023 8:23 PM, RJH wrote:
>> On 13 Feb 2023 at 9:59:16 AM, Stan Brown <the_stan_brown@fastmail.fm>
>> wrote:
>>
>>> If you really want to turn off search indexing, why not just go to
>>> Services.msc, select Windows Search, stop it, and then set it to
>>> Disabled?
>>
>> Why not? Well. Sir. I'll tell you why not.
>> You asked bloody why not, right?
>> Ahem! You sir! You challenged me sir!
>>
>> (I'm stalling. I'm trying to think of a witty reply while I'm stalling.)
>>
>> Sheesh. The real answer is that I didn't know how to do that.
>> Not until you just said so. That's why.
>>
>> I just did it.
>> <1> Windows+R services.msc
>> <2> Windows Search > General > Stop
>> <3> Windows Search > General > Startup type > Disabled
>>
>> Thanks! :->
>>
>
>Check after a reboot and see if that control has
>been altered on you.
>
>There is a certain level of aggression around
>search. This is why I was expecting trouble,
>because it has a history of being aggressive
>(infinite services restarts instead of three service restarts).
>
>Because there's a Bing module in that folder (SearchApp folder),
>it could be tied into recording the things you do on
>the computer, which is why the subsystem should be
>aggressive.
>
>And it could be, that SearchApp keeps tabs on Search Service,
>and maybe it is the thing that restarts the service. Since
>you killed the SearchApp.exe first, maybe that will change
>the outcome of the experiment (of disabling the service). Microsoft
>uses a tag-team approach, like a malware would, for things
>it wants to have running on the machine. They will use a
>"second" software, to make sure the "first" software is
>running and has not croaked. Scheduled Tasks can be wired up
>for this stuff, too.
>

For sure CTFMON.exe will not shut up. It respawns instantly. I think it's
part of Office 365.

Also the "Text Input Management Service" service. You know, the part that
reads your input and tries to "help" you with it.

You can no longer disable that service (or even stop it) in an elevated
prompt.

I haven't tried doing so with the built-in Administrator account, but I
suspect that would work, as it can do things that "TrustedInstaller" and
"SYSTEM" are allowed.

To wit: MS is getting very aggressive about maintaining certain services,
and an admin account does not have the same permissions as the built-in
Administrator account.

I just sighed and gave up. I'm tired of whack-a-mole.

--
Zag

No one ever said on their deathbed, 'Gee, I wish I had
spent more time alone with my computer.' ~Dan(i) Bunten

On 2/15/2023 2:57 PM, RJH wrote:
> On 15 Feb 2023 at 11:31:24 AM, Paul <nospam@needed.invalid> wrote:
>
>> tasklist /svc
>
>
>> and I can't find wuauserv now.
> tasklist /svc | findstr wuauserv
> svchost.exe 6860 wuauserv
>
> Am I supposed to kill whatever that is doing?
> wuauserv?https://www.google.com/search?q=what+is+wuauserv.exe
>
> https://www.minitool.com/lib/wuauserv.html
> "Wuauserv is the Windows Update Service, which is responsible for
> automatically downloading and installing software created by Microsoft"
>
> In services.msc my "Windows Update" is set to manual.
> What is your recommendation?
>
> The biggest "hog" now in my system is "MSMpEng.exe" but I can't kill that
> because it's the antivirus I think. I couldn't even lower the Affinity
> because it wouldn't let me change the number of CPUs that it runs on.

Well, the reason I was looking for wuauserv, is because that
is an "orientation feature of the landscape". The wuauserv is
supposed to be inside the "big" SVCHost. I expect to see it in
that group of services.

Yet it appears for some reason, it is not running on my Windows 11.

Services do not have to use any cycles. A lot of those services
cost you nothing but a bit of RAM.

There is no particular reason to kill it, especially if the USO
service is controlling the wuauserv for us. USO is a scheme
that might be used on Enterprise, but they decided to test
it on the consumer SKUs too. USO causes three command prompt
windows to appear and rapidly disappear, right after the desktop
appears.

*******

MSMpEng.exe can be controlled from the... well, mine is playing
dead right now.

Windows Security : Virus & threat protection : Virus & threat protection settings : manage settings

Move Real-time protection slider to Off.

You will see a UAC prompt, click OK.

DO NOT close the Windows Security panel. If you do,
MsMpEng.exe will be put back into scanning mode again.
You leave that window open, and just stack other windows
on top or around it.

Note that, even when the slider is in the OFF position,
the process can be scanning. Depending on the mood it is
in, it might start scanning again after ten minutes. This is
one of the curses of nadless software controls. It turns
the computer into a Fisher Price busy box, where you spin
knobs and nothing happens.

The purpose of switching off the Real-Time protection,
is to aid the performance of read-only apps. For example,
if I use hashdeep64 and attempt to generate checksums
for a file tree, with MsMpEng running, the ability to
read files is reduced to 12% of normal. Pretty slow.
I turn off the Real-Time scan, while hashdeep calculates
the checksums. Then, turn it back on when finished.

You leave real-time scanning enabled, when you are
double-clicking EXE files and the like. Any activity with
a perceived (Safe-Hex) danger or attack surface, you want
the real-time scan running.

If the scanning did not degrade performance, I wouldn't
be doing this.

Paul

On Wed, 15 Feb 2023 07:23:25 +0000, RJH <patchmoney@gmx.com> wrote:

>On 14 Feb 2023 at 8:27:04 PM, Andy Burns <usenet@andyburns.uk> wrote:
>> <3> click Modify, then expand the folder tree and untick every folder
>> that you don't want indexed (possibly all of them)
>> <4> click advanced and then click rebuild
>
>Got it. Thanks. This is a perfect example of how this newsgroup works for us!
>This is useful for the archives too, so that it's useful for everyone later.
>For that, I'll summarize the solution that remained after a Windows Update.
>
>Recommended solution. (survives Windows Update)
> <1> Windows+R services.msc
> <2> Windows Search > General > Stop
> <3> Windows Search > General > Startup type > Disabled

Thank you!

On 2/13/23 20:31, this is what RJH wrote:
> It was that simple in Windows too!
> <1> Open an admin window
> <2> cd %windir%\SystemApps
> <3> copy (but do not yet paste!) this into your clipboard
> move Microsoft.Windows.Search_cw5n1h2txyewy Microsoft.Windows.Search_cw5n1h2txyewy.old
> <4> taskkill /f /im SearchApp.exe
> <5> Immediately paste your clipboard contents into the window!
>
> It took a few tries before I realized I had to be fast.
> But then it gave up without a fight.
You could have put that in a batch .BAT file and there would no worry about timing.
Al