%LOCALAPPDATA%RingCentralSoftPhone
Good morning,
I'm experiencing the same exact issue on a single computer in our environment.
I've checked and all permissions to the necessary locations are proper. Running as Admin does indeed work, as a temporary solution - but still have been unable to pinpoint an exact cause.
Any other updates on this?
Thanks!
We've given full permission to that location, the issue still occurs unless it's ran as admin, so this doesn't seem to be the fix.
Good to know, however we have tried both granting the user full control over both this and the Program Files (x86)Ring Central folder, as well as deleting the orphaned files in both paths before reinstall, and the issue seemed to recur. Would you happen to know which file is the actual database file it is using? Thanks in advance!
Is there an update anyone has on this issue, as if it is a MS security patch which caused this, then it will be impacting more PCs as they reboot. We have a ticket open but no real response to this issue from RC Support. If we could get info on the patch we could potentially prevent it from marching forward to not have all of the call agents down.
1. Does somebody have some specific permissions on using OpenSSL library under non-admin user?
2. Does somebody try to remove appstorage.db and restart RC Phone App?
Experiencing the same issue, of course Ring Central Tech Support is saying they know nothing of this error and aren't sure how to fix this. I know that both the Ring Central desktop app, and Phone app have recently both been updated late November, of course this is when we started having issues with it.
Things we've tried that have not worked:
- Allowing app through the defender fire wall
- Uninstalling both RC and RC Phone apps and reinstalling
- Giving owner permissions to the local folder
Things we've tried but haven't really tested:
-Clearing out the %temp% folder of the user after reinstall >this may be the solution, but need to figure out the order of operations ie uninstall, reinstall, delete temp or which order it needs to go in order for it to work.
Things that DOES work
- running it as admin, which is not a possibility as our users only get user permissions in our Azure AD environment.
Maybe that helps point you in the right direction...but I've only been able to replicate the temp folder situation only once, but I think the answer may lay within that parameter.
I have also been getting this on a couple of computers. I have found that deleting the UsersUsernameAppDataLocalRingCentral directory and re-installing RCPhone fixes it for a day or so, but then it happens again.
@Gregory Yaschuk I just fixed this issue this morning on a computer by just deleting the appstorage.db file from the same place. We had to re login but not reinstall RCPhone, so that's already a bit better.
I don't think we have any OpenSSL stuff going on, it's not effecting all our members of staff just a couple at the moment. I suspect that this one I fixed today will break again in a day or two, I guess we will find out.
This computer was running version 21.2.1.42167. I didn't think there is much point updating as @Frank Hinz has the same issue with 22.4
Tom, I just tried it myself, and it does indeed fix the issue, and the user will have to log back in, but it's better than it just sitting there and not being able to be used. We'll keep an eye on this and see how long it fixes it, and at least talk to RingCentral about this and try to get them to patch up this error.
I found 22.3 is somewhat stable, I don't think we have had any users in our environment have issues on it.
Deleting just the appstorage.db in the SoftPhone directory seems to do the trick if you're looking for the temp fix, but it will just come back.
Hi
We ran into this issue as well. We were forced to uninstall the ring central phone app and delete the appstorage.db and reinstall the phone.
This has been stable.
File location
C:UsersyouruserAppDataLocalRingCentralSoftPhone appstorage.db
We were also experiencing this issue, none of supports suggestions help or the above suggestions.
Our 2 affected users have š & â in their local profile path. We have raised this with support as something must have change in an app upgrade as these accounts were previously working
