If any crash dumps were generated, please send them to us so we can investigate:
If you go back to 12.9 does the problem go away? I can't think of any changes in 12.9.1 which would start to cause that problem.
It's possible the crash is not in Opus and is a shell extension something else has installed going wrong, but we can usually use the crash dumps to see if that's the case.
If there are no crash dumps, this guide has other suggestions on tracking down the cause of this type of crash:
sorry there were no dumps or logs in the folder for which find generated crash.
but I could narrow down the trigger for this crash, if the current folder is having wsl symbolic links and the filter condition should match the symbolic links name.
Is there anything different about WSL symbolic links compared to normal ones in Windows created without WSL?
What do the Type and Target columns (both under the General category) show for those links?
Could you list the steps to re-create what you have? e.g. WSL commands used to create the links.
Are those links on your C drive, presumably normal NTFS, or is there a junction or similar involved and the folder in question is on another drive/filesystem?
And just to confirm, you've looked in %TEMP%\DOpus.Minidumps (e.g. C:\Users\<your user name>\AppData\Local\Temp\DOpus.Minidumps for the crash dumps? They'll only be found there.
Let me check the directory and upload if i have any dumps.
I used "ln -s" to create symbolic links in wsl. I am running Ubuntu 16.04 on wsl and my disk is ntfs formated. If you want i can upload the directory content as tar gzip.
If you turn off Preferences / Folders / Folder Display / Display localized folder names, do you still see the same problem?
If you no longer get the crash when that is turned off, we've found and fixed the problem. But if you still get the crash, please let us know so we know to look for something extra.
The crash doesn't look like it has any connection to WSL symbolic links. It definitely won't be related to AMD CPUs either.
We think it might be tied to folders that have localised names, and setting up the Find so it starts in the path which uses the localised name rather than the physical path.
On the machine that was seeing the crash before, please check that the crash still happens with things as they are, and then that it no longer happens when the Display localized folder names option is turned off.
invoking search pattern kerne* under a* displays all 6 files
but invoking same seach pattern under the softlink displays empty results even though 3 files matches. repeated invoking by pressing multiple enter key triggers the crash dialog. it happens even in my amd desktop
That's expected. That is not the folder's real path by the look of things (you can't use a * in a filepath in windows, although I'm not sure it is really a *, it looks like a raised dot in some places in your screenshots), so if you specify that as the Find In path, it has to be translated into the real path, which is where the crash was happening. (If the translation is not done, i.e. when the option is turned off, then it won't find anything because the path you're specifying does not really exist, at least not on the Windows side of things. Only the translated path exists.)
In that case it will all be fixed in the next update.
I'll rename the thread to match what the issue is about.
in wsl its a * , by the way search works if you are right under the folder which has * , in my case a*. but it fails only if you go to the folder that has soft links to its parent