XYplorer Beta Club

I have Thunderbird set to the Maildir storage, which stores all files as *.eml .
XY has no problems to search for text in such files.
There is an iFilter and there are no errors while searching.

Hi Donald. I'm back and ready to continue working with you on this problem.
Thanks for your help and your patience!

OK, what's your settings here:

Configuration | Other | Shell Integration | 64-bit Windows | Use 64-bit IFilters for content search
Configuration | Other | Shell Integration | 64-bit Windows | Fall back to IFilters of the other bitness

Play with them and see whether changing those settings makes a difference.

I did some experimenting to see if I could simplify the test by
restricting the search to a single directory and its subdirectories.
The goal was to reduce the number of files being examined and,
therefore, reduce the elapsed time for a given test.

My initial pass was with both "Use 64-bit IFilters for content
search" and "Fall back to IFilters of the other bitness" unchecked.
I ran the search and quickly encountered the Divide by Zero error on
several (but not all) .EML files.

Test 2:
"Use 64-bit IFilters for content search" checked and "Fall back to
IFilters of the other bitness" unchecked. The test completed with
no errors and a few of the .EML files were successfully found.

Test 3:
"Use 64-bit IFilters for content search" checked and "Fall back to
IFilters of the other bitness" checked. The test completed with no
errors and the same .EML files were successfully found.

Test 4:
"Use 64-bit IFilters for content search" unchecked and "Fall back to
IFilters of the other bitness" checked. The test failed with the
Divde by Zero error.

I ran another variant of Tests 2 and 3, with the difference being to
broaden the search across more directories. For these tests
XY64contents.exe entered a permanent Wait while processing a PDF (it
was the same PDF in both cases). I used Process Explorer to take a
peek at the status of XY64contents.exe. It had four threads, each of
which was in a "UserRequest" Wait State and the wait condition was
never satisfied, i.e., the wait was permanent.

I've never had the need to write any code which directly invoked
IFilters, so I needed to learn a little about the architecture,
implementation and usage model.

I used information I found at these Microsoft URLs to gain a bit of
an understanding of IFiletrs in general and how to determine the
relationship between file types and the corresponding IFilters: Spelunking through the Windows Registry, I believe these are the
IFilters on my system for .eml and .pdf file types, respectively:
Please let me know what I should do next to further assist in
diagnosing the problems and arrive at a solution.

Thanks!

Good! So the error is in the 32-bit process. Makes it much easier to debug.

Select one of the EML files that generate the error and run this script: text extracttext(); Does it generate the error as well?

I ran the text extracttext(); script on several of the .eml files
that had previously caused the divide by zero error, and the script
executed without error and displayed the extracted text.

Just to be clear, I ran the script with the Configuration options
"Use 64-bit IFilters for content search" and "Fall back to IFilters
of the other bitness" both unchecked.

When you get the error, is the message still "Proc: IsFileOK@129 ..." or is it some other number?

They are all Proc: IsFileOK@129

I've attached the file Test_20230517.zip which shows a sampling from a
test run today.

Bizarre. There is no division in that line, let alone a division by zero.

So it's a deeper bug that somehow damages the error reporting. Shell extensions like IFilters can do crazy things. Impossible to debug.

I've installed several versions of XYplorer, each in their own directory:
V22_90_0100
V23_90_0200
V24_40_0000

I ran the exact same search using each of these versions and I get the same
Divide by Zero failure each time. The machine where the failures occur
is a Lenovo T460P running Windows 10 Pro 64-bit, Version 21H2,
OS Build 19044.2965

I also installed the same versions of XYplorer on a different machine:
A Microsoft Surface Pro V3 running Windows 10 Pro 64-bit, Version 21H2,
OS Build 19044.2846

I ran the exact same tests and they all executed correctly; no errors reported
and they all found the appropriate files.

My guess is that there is something different enough between these two
systems that causes the failure.

Is there a way to configure XYplorer such that it does not field the Divide by
Zero exception and, therefore, we might be able to see the error where it
actually occurs? Perhaps running XYplorer with the Microsoft Visual Studio
debugger (I have this installed on the T460P system)?

I'm open to suggestions!

Thanks again for the help.

This won't help me because the relationship between the output of this debugger and my code is unclear.

If text extracttext(); does not throw the error, then it must happen during searching the return of extracttext(), and this return is probably different depending on your system. So let's look at the return. This will create a file (in the current path) with the raw extracted text of the currently selected file: By the way, does it make a difference which word you enter in the content search?