Cancel does not always stop the Search within a reasonable time.

[mdell-seradex]

It seems that after a reboot, or after not using dnGrep for an extended period of time, the Cancel button is unable to stop the search in a reasonable amount of time.
Note that after the search completes, a second run can be cancelled quickly.

This is something that I have experienced periodically, but have unable to determine a realtionship to anything before.
As this may be hard to identify, please do not hesitate to use me to run code or other tools.
I have multiple versions of Visual Studio installed.

[mdell-seradex]

All 3 plugins are enabled. I didn't include the other options because they didn't seem relevant.
If you need any more info, please don't hesitate to ask.

[doug24]

In the worst case, how long does it take to cancel the operation? 10 seconds? 1 minute? Longer?

This will be difficult to debug without a reproduceable case. The cancel command sets a flag that is checked at many places in the search code to break out of loops, drop out the search operation and let the worker threads end. When the cancel takes a long time, I suspect the code is making a system call or some long running operation in between checks of the cancel flag.

What I would try is to run the application with debug build in the VS debugger, start a search, cancel it, wait some time to see the cancel is not completing, then do a "Break All" is the VS debugger. Check all the call stack on all the threads (there will be several) to see what thread is still doing some part of the search (you will need to open both the Threads and Call Stack windows in the debugger).

[mdell-seradex]

It seems like the search completes, which seems to take about a minute or more. I didn't exactly time it, but definitely noticed a significant difference between the two.

I can try what you said if you wish.

[doug24]

Added more checks in release v3.0.136. Reply if you see anything else with a way I can reproduce it.