`SearchIndexer.exe` crashes when EP is used as shell extension

gjera commented 2 years ago

Hi

Ever since I installed ExplorerPatcher, I had problem on execution of SearchIndexer from Windows itself. SearchIndexer just wouldn't run anymore.
Error info that I got from Event Viewer was:
--------------------
Faulting application name: SearchIndexer.exe, version: 7.0.22000.282, time stamp: 0x5759ba2c
Faulting module name: ExplorerPatcher.amd64.dll, version: 22000.318.38.2, time stamp: 0x6196993e
Exception code: 0xc0000005
Fault offset: 0x000000000000912d
Faulting process ID: 0x1814
Faulting application start time: 0x01d7dcc526e103be
Faulting application path: C:\Windows\system32\SearchIndexer.exe
Faulting module path: C:\Program Files\ExplorerPatcher\ExplorerPatcher.amd64.dll
Report ID: f8101667-2b64-4890-b30a-cd902464a7b3
Faulting package full name: 
Faulting package-relative application ID: 
------------------------

If this was problem of just one specific option in ExplorerPatcher or general problem, I wouldn't know.

Br, Gregor

BraINstinct0 commented 2 years ago

Check if it goes away when ExplorerPatcher is uninstalled. If it doesn't, then it's not EP's bug.
Check if it goes away when EP is installed and settings are set to default. Find which setting(s) cause this.
If it happens with EP @ default settings, I think we can call that a bug.

valinet commented 2 years ago

I have just clean installed a copy of Windows 11 build 22000.318 in a VM downloaded straight from Microsoft.

Executing "searchindexer.exe" from Start - Search yields nothing.
Executing "searchindexer.exe" from Run yiels nothing.
Installing ExplorerPatcher and running "searchindexer.exe" yields nothing.
Registering ExplorerPatcher as shell extension (which it looks you have done on your computer) and running "searchindexer.exe" yields nothing.
I then attached with a debugger both with EP registered as shell extension and not registered and run "searchindexer.exe" under it. After the initial breakpoint, NtTerminateProcess is immediatly called and the following messaged is logged in the debugging console:
```
onecoreuap\base\appmodel\search\common\dcomsvc\dcomsvc.cxx(422)\searchindexer.exe!00007FF7C4850F55: (caller: 00007FF7C482FC22) LogHr(1) tid(2190) 80070427 The service process could not connect to the service controller.
```

So, it seems to be a general thing with Windows. I cannot manage to start it with or without EP installed. I don't know what that thing does, but it seems deprecated to me, or Microsoft did some change that made it non-functional. I don't know why the log points it to EP's DLL, it can only do so when you register it as shell extension. if it works without registering EP as shell extension, then I still don't know what to do, since I have told you, I tried running this thing on a clean install and it does not want to start with stock settings.

Thanks

gjera commented 2 years ago

1. Check if it goes away when ExplorerPatcher is uninstalled. If it doesn't, then it's not EP's bug.

2. Check if it goes away when EP is installed and settings are set to default. Find which setting(s) cause this.

3. If it happens with EP @ default settings, I think we can call that a bug.

I tried to reinstall it and went back to default settings. This seemed to cure the problem. Question now is which EP setting caused this problem.

valinet commented 2 years ago

Reinstalling EP does not reset any settings of itself. I told you, what may be causing this: using as shell extension. That injects all applications, is the only way EP may get loaded in something other than explorer.exe, StartMenuExperienceHost.exe and ShellExperienceHost.exe. As I said, I cannot reproduce.

gjera commented 2 years ago

I mentioned that i specifically went back to "default settings" with option in EP itself. I don't understand how I would use it as shell extension. All I did was that I used integrated EP functionalities.

valinet commented 2 years ago

This:

Have you used that or not?

gjera commented 2 years ago

no. here i used only "disable the windows 11 context menu"

gjera commented 2 years ago

