Hi - I have a folder structure full of text files and image files. I use an app called Rainmeter that allows you to create little apps on the desktop.
When I search with the following parameters I get an almost immediate crash with Dopus. With another file manager product I get results. This is not random - Dopus fails every time.
Name matching: *.ini
Containing text: anything - the last crash was Roundline but any value here crashes.
If I remove the Containing text value the search comes back without crashing.
I have tried this with Rainmeter RUNNING and CLOSED - same effect - so I do not believe it is a file premissions issue.
How can I provide you information or logs to help determine what the issue is? I do this type of search quite often and I would rather keep using Dopus for this task instead of the other product.
Can you work out which file being searched triggers the crash and send us the file?
It's possible the problem is not in Opus but in an IFilter something else has installed, which will be used when searching text contents. The crash logs may tell us if that's the case but have you tried the same search on the same files using File Explorer to check that?
This search with the same criteria works using Windows File Explorer and XYplorer without crashing.
Directory Opus instantly crashes when I execute the search, before any results are displayed, so I am unable to tell you what file is causing the crash.
No log or crash files were created that I can see following your link.
You should be able to work out which file is involved by copying a few files at a time to a test folder and seeing which ones were added just before doing the search on that folder triggers the crash.
It should only be the *.ini files below where you're searching, assuming you've set up the search in the usual way. (Post a screenshot if you're not sure.)
AHA! OK - I tried it in single pane mode - no crash. When The search windows is the SECOND pane it crashes. I took a video and saw that the results were coming in, matching XYplorer, then a short pause, then crash. When I went to single pane mode the results came in - no crash. The pane I was searching in was on the RIGHT in vertical mode.
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.
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!
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.)
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.
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:
