DO 12 has worked perfectly for me since 2016. Recently however, when searching for text within documents in a subfolder, the search keeps running and does not finish. The STOP button is unresponsive and the program must be closed in order to conduct another search for text. This behavior continues in the DO 13 beta. I have not changed any configuration in the program, so I don't think this is due to anything I've done. Windows 11 is up to date. Any help is appreciated.
What type of documents? Sounds more likely to be a bug in an IFilter for one of the document types (which would be part of other software, or sometimes Windows) than somethIng in Opus itself.
Thank you for the quick response, Leo. The only documents in the folder are WordPerfect (.wpd) documents. There are no attachments or embedded graphics. I just now tried a search in a folder with only .pdf files with the same result. FWIW, as a test, I installed the trial version of PowerGREP and it is finding specific text within the .wpd files with no problem. I really like DO, so I hope we can find the cause of the problem.
Opus doesn't know how to search WPD or PDF documents by itself, so an IFilter is almost certainly involved in both cases, although it would normally be a different one for each type.
If you make some process snapshots after a search has been hung for a few minutes, we may be able to use those to see which component is holding things up. That should tell us if it's an IFilter (and which one if it is), or something else.
Thank you for the detailed instructions. A zip file of the 5 crash dumps has been emailed via hightail.
Many thanks for the DMPs.
It looks like it is a stuck IFilter:
C:\Program Files (x86)\Nuance\PaperPort\PDFProFilterPP64.dll
That is being called to search inside a PDF file, and it either never returns or is taking a very long time to return:
May be worth reporting to Nuance, who should be able to use the same DMP files on their side.
In case extra info helps them track it down, it appears to be getting stuck in the
IFilter::Init call here:
HRESULT hr = LoadIFilter(pFSPath.GetString(), 0, pFilter.assign_ptr_void_reset());
// start reading via the filter
DWORD dwFlags = 0;
if (FAILED(pFilter->Init( IFILTER_INIT_INDEXING_ONLY
| IFILTER_INIT_FILTER_OWNED_VALUE_OK, 0, 0, &dwFlags)))
It's stuck in four different threads at once, while searching inside four different PDF files, so it doesn't look specific to the file being searched.
THANK YOU, Leo! I recently purchased a new Brother printer which installed PaperPort 14. I uninstalled Paper Port 14 and now DO is working normally! I don't need Paper Port / Omni Page since I have Adobe Acrobat Pro. Thanks again for your help.