If the directory in which you perform a search has many files selected by the file filter, then basic find in files may crash with Access violation code 0xC0000005. N++ attempts to save whatever it can, proposes to dump a crash file, and then Windows (XP SP3) issues 3 problem reports. Recursing into subfolders obviously makes crashes more likely. Try to find text in <Program Files> with recusion and filter=*.* to reproduce.
Making the file filter more selective usually solves this.
Perhaps N++ should warn user and cancel whenthe temporary memory allocation overwhelms the available resources.
Using 5.4RC unicode, not sure about 5.3.1
I think I know what the problem is, and I already fixed it. There was a bug when finding results in binary files where the Null character (0x00) appears in the middle of the line (before the \n character) where the result is found.
Thell Fowler - is it possible you're using the ANSI version of NPP?
Anyway, I'll need to speak with Don and see if I can commit the fix (but I think he is on his vacation now).
No; it was unicode. No matter now, though, that you have a fix.
I just tried a search for 'log' in <Program Files> with filter of *.* and after 20 minutes cancelled it with 56290 hits in 3251 files.
I have only 1,024Mo RAM here. If you have more, that could explain.
I'm pretty sure I've fixed it. It'll be included in the next release.