1PW4 mini crash: potential incompatibility with WebRoot(browser extensions) when using vaults

horseman

I have used both 1PW and Webroot SecureAnywhereComplete(WSAC) for several years (in their various respective versions) without issue up until I recently started using 1PW Vaults.
I’m now encountering repeated crashes (apparently 1PW4 Mini/Helper) when accessing a secondary vault if WSAC extensions are enabled in Safari 7.0.3 on Mavericks 10.9.2

Environment:
MacbookPro 7,1 8GB Ram >15GB free space
OSX 10.9.2
Safari 7.0.3

1PW 4.1.2 ,4.2.2 now 4.3Beta12 RC
1PWMini 4.1 now 4.2beta15
Originally using single vault now using 3 (Primary + 2 secondary). These are synched to drop box with 3 individual agilekeychains. Currently the primary vault has 1772 entries and these were effectively initially duplicated (via dropbox agilekeychain) to create 2 secondary vaults (changing each specific vault Master password) and manually deleting irrelevant entries in each specific secondary vault.

WSAC: 8.0.6.105
WSAC Webfilter 1.0.1.40
WSAC Password Manager 2.5.5

Usuage Scenario(Background/History):
My typical working scenario uses primarily Safari Browser and only resorting to Firefox and then Chrome if I suspect a compatabilty problem. Up until I started using secondary vaults in 1PW 4.1.2 I had the relevant browser extensions for both 1PW and WSAC all cohabiting concurrently in all three browsers.

I had also been testing WSAC own Password Manager for last few months: I’ve no intention on relinquishing 1PW as it’s far more conceptually versatile than the WSAC pw component, however autofill on 1PW is sometimes(often?) problematic on some of the sites I use(requiring manual copy/paste of authentication details), and WSAC PW manager appears to be far more efficient in this regard.

Fault Scenario:
As stated when I now use 1PW4 extension to log in to one of my secondary vaults(e.g. Tony) and then click on helper icon then 1PW mini/helper crashes quite frequently!
Logging into to Primary/Master vault didn’t appear to induce anything like the same crash occurrences.
Initially I’ve tried combinations of 1PW 4.2.2 and 4.3Beta along with 1PW Mini 4.1 and 4.2beta and punted the crash logs to 1PWJedi but realised I need to narrow down possible extension conflicts. So far it appears that disabling both the WSAC extensions in Safari has stabilised 1PW mini 4.2beta15.
I’m currently trying to correlate 1PW diagnostics with 1PW versions and extend testing to other browsers and possibly regress to OSX10.8 and another MBP hardware model.

Heads-UP:
Of course testing is so far less than comprehensive and may be even (say graphics) machine specific and it would be premature to conclude that WSAC components are also specifically at fault as only 1PW extention/helper crashes at this time!
Thus I’m posting this initially on 1PW Support in the (very unlikely) event that any other 1PW4 user is also utilising WSAC application (perversely with it’s own PW extension) along with the similar 1PW multi vault scenario?.

Conclusion:
I certainly don’t want to provoke a time wasting “Not-Invented-Here” discussion but ironically since I started using Macs back in 2005 there have only been 2 “must have” applications that have both consistently impressed me over the years with the quality of their individual designs and (equally importantly) by the quality of each of their individual technical support organisations!
It just so happens that currently they initially now appear to be in conflict with each other! :(

AlexHoffmann

Hi @horseman‌!
Thank you for your detailed error description.

I believe you're right in your assumption that WebRoot is the source (yes, I was tempted to say "root") of your problems.
Let me tell you why: 1Password uses web socket communication to exchange data between the vaults and the extensions.

Apps like WebRoot and it's services are often rather overzealous when blocking this kind of communication, resulting in failures in other apps.

Since we can't be sure that the WebRoot extension alone causes the problems, I'd like you to try and

1. Open the Webroot SecureAnywhere control panel.

2. Click on the gear icon next to ‚Identity Protection‘.

3. Click the 'Application Protection‘ tab.

4. Look for the following entries related to 1Password. The default setting for these should be ‚deny‘.

5. Change the setting for these files to ‚protect‘.

6. Reboot your Mac.

This should make the vault change work again.

Another idea would be to add an exemption for 1Password in the WebRoot extension, allowing communicating either for the 1Password extension as a whole (if possible) or allowing communication at the 127.0.0.1 IP

Here's more about this: http://learn.agilebits.com/1Password4/Mac/en/KB/filling-issues.html

These WebRoot support resources might also be of help:
http://live.webrootanywhere.com/content/542/Webroot-SecureAnywhere-for-Mac-OS-X
http://live.webrootanywhere.com/content/575/Controlling-active-Processes

Please let us know if this helps, or if there's anything else we can do for you.

Cheers,

---

Alex
Bearded Vulcan Support Technician @ AgileBits

horseman

Thanks Alex - Appreciate the tips, but unfortunately I've already covered these. Because the issue is sporadic and so far the only diagnostics are the 1P Mini-helper crash logs. Until I've fully checked other Macs and reproduced the issue (and thus confirmed it's not machine specific) it's also a tad premature to raise a support request with just those logs until I've tested more comprehensively(which with hols may well be a few more weeks)!
I've thus, as stated previously, only posted in the (unlikely) event any others encounter a similar issue in the interim.
Thanks again - have a nice Easter....

Megan

Hi @horseman,

I'm so sorry that @AlexHoffmann‌'s tips didn't get things solved for you! Please do let us know if you're able to reproduce this issue with more testing, and we'll be happy to investigate further. :)

horseman

Thanks Megan (and AlexH), but having updated thru some 1 PW4 beta's I'm now currently having problems recreating this.... (or on other Macs).

Megan

Hi @horseman,

I'm not too worried if you can't recreate the bug ... hopefully it has gone for good!

If it does pop up again, please let us know. ;)

horseman

Quick update: the 1PW4 mini crashes started reoccurring again on 11th May and appeared to be reproducible only on any of the 2 secondary vaults after the vaults had (auto)locked. These occurred on both Safari 7.0.3 and Chrome V32.... Since I was away from home I didn't have opportunity to test on my other Macbook. However today 1PW4 updated to 4.4.1beta2 and I noticed that there was a specific fix for "Fixed crash in 1Password mini's details view after locking and unlocking 1Password".
Directly after updating this did initially cause main 1PW4 itself to crash on opening a secondary vault (as opposed to crashing 1PW mini). Subsequent (un)locking of sec vault so far failed to recreate.
Obviously a lot more testing on my part is still required but the fact a potential fix now included in 4.4.1beta2 means some of my symptoms appear to have been experienced by others?

AlexHoffmann

That's a strange issue to say the least. Can you please monitor the situation and send us a diagnostics report to support+mac@agilebits.com if you can reproduce it successfully? With a reference to this thread of course.

Thanks!

horseman

Thanks Alex, yes still occurring on latest 4.4.1beta3 and I'm punting the 1PWmini crash logs back to support as they occur. I've also retained some 1PW diagnostics so I'll follow your suggestion in due course - thanks

Megan

Hi @horseman,

Thanks so much for keeping an eye on this for us! Please drop a note here when you do send the Diagnostics in so that we can take a closer look. :)

horseman

Hi @Megan, Just updated to OSX10.9.3 with 1PW4.4.1beta4 and 1PWMini 4.2.0beta21 and again the first invocation of a secondary vault crashes. Subsequent invocations work (as does Primary vault) until Macbook sleeps or vaults are auto locked. I have been punting the crash logs regularly to AgileJedi but not yet finished checking on my other mac/volumes and redacting all anti-malware and background apps to actually submit requested diags yet. Recent 1PW beta's all seem to mention 1PWmini crash fixes so I thought it was best re-testing first before submitting diags against latest levels?

horseman

@Megan - OK I bit the bullet and just sent a Diag to AgileJedi with link to this thread - Thanks

Megan

Hi @horseman,

Thanks for sending that Report in! I took a quick look in our system, but I was unable to find an email from the address you attached to your forum account. If you could send me a private message with the address that you used to send in the Report, I'd be happy to track it down and ensure that it gets answered quickly. :)

horseman

PM reply with details sent along with many apologies for my paranoid use of separate email addresses! ;) Many thanks for your patience....

Megan

Hi @horseman,

We've received your Diagnostic Report - thanks for sending it in! Someone from the support team will get back to you as soon as possible with some details.

.

horseman

@Megan, Many thanks to yourself and of course Alex who promptly replied with several pointers and suggestions. It does seem I missed the obvious when forking to 1PW4 beta and didn't appreciate that original Apple store 1PW4 was therefore not replaced by Agile Beta (as I recall always happened previously with Agile store versions!). Consequently there appears to be 2 plists and I had 1PWmini enabled/running in both. Duh!

Still early days yet but thanks to Alex I think I'm on now on the right path. Curiously (or perhaps obviously) the 1PW4 (Agile) beta uses/displays the Apple 1PW license?
That I suspect potentially prevents me from totally cleaning/removing the additional 1PW(Apple) version package from my system. I note that there are some instructions in KB (and probably on this forum) to rationalise/migrate the 1PW from Apple to Agile but note that "licensing migration" has not yet been covered?

I naively (long with a large degree of laziness) assumed back with Mavericks release last year that using Apple store 1PW4 upgrade would be seamless and avoid housekeeping Agile 1PW4 dmg's after installing and separately tracking licenses and seat compliance. Now appears this was a flawed premise and I should have stuck with Agile native app: "events stultorum magister_"!

Ho hum...... but 1PW was (and still is) worth enduring this inadvertent self-inflicted pain! ;)

I'll update here again later after I've unravelled the "knotted mess" from my system and tested more thoroughly!

Megan

Hi @horseman,

I'm so glad to hear that Alex was able to get things sorted out for you! Unfortunately, because of Apple's sandboxing regulations, the webstore version (and the beta) are built slightly differently than the Mac App Store version, which can make it a bit complicated balancing both the webstore beta version and the Mac App Store version. But it is possible to keep them both installed, provided you ensure that the Mini running is the correct one for the version you're using (as Alex probably already advised you.)

Curiously (or perhaps obviously) the 1PW4 (Agile) beta uses/displays the Apple 1PW license?

1Password's ability to find and read the license from the Mac App Store is a new feature. Due to Apple's review process for releases, some users have felt the need to switch from the Mac App Store version to the webstore version. Previously, this meant writing in to support with their Mac App Store receipt to have a webstore license generated. Now the webstore version can recognize the Mac App Store license information, making it easier for users who do want to switch.

I suspect potentially prevents me from totally cleaning/removing the additional 1PW(Apple) version package from my system.

Generally, if you are content to remain with the webstore version and want to remove the Mac App Store version, we only recommend quitting the app (using Command-Control-Q to ensure that the Mini is quit as well) and dragging the '1Password' (not the '1Password 4' app) to the Trash. This ensures that if anything does happen with your database, you will still have a nice cache of backups available from the Mac App Store version. Of course, once the beta/webstore version has built up a significant cache of backups on its own, we can discuss some more thorough cleaning, but for now, dragging the app to the Trash should be sufficient.

Please do let us know if you need any further help unravelling knots - we're here for you :)

horseman

Hi @Megan Thanks for the elaboration/explanation - I did subsequently trash 1PW(Apple) version but the 1PW4mini has crashed again since. I sent Alex the diags anyway but obviously I still need to continue to address the other two potential causes he suggested.

horseman

Somewhat anecdotal and possibly not even related but I perused the console log from initial 29Oct2013 date:

and found the first obvious crash on April11th this year:
Fri Apr 11 16:50:22 2014| 430012 [DATABASE:0x7f800xxxxxxx:] X _performSyncTransaction:withPriority: | Exception caught in (/Users/roustem/Projects/onepassword4/Subtrees/shared/ObjC/DataModel/OPDatabase.m:562): profile must be unlocked

Nice to see young Roustem is still keeping his hand in! ;)
(I obviously redacted last 7 hex chars of database)

This changed on 15th April with 430013 1PW4mini : Exception caught in (/Volumes/AgileBits/git/onepassword4/Subtrees/shared/ObjC/DataModel/OPDatabase.m:575): profile must be unlocked

but continues sporadically until now with different line/index. This appears to (very) circumstantially support the original hypothesis that some (probably Anti malware) application is blocking IPC between 1PW4mini and SQL database?
Even though it's not a showstopper (as 1PWMini restarts almost immediately) it would be nice if the exception handler caught this and displayed a popup dialog to suggest the user check their whitelists on any AV with option to continue perhaps?

However since I haven't yet deleted all my AntiMalware applications totally to (dis)prove the theory then it might be something completely different!
EDIT: perhaps even "application nap" feature of Mavericks? Lot's of speculative testing to try it seems! ;)

Watch this space...... ;)

horseman

Yet another update:

SHORT SUMMARY:

I disabled the 1PW4 app and 1pw4mini "application nap" settings with negative results - secondary vault still crashed after auto-lock/sleep.

However I then disabled Webroot WSAC (again) this time for 12 hrs and successfully managed to avoid any crashes during repeated auto-lock/sleep iterations!
(NB: from Alex's valued previous advice I had already checked that 1PW4 mini was ALLOWED in WSAC's "whitelist" )

I've now re-enabled WSAC as obviously I'm not prepared to take the risk to continue at length totally unprotected.

Instead I decided to live even more dangerously and am now concentrating on migrating the wifes MacBook which was running same WSAC version and 1PW(Apple)4.4 to 1PW4(Agile)Beta with multiple synched vaults to see if the same 1PWmini crash occurs on her system!

Should I survive that testing unscathed by the "Wrath-of-Khan" then I'll update in due course with the results. ;)

WARNING-LONG VERSION

In the meantime I had a response from AgileSupport that rather concerned/confused me!
I'll paraphrase along with my intended response:

After analysing my diagnostic troubleshooter I was requested to rename any "non relevant" agilekeychains as follows -

You may want to look for the 1password.agilekeychains here:

/Users/Tony/Dropbox/Security/1Password.agilekeychain

/Users/Tony/Dropbox/Security/Tony.agilekeychain

/Users/Tony/Dropbox/Security/Barbara.agilekeychain

/Users/Tony/Dropbox/Security/TonyOLD.agilekeychain

/Users/Tony/Dropbox/TessConfig/1Password.agilekeychain

/Volumes/MacHD-Lion/Users/barbarawilkinson/Dropbox/Security/1Password.agilekeychain

/Volumes/MacHD-Prod/Users/Tony/Documents/My Dropbox/Security/1Password.agilekeychain

/Volumes/MacHD-Prod/Users/barbarawilkinson/Dropbox/Security/1Password.agilekeychain

/Volumes/MacHD-Prod/Users/Tony/Documents/My Dropbox/TessConfig/1Password.agilekeychain

and my RESPONSE:

OK I’ve changed all “agilekeychain” extensions to “agileDDMMYY” where MMDDYY is last modification date, with the exception of the following:

/Users/Tony/Dropbox/Security/1Password.agilekeychain

/Users/Tony/Dropbox/Security/Tony.agilekeychain

/Users/Tony/Dropbox/Security/Barbara.agilekeychain

The reason being these represent the SYNC VAULTS for Primary and two secondary vaults (1Password,Tony & Barbara respectively).

A somewhat lengthy explanation as to why there were so many agilekeychain files may be useful:

1. Each AppleMac OSX major point release is contained in a separate bootable volume viz:

     MACHD-LION   = Mountain Lion 10.8.5
   
     MACHD-PROD = Snow Leopard 10.6.8 
   

2. It was easier for me when testing a new OSX release (e.g. Mavericks now on a 3rd “Mac-Mavericks” bootable volume) to regress to previous workable OS to perform a comparative check if perceived bugs were encountered. However I still needed to use 1PW system with uptodate keychains!

3. I have been using a 1Password 3 Family license for several years and thus OSX 10.6/10.8 had 1PW3 and utilised agilekeychain on Dropbox in order to sync across two family users and 2 MacBooks (both which had these 2 user logins/accounts).

4. When Mavericks was released/installed around Oct2013 then I upgraded to 1PW4 via Apple Store.
   (on reflection a big mistake it seems and on hindsight I should have continued to procure via Agile store as I had for all previous upgrades)

In April this year I became aware that multiple vaults were available(which avoided sharing same master password and reduced the individual users relevant password records) and subsequently switched to Beta fork and thus incorporated an additional two SYNC preferences (for 2 secondary vaults) in addition to Primary Vault all located on DropBox.

Up until your response/suggestion I had no reason to suppose these scenarios were not fully supported?
In fact I’ve been sporadically beta testing 1PW for years and my understanding was the legacy retention of agilekeychain format was currently retained in (external synch locations) precisely to afford backwards compatabilty for 1PW4 and previous 1PW3 to communicate together?

My only error being that I was not aware till recently that the newer local SQLlite databases for Apple & Agile native 1PW4 apps were in slightly different locations and that some care was now required to also avoid implementing both 1PW and 1PW4 mini extensions on same account when migrating between these subtly different versions!

Bottom line is these crashes only started when using multiple vaults in middle of April and I believe these are still potentially caused by race/timing conditions due to interaction of a specific AntiMalware product(Webroot WSAC) that I suspect is occasionally locking the “vault profile” on local SQL Db after vaults are both auto-locked and system also resumes after a sleep state.
I’m currently trying to test that hypothesis by introducing same beta/multiple vaults on second Macbook while disabling Anti-malware on the problem system for extended periods.

Apologies for the length of the explanation and if this appears at all argumentative and/or ungrateful but I’m now really seeking clarification in case my premise on how 1PW functions above is still fundamentally flawed?

Megan

Hi @horseman‌,

Thanks for the updates! I've added these latest notes to the email thread - I think it's best if we continue this conversation via email, just so we don't end up duplicating efforts or confusing things further. :)