After upgrading to 6.3.0.17, sporadic access violation using Quick Search

[cnewtonne]

Since this upgrade, I have been getting this AV error daily. Never seen it before the upgrade.

It is sporadic, but when it does happen, is results from these steps ...

1. Invoke quick search.
2. Type search string
3. Hit ENTER
4. Get the AV error.

It does not happen all the time using these steps. UR does not crash and once I dismiss the error, I'm able to continue using UR without having to restart it.

Ultra Recall Professional 6.3 (x64)
Copyright © 2004-2024 Kinook Software, Inc.
Registered to: **** (1-user license)
Windows version: Windows 10 Enterprise
Install path: C:\Program Files\UltraRecall
HRW15.DLL version 15.0.0.1
HRW19.DLL version 19.0.0.2
HTW21.DLL version 21,0,0,0
HTW25.DLL version 25,0,0,3
msptls.dll version 15.0.4420.1017
msvcr100.dll version 10.00.40219.325
PolarSpellChecker.dll version 4.0.5.6
riched20.dll version 15.0.4420.1017
SftPrintPreview_x64_U_20.dll version 2.07
SSGPW.DLL version 1.0.2.1
SSLW.DLL version 1.5.0.3
TEW26.DLL version 26.0.0.7
TEW30.DLL version 30.0.0.6
UltraRecall.exe version 6.3.0.17
unins000.exe version 51.52.0.0
Database filename: ***\***.urd
Database version: 6.3.2 [FTS]

[kinook]

I will analyze the recent changes. In the mean time, if you can identify steps to reproduce it could help.

[cnewtonne]

Thanks.
I included the steps in my original post above. I do not know if the search string has something to do with the error. I'll pay attention to it next time.

[kinook]

Right, but I tried that and haven't experienced the problem. It could be a combination of your settings or other differences.

https://www.kinook.com/Forum/showthread.php?t=3038

[kinook]

I put the previous version for download at

https://kinook.com/Download/Old/UltraRecallProX64Eval_6.3.0.16.exe

in case it avoids the issue, and if so, it would also narrow down which changes could have caused it. I checked all recent changes and nothing stands out as introducing the problem.

[cnewtonne]

On a second machine, I started experiencing same AV errors and UR crashes/aborts using Quick Search (QS) form. I tried 7 times using same steps, UR either displayed AV error or aborted in 5 of them. I was not able to reproduce in the remaining 2 attempts. It is not 100% reproducible.


1) Call QS form using keyboard shortcut.
2) Duplicate QS form using CTRL+T to open 4 new QS tabs.
3) Perform ~ 4 QS's using text string in most recent QS tab (QST4).
4) Switch back to QST1 tab (oldest).
5) In QST1, type search string, hit ENTER, Backspace to delete it. type same text, hit ENTER. Repeat few times.
6) On at least 2 occasions, simply doing CTRL+T to duplicate QS tab, produced AV error.
7) At some point, searching in QST1 should either produce AV error of crash/abort UR.
8) If you get AV dialogue. dismiss it. You should be able to continue searching. UR appears to be working fine.


Ultra Recall Professional 6.3 (x64)
Copyright © 2004-2024 Kinook Software, Inc.
Registered to: ***(1-user license)
Windows version: Windows 11 Home
Install path: C:\Program Files\UltraRecall
HRW15.DLL version 15.0.0.1
HRW19.DLL version 19.0.0.2
HTW21.DLL version 21,0,0,0
HTW25.DLL version 25,0,0,3
msptls.dll version 15.0.4420.1017
msvcr100.dll version 10.00.40219.325
PolarSpellChecker.dll version 4.0.5.6
riched20.dll version 15.0.4420.1017
SftPrintPreview_x64_U_20.dll version 2.07
SSGPW.DLL version 1.0.2.1
SSLW.DLL version 1.5.0.3
TEW26.DLL version 26.0.0.7
TEW30.DLL version 30.0.0.6
UltraRecall.exe version 6.3.0.17
unins000.exe version 51.52.0.0
Database filename: X:\****.urd
Database version: 6.3.2 [FTS]

[kinook]

No luck so far.

Could you try uninstalling and going back to 6.3.0.16 (see earlier link), to help identify if it was introduced in the latest version?

Are you able to reproduce in one of the sample DBs?

Can you provide the info from

https://www.kinook.com/Forum/showthread.php?t=3038

since it may be specific to your settings?

Thanks.

[cnewtonne]

The issue appears to be related to a race condition between opening/closing QS tabs and what happens when a new QS tab is created i.e. executing a search.

All crashes occur when a new QS is created using CTRL+T.

I was able to reproduce it using this procedure as well.

- Verify search option 'automatically start saved search when search item selected' is ON. When OFF, creating a new QS tab (with search string entered) will not populate the related items or search pane.
- Make sure child items / search results pane is displayed. I have mine placed bottom of data explorer pane.

1. Call QS tab using keyboard.
2. Type search string, hit ENTER. Requires relatively large URD DB to slow search a bit.
3. Duplicate tab many times using CTRL+T (do not release the T key): Create 20 more. Every new tab will execute the search and populate the related items/search pane.
4. Close them all using CTRL+SHIFT+W.
5. Repeat steps above till you get a crash or an AV error.

I think disabling search option 'automatically start saved search when search item selected' helps. I was not able to reproduce crash when this option off. I'll confirm again.

I was not able to reproduce it in newly created empty DB's. The crash procedure requires relatively large data to slow search down when new QS is created/closed.

I will try using older 6.3.0.16 tomorrow.

[cnewtonne]

Using the latest procedure to crash UR (in my latest post), I was able to reproduce the crash in versions 6.3.0.17 & 6.3.0.16. However, version 6.3.0.12 did not crash.

I think I narrowed it down to the change in default QS. In version .17 or .16, default QS has a new AND row in the RELATIONS column. Version .12, does not.

In version .16/.17, If I delete the AND row, UR does not crash when I duplicate a QS tab using CTRL+T. This duplicate tab without a search string in the QS edit box.

For some reason, this new AND changed something about QS where duplicating a QS tab crashes UR.

Is there away to undo this change to match what he had in version .12?

Thanks

[kinook]

Previously, the first row of the advanced search grid would have blank in the Relationship field, but it was an implied AND (with the quick search value). Now, it can be either OR or AND. I don't think the drop-down being populated is the cause of the error, and this change was implemented in 6.3.0.17 so it must not be the cause if the issue exists in 6.3.0.16. Can you reproduce this in a new or one of the sample DBs? And can you send your registry options? I still haven't been able to reproduce, even in a 1GB db and a search that takes a couple seconds.

In the latest download (6.3.0.18), I added some null checks that could potentially address the problem you're seeing.

[cnewtonne]

Thank you.
Downloading the latest release still shows 'UltraRecall.exe version 6.3.0.17'. I see same behavior. UR aborts when duplicating a QS tab with search edit box contains a search string.

I have not tested with a sample urd db. I did test three different database. UR crashes on all three. I'll try to test with a sample db.

You are also correct in that version .16 does not have the AND column but continues to crash.

One consistent pattern I see is that crash occurs only when duplicating QS tab when the search edit box contains a search string. If I remove the string, UR does not crash.

[kinook]

Try clearing your browser cache and re-downloading, then uninstalling and installing. It will show 6.3.0.18 in Help | About if you have the latest version.

[cnewtonne]

I was able to produce a crash/abort using .18 release.

I went back & examined the release history changes as documented by Kinook. Starting from the 'fact' that release .12 did not crash while .17 and .18 did.

For the enhancement section, releases jump from .12 to .17. An enhancement which is supporting AND/OR in QS. We ruled this out as the cause of the crash because .16 didn't have it, but it crashed.

For the 'bug fixes' section, there is no .12 release listed, but, a bug fix in .13 which seems unrelated (combining text). There is search related bug fix and behavior change introduced in .15 regarding SearchNonAsciiTextNonCaseSensitive.

With this is key set to zero, I was NOT able to crash .18 or. 17. Deleting the key, I was able to crash both releases. I mean duplicating QS a 100 times, did not crash it. Just similar to what I experienced in release .12. I never was able to do 100 QS tabs without a crash.

I'll be using UR for the next few days. I was getting crashes daily last week. I'll confirm again.

[kinook]

Thank you, that helped narrow things down. I was finally able to identify the issue and it's fixed in v6.3.0.19.

[cnewtonne]

Wow!
So rewarding to see the word 'fixed'. Testing with .19, I ran the same test of generating near 100 QS tabs with and without string string, no crash. Looks good.

I'll confirm as I continue to use UR for the upcoming days.

Of course, it is not typical of my workload to generate this many QS tabs all at once. But, in the course of a day, I probably do.

Thank you.

[cnewtonne]

It has been three days now without any crash or AV errors. I used to get them daily last week.
Looks like the issue is now resolved in release *.19.

Thanks for the great support.