i tried to replicate my settings, but couldn't replicate also the problem. so i guess we can close it, but uninstallation of EP fixed my "windows search indexing" immediately. i tried all sorts of different remedies. from deletinging the windows search caches, to resetting of his configuration files and nothing helped, except uninstallation of EP.

valinet commented 2 years ago

Yeah, idk, weird… it cannot crash without it being injected there, and for it to inject in some random app, that’s the only mechanism currently. Anyway, I am glad that you sorted it out eventually.

BraINstinct0 commented 2 years ago

At least we now know the empirical"if all doesn't work start clean" is valid here, too

VarunAgw commented 2 years ago

Same issue. Register as shell extension feature is causing the crash for me.

BraINstinct0 commented 2 years ago

yeah, for now that feature is really of experimental stage but it'd be worth noting.

akorsus commented 2 years ago

Here same: Deactivating Register as shell extension solved Search indexing crashes

valinet commented 2 years ago

Yeah, well, the shell extension is a very specific use case, not recommended to generally use. Idk why it crashes that and idk how to solve it as I said it, I cannot reproduce it in the first place, idk what to reproduce really, I cannot launch that executable, no one seems to be interested in providing that info and idk how much time I have to spend on it anyway. I personally hate this feature, injecting all/most of the apps on the system is a bad idea, generally, it takes a lot to get right and it also makes using this app more cumbersome, especially updating it is a pain the butt. I thought I fixed it, to inject properly in general, yet it seems not so, I could add a check to disable injecting SearchIndexer.exe specifically but yeah, that’s a local fix, ideally one would investigate why it crashes it and fix it generally, if possible.

I could also add a mention near this option that it is not recommended to use. Removing the option from the UI is what I would do, but ofc some people would then jump screaming how the function is removed altogether in the last version because hardly anyone bothers ever reading the release notes and some people prefer entering panic mode instantly, and then when they realize the thing’s still there, but hidden from the UI, they’ll yet again complain how it is useless now because they can’t toggle it a million times a day just for the sake of it and because merging a registry file is now very hard when you have a GUI like EP’s that makes it so trivial to apply some registry entries.

This functionality is less tested or largely hardly tested at all, with most testing coming from users that complain when something breaks, as I don’t daily drive it, basically. And it’s mostly useless, it was mainly developed to fix the context menu in Open/Save file dialogs when themes are disabled, which is a configuration used by a couple of users.

So yeah, idk what I could really do…

valinet commented 2 years ago

@adylyn Thanks for confirming my statements in the original post very well. Wouldn't it have been better if I did not bother to release this tool in the first place anyway. I could use it for myself and it spared me being cussed at by random strangers online who have nothing to do during the day than behave like dicks. Btw, non-registered users can search past issues just fine, no need to justify your behavior.

And if you stand by your opinion, write it so it's clear from the get go, i.e. in English. Everyone has Google Translate or at least took a basic class in German, enough to understand the insignificance of your reply. I stand by my original post, dumping a bunch of screenshots in whatever language is not helpful at all. I know, it only takes you 10 seconds to do so, so why would I invest more than 10 to help with that too...? Same as not looking up for past threads, I know it's just easier not to give a single fuck.

This community is becoming more and more toxic by the day. I am seriously considering closing the forums here.

VarunAgw commented 2 years ago

@valinet I am sorry about this comment. Some people are just assholes. Ignore them.

We appreciate your work. Even if you abandon the project completely today, we will appreciate your work. But we really hope you ignore the words of some random prick and move on.

You are just volunteering here. Work on whatever you want. You have no obligations. I don't expect you to spend spare time on this issue or this project if you rather wish to do something else.

VarunAgw commented 2 years ago

I also just reported his profile to the Github on this URL

https://support.github.com/contact/report-abuse?category=report-abuse&report=adylyn&report_id=95639665&report_type=user

valinet commented 2 years ago

