Find Files Stop button ignored when searching PDF content

Using Tools>Find Files to search for text inside files can take a long time - as one would expect. If I choose to manually terminate such a search by clicking the "Stop" button a problem arises.

Clicking "Stop" within about 10 seconds functions normally but after a longer period I cannot stop the search because DOpus ignores the request.

Actions and symptoms...

  • Any number of clicks on the "Stop" button show that a click was registered but the search continues in an apparent endless, uninterruptible loop. The only way to then stop the search is to close DOpus - either by normal means or via Windows Task Manager.
  • I have ticked "Show percent complete in progress indicator titles" under Preferences but the progress indicator at the top of the screen shows a looping green slider - not a progress percentage - so I am unable to determine at what point the search has become uninterruptible.
  • If I click the close (x) button in the Utility Panel the entire Utility Panel screen does not accept any input at all (it appears to have crashed) but I can still make selections elsewhere on the screen.
  • There is nothing I have observed that indicates the moment at which the search cannot be interrupted.

While the solution is easily carried out it is a nuisance to have to close the software and start again.

I would greatly appreciate assistance please.

  • What kind(s) of files are being searched?

    An IFilter which other software has installed for the format may be involved, depending on the type.

  • Please make some process snapshots after clicking the Stop button. We should be able to use those to work out whether it's Opus itself or something external which isn't responding to the stop request in a timely manner.

It looks like Microsoft's PDF IFilter is getting stuck on the file.

This is apparently a well-known issue that happens if the MS PDF IFilter is what's used for PDF files, and certain types of PDF are searched. It affects all software that uses IFilters (including Windows itself, Opus, Everything, TreeSize...) Obviously Microsoft have never fixed the problem, as they don't care about software quality, users, developers, or Windows in general anymore. :slight_smile:

Installing something which replaces the MS PDF IFilter with an alternative one (e.g. from Adobe, Sumatra, PDFLib, or various other tools) is suggested in other places with threads about the same issue. For example:


It seems that installing the Adobe iFilter makes my search succeed instantly again.

(That thread also has links to a couple of alternative IFilters.)


File handlers registered in Windows are used to search for file content. That is, the application uses other programs to query the contents of a file. For example, the search in Windows Explorer uses the same technology (the problem can also be reproduced there). The problem occurs when searching certain PDF files and is triggered by the PDF file handler that is preinstalled in Windows.

As a workaround, another file handler for PDF files, for example from Adobe , can be installed.

For reference, call stack from the process snapshots which shows the Microsoft PDF IFilter is getting stuck (or taking a very long time) within its GetChunk call (which is only being asked to read a tiny amount of data, from the snapshots):

Opus will check for the Stop button between GetChunk calls, but can't stop things while waiting on the GetChunk call. GetChunk should normally not take long, but it seems Microsoft's code gets stuck on certain PDFs.

1 Like

Thanks Leo,
I will followup those links and see what I can learn.