We're working on a debug build that should provide us with more information when these type of errors occur. We'll contact you offline when it's available.

OK, this problem is completely reproducable for me. One tab is open, so this is not tab related.

1. Have "Combined text for multiple selection" enabled.
2. Select a decent number of items (in my case I selected 10 - 15)
3. Now quickly delete those items. If the Item Detail pane is still refreshing, you will get a Microsoft window announcing their sorrow that UR has to be closed.

There is no denying that UR is SLOW. It is slow while importing, it is slow during synchs, it is slow (as reported in another thread) capturing web pages, it is slow opening large numbers of child items in the Explorer window. I have tried to improve the speed and stability on a number of different computers and have implemented Kinook's registry tweaks. Some combinations are incrementally better, but not functionally better (for me). By that I mean that there may be some performance improvement, but only when compared with UR. When compared to other programs, well forget it.

I think that the users in this thread have identified some failures as being caused by acting too quickly before UR completes its task. So what? Speed and accuracy are essential to computing. Why should users adapt to the limitations of the program?

I like UR very much and the potential it has is wonderful. I would characterize myself as a UR realist, not a UR loyalist. Performance issues need to be radically improved because usability suffers. Now there is some evidence that performance issues can also effect program stability.

Jon

I've only had one access violation while using the debug build. I think this is perhaps because:

a) the debug build has a fix for whatever was causing the access violations; or

b) I'm now not saving tab positions when I close UR; or

c) the debug build runs noticeably slower than the normal UR.

how can I get a copy of this trace-enabled build?

Instructions were sent to your forum account email address last week. If you didn't receive it, send a request to support@kinook.com.

The trace build you linked me to does not allow more than 1000 items. This makes it unuseable for me. Can you advise.

Does this build run significantly slower? I have gripes about UR's performance already and do not look forward to futher performance degredation. Still, if it helps identify these problems...

Jon

Download it again. It was updated to fix that issue. Speed should be comparable to the regular build.

Thanks

I started this thread sometime ago and out of frustration I thought I would just stay away from UltraRecall for a while because I was rather busy and could not bear to think I would lose data (worse - not knowing what I'm losing).

Anyway, I think I have the privilege of also closing this thread with respect to AV permanently with the release of V3.2.4 referred mention in another thread below. I have restarted using UltraRecall and hope to stay on but it has not been easy for two reasons which I won't elaborate here but in another thread.

---------------
"Important fix for stability problems

Today, we were finally able to reproduce the instability issues that have been reported by some users, and the latest download (version 3.2.4) includes a fix for the problem.

It should resolve most, if not all, access violation, out of memory, pure virtual function call, library routine called out of sequence, runtime errors, crashes, and/or UR closing without displaying an error.

If you continue to encounter any of these problems after installing v3.2.4, please let us know. Thanks."
http://www.kinook.com/Forum/showthre...&threadid=3046