@VarunAgw Yeah, I don’t mind, that’s why I also haven’t deleted it. I don’t like censorship. As in, “I disapprove of what you say, but I will defend to the death your right to say it”. It’s his/her choice to behave like this, if it finds it appropriate, that’s their opinion. I am just disappointed sometimes but what I see from some people over here. Some, not all. The same way I am also amazed at other times.

And regarding this, I am slowly looking into it, ofc I want and should I fix it, I will push the change right away, I don’t like bugs or annoyances either.

Thank you 🙏

VarunAgw commented 2 years ago

@valinet Thanks. Good to hear that.

Personally, I reported the issue just for the sake of it. I don't use the "Register as shell function" anyway so I am not affected at all. Earlier I enabled it out of curiosity, now I just disabled it.

valinet commented 2 years ago

Yeah, well, it’s not that required. Injecting all apps is also kind of tricky. As for usefulness, it represents mostly fixes for the classic theme users. It also makes updates harder, since you have to reboot because the old version is still loaded in most apps. It takes a while to get it right. It’s weird enough that it seems to happen only with this app. I wonder why, and I am trying to find out. Ofc, if it’s just with this, the easy fix is to blacklist it specifically. But I am still curious for the actual reason. But nevertheless, it should be fixed at some point. It’s the nature of this software, it will never be perfect, there will always be some issues and it takes a while to iron out some of them, that’s it. Not that others with billions of dollars and thousands of developers do a much better job, if we’re at it.

akorsus commented 2 years ago

@valinet I am also sorry for the inappropriate comment. I think it's just a troll and 99% of the users are really thankful.

Regarding a good solution: IMHO clear warning in the settings section would do it. I enabled the option out of curiosity and the feeling the experience could be more "complete" if enabled. A hint that this option could be harmful would do it. Other option is to move the option to the 'Advanced' Section and mark it with the asterisk meaning to change it only after reading documentation.

akorsus commented 2 years ago

Regarding the problem itself: SearchIndexer.exe is the windows search / indexing service and is usually started on windows startup. You can start it manually via the Services MMC. Starting SearchIndexer.exe like an app doesn't do anything as you already noted. If it crashes, no search in Outlook or the Explorer command bar will success.

When crashing, there is an event with ID 7034 in "System" from "Service Control Manager", saying "The Service 'Windows Search' terminated unexpectedly" in the Windows Event Viewer.

There is also an Event with ID 1000 in the "Application" section of the event viewer, stating

Name der fehlerhaften Anwendung: SearchIndexer.exe, Version: 7.0.22000.348, Zeitstempel: 0x46d1468c
Name des fehlerhaften Moduls: ExplorerPatcher.amd64.dll, Version: 22000.348.39.1, Zeitstempel: 0x619e2dea
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00000000000091fd
ID des fehlerhaften Prozesses: 0x61c8
Startzeit der fehlerhaften Anwendung: 0x01d7e82d769c50f7
Pfad der fehlerhaften Anwendung: C:\WINDOWS\system32\SearchIndexer.exe
Pfad des fehlerhaften Moduls: C:\Program Files\ExplorerPatcher\ExplorerPatcher.amd64.dll
Berichtskennung: e5210249-1572-4fa7-943a-1adb47b78b99
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

(Sorry that this is in German, hope it helps anyway) Hope that helps investigating the problem

valinet commented 2 years ago

Yeah, thank you, I will think about it. I will try to address this somehow as well. It’s not harmful, it can be problematic, as I said, there may be cases I miss, I can only do so much and limited testing myself. Even currently there is a link there to this: https://github.com/valinet/ExplorerPatcher/wiki/Using-ExplorerPatcher-as-shell-extension which outlines very clearly how that option works. It’s a tool for advanced users anyway, I’d say, I don’t want to impose 5 pop-ups before letting you enable it, it’s also kind of implied users read the documentation or generally have a sense of what they’ve doing and what could go wrong. For example, it’s obvious this problem can happen only when using that option, as otherwise EP is not injected in random processes, so at most it can affect them indirectly.

So yeah, maybe I will indeed move it or decorate it with some warning, but also, I’d want to fix this in either the correct way, or the pragmatic way, but fix it.

The event log clearly says the faulting module is ExplorerPatcher, and it seems to say the error code is ERROR_ACCESS_DENIED??? That’s interesting. I will try to simulate this in a VM, enable full user mode dumps and collect a crash dump. That would be much more useful, as maybe I can see exactly what check returns error 5 and determine a thing to workaround it and that should fix it.

valinet commented 2 years ago

Btw, it’s interesting the comment has disappeared. I personally haven’t deleted it, clicking on that user handle returns a 404 page, so it seems his/her account was apparently shut down.

valinet commented 2 years ago

Yeah, so, I cannot reproduce this at all, neither on my PC, nor in a virtual machine (I set the language to German to reduce the number of differences, yet no dice). I attempted to mitigate this in the latest builds by doing nothing when loaded in SearchIndexer.exe. Maybe this fixes this issue at least, otherwise, the fix still remains not using this where it causes problems, or someone that experiences this to thoughtfully investigate it. As well, maybe someone can check to see if this helps in any way, as I cannot really test it, as I said.

LoranKloeze commented 2 years ago

First of all: @valinet, very nice tool! Keep up the good work and don't let the a-holes take over... 😊

FWIW I experience the same crashes. Disabling Register as shell extension 'solves' it for now.

Some info from the event viewer. I hope it helps in solving the problem. Microsoft Windows [Version 10.0.22000.376]

<?xml version="1.0" encoding="UTF-8"?>
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
   <System>
      <Provider Name="Application Error" />
      <EventID Qualifiers="0">1000</EventID>
      <Version>0</Version>
      <Level>2</Level>
      <Task>100</Task>
      <Opcode>0</Opcode>
      <Keywords>0x80000000000000</Keywords>
      <TimeCreated SystemTime="2021-12-24T12:03:32.3861256Z" />
      <EventRecordID>178998</EventRecordID>
      <Correlation />
      <Execution ProcessID="19792" ThreadID="0" />
      <Channel>Application</Channel>
      <Computer>MYCOMPUTER</Computer>
      <Security />
   </System>
   <EventData>
      <Data>SearchIndexer.exe</Data>
      <Data>7.0.22000.348</Data>
      <Data>46d1468c</Data>
      <Data>ExplorerPatcher.amd64.dll</Data>
      <Data>22000.348.39.1</Data>
      <Data>619e2dea</Data>
      <Data>c0000005</Data>
      <Data>00000000000091fd</Data>
      <Data>6174</Data>
      <Data>01d7f8be45548139</Data>
      <Data>C:\WINDOWS\system32\SearchIndexer.exe</Data>
      <Data>C:\Program Files\ExplorerPatcher\ExplorerPatcher.amd64.dll</Data>
      <Data>0d94804c-b22c-4c18-adea-b4ade5adfe48</Data>
      <Data />
      <Data />
   </EventData>
</Event>

valinet commented 2 years ago

It should be fixed with the latest pre-release, where SearchIndexer is excluded. Try that please. I was waiting here for some feedback after my message, but in 2 weeks apparently no one had time to check it out. I’d be curious if it works or not, if not to fix it somehow and close this eventually. It would be nice if this working fix ships in the next release, which I want to do soon, by the end of the year. Thanks.

LoranKloeze commented 2 years ago

I've installed https://github.com/valinet/ExplorerPatcher/releases/tag/22000.376.40.18_866ea59 and it looks like it solves this issue. SearchIndexer.exe stays alive even when I enable 'Register as shell extension' 😊

valinet commented 2 years ago

@LoranKloeze Thanks for the feedback. Hopefully this is fixed now. It will ship with the next stable release as well, soon.

valinet / ExplorerPatcher

`SearchIndexer.exe` crashes when EP is used as shell extension #416