Thanks!
I can't reproduce any crash so far.
If you run SearchFilterView, do you see anything in addition to these standard ones? That could be the cause of the crash (if it only happens when searching contents).
Also, what is it that puts the green checkmarks over lots of folders in your video? It's even over the Favorites branch in the folder tree, which seems unusual for a sync or version control tool.
That could be involved in the crash, if it's happening when icons are requested, just as the results are displayed.
If turning on Preferences / Folders / Folder Display / Show generic icons for... and setting it to ...All Folders prevents the crash, then it's most likely due to that.
There are a few extra items in there.
With regards to this - setting that setting has prevented the crash in dual mode, but I tried it in single pane mode and it crashed again
I think those overlays are from a program called Syncplicity that syncs to the cloud. I find it interesting though that this cause the issue - the folders with those icons were in the LEFT pane that was not being searched on. I specifically put the "test folders" in a directory that doesn't get sync'd with Syncplicity.
I still crashed - dual pane was fine, SINGLE PANE crashed this time!
Syncplicity is overly greedy - my company forces everything in fav's and documents to be sync'd if I want it or not.
The shell extension is probably set up so that it has to be asked for every file and folder. If it doesn't add an icon to something, that doesn't mean it wasn't still asked if it wanted to.
You could try disabling its Icon Overlay Handler using ShellExView (64-bit version) to test the theory that it is involved.
I closed Syncplicity and then I did as you instructed and I disabled the Icon Overlay Handlers for Syncplicity. Its crashing every time. I think the initial success was a false alarm.
Should I somehow deeply uninstall Dopus and reinstall?
I just rested with File Explorer and XYplorer again and they are fine.
If you want to try uninstalling and reinstalling, backup your config first (Settings > Backup & Restore), but do some tests after reinstalling using the default config in case whatever is happening is related to something that has been customised.
I would also try disabling any other shell extensions on the machine to see if they are involved.
Also try disabling all Search Filters that are outside of the Windows folder. (In fact, if the problem only happens when searching contents, and not when doing a basic *.ini search, then it's almost certainly going to be one of the filters. But if it also happens when not searching contents, then it won't be a filter.)
Thanks for paying attention to this issue. I will do this testing tomorrow (I'm in Japan, time to open a can of beer or 2, tomorrow is a holiday).
I will report tomorrow. Thank you. I have never messed with Search Filters - I will read up on these and then see about removing some of them.
I CAN CONFIRM - only searching contents crashes. If I remove that parameter and just search *.ini its fine.
1 Like
Definitely try the filters in that case.
Note that XYplorer is a 32-bit application so it wont use the same IFilter components as Opus and File Explorer. And File Explorer is what everyone tests their components against, so there are sometimes bugs that are hidden in it but not in other things. In Explorer, indexing may also mean the IFilter has only been called once and now a cached result is being used, and if the indexing ever crashes it's typically hidden from you.
How do I disable a search filter? The utility you pointed me to gives me details for each Search Filter but doesn't allow me to disable them.
From some more investigation, if an IFilter is involved, the crash is probably triggered in part by these two files:
Yard_World_Clock\Clock_0\Clock.ini
Yard_World_Clock\Clock_2\Clock.ini
If you move those files out of the search area, do you still see a crash?
The other *.ini files are all either ASCII or Unicode with a BOM, which means we would not ask an IFilter to search them (we do the plain text search ourselves), but those two files are UTF-16 without a BOM, which looks like binary data and is delegated to IFilters. Our guess is that one of the IFilters on your system is even more confused by UTF-16 without a BOM and is (often) crashing when asked to search the file.
In SearchFilterView, select each filter in the top part of the window and see if it's assigned to .ini in the bottom part. Most only have a couple of extensions, so you can quickly move through the list with the cursor keys.
In my case, one of the query.dll "Plain Text Filters" which are part of Windows is assigned to .ini files:
Note that you may find more than one thing is assigned the extension.
If you then select the extension in the bottom part of the list, you can remove it via the menu at the top:
(You can put it back again after testing via the same menu.)
Thanks. I only have ONE Search Filter that contains .ini which seems to match with yours.
I removed the entry - same crash.
By the way - I installed a 64 bit filemanager called FMAN and it also does not crash on my machine when I run a search for *.ini and the text Roundline in the files.
I have reset Dopus to its defaults. For some reason only Dopus is crashing and the .ini extension is tied to the same Search Filter as yours. But, you cannot duplicate the issue. I guess we are stuck unless there is some sort of debug I could do within Dopus in order to catch what is happening behind the scenes?
If this is only me - then its fine. I love your product and if this helps your product become better I am willing to help. If this is isolated to me, and there is nothing else to be done, that is OK. Let me know.
I don't know if FMAN uses Ifilters or not.
Did you try removing the two .ini files I mentioned to see if you still get a crash then?
Only found one entry in Search Filters for .ini. I removed it and it still crashed. I Then put it back.
Is there a specific .ini file in the group of files I sent you wish me to delete? Apologies if I missed this.
At the top of this post:
By the way, when you zipped up the folder, did you use Opus to make the zip? If not, please try that in case something is killing the process if it tries to access certain files. (Seen that once or twice with privacy tools deciding a random file has personal data and being more suspicious of some exe files than others.)
Hi Leo - thanks for sticking with this.
- I removed those two .INI files, same result
- I did use Dopus to do the zipping
As a data point - XYplorer has a setting to use 64-bit Search Filters. I set this option, ran the search several times, no crash.
Haven't had a chance today, but we'll see if we can make a special test version that logs what is happening during the find operation to see if we can work out where it's going wrong.
Generating a Process Monitor log of the crash might reveal something as well, if you want to do that: