Mac (10.9) kernel panic WSAC 8.0.5.66:128 with user switching

Having now successfully autoupdated to latest WSAC(Mac) version which now has Mavericks kernel fixes and thus appears stable(up to a point) I started to utilise “user switching” feature in Mavericks and noticed that if I attempt a “logout”, restart or shutdown on any concurrent user that it invariably causes a “kernel panic”!.

Now it’s a little early to point the finger but this occurs on two separate MacbookPro’s (a 5,1 and 7,1 model which pass h/w diagnostics) and one of the common kernel extensions is of course Webroot?.

Obvious question, before I attempt to build a 3rd test bed and/or submit panic logs to WR support, is to ask whether any other Mac (Mavericks) WSAC user has tested with “user switching” as above?

I’ll place a link to this on Webroot forum as well.
EDIT: >Mac-10-9-kernel-panic-WSAC-8-0-5-66-128-with-user-switching

 

Thanks, I'll pass this on to the team and let you know what we find!

 

Do you happen to have the kernel panic reports? 8.0.5.x fixed the only known panic which we've come across but perhaps the update didn't fully remove the offending components.

Thanks!

 

Yes - all of them from both MBP's! Presumably you want me to zip them up and attach to a Trouble Report?
Remember I'm not anyway 100% convinced this is down to WSAC as such yet (don't want to cry wolf!) as my other current wild theory also point's at Nvidia hardware/driver on these mid2009 and 2010 MacbookPro's.

Unfortunately I'm about to otherwise be "distracted" for another week but can comply later as required?

Many thanks again for your response/interest.

 

You can send them zipped or through a file transfer service to my username at gmail.com and I'll have our guys take a look at them straight away.

Thanks!

 

Sorry but check your PM for alternative links as either an ISP (or Idiot problem) this end...

 

Received - thanks!

 

Thanks Joe, although I doubt the back room Mac guys will find anything conclusive in the logs that points to WSAC!

In meantime I managed to break the gui about an hour or so ago when scrolling thru SYSTEM CONTROL which hung then crashed.
I've added the Webroot crash log, a subsequent System Analyser Report, and a couple of system stats screenshots to a subfolder "Tony -MBP logs" in the Dropbox link already advised.
Unfortunately the crash log has no backtrace so again will not be particularly useful.

I/we probably suspect that inevitably I'm going to have to "bite-the-bullet" and de-install WSAC and disembowel any remnants with a sudo(root) command and re-install a fresh 8.0.5.66 again.

However I'll wait before taking unilateral action in case Mac support offer any feedback/suggestions and/or a new WSAC(Mac) update is pending?
Although uninstall will at least give an opportunity to check whether "user switching" panics are related to WSAC or not?

 

Thanks, I think it would be worth waiting to uninstall until the guys have gotten a chance to fully dig through it, if at all possible.

 

The team has confirmed that this is happening on the latest version of WSA so it looks like we are at fault. We're digging in deeper now and will hopefully have a resolution for you soon!

Also, with the UI crash, is there any possibility that it's reproducible on your system?

 

Thanks for the update(and thanks to Mac Team as I didn't expect them to find any tenuous correlation immediately anyway!).

I'll now concentrate on stressing the UI (I suspect this is more likely after an extended uptime/sleep cycle with >250 tasks/>1150 threads and <150MB free memory) so as yet not reproducible.
However with my proclivity to engineer some pathological stress/resource scenarios over the years I'm sure I can break it eventually!

Watch this space....

EDIT1: as a somewhat tangental after thought/suggestion would there be any "mileage" in using the lower LH main gui screen to advise of potential issues/known problems(instructions to email panic logs initially etc perhaps)? Even given the customer base on Mac may well be magnitudes lower than PC population I'm a little suspicious that no other Mavericks/80566 user has yet appended here or on Webroot support fora?

EDIT2: Appears easier than I thought to crash gui! Sometimes less than 10-20min scrolling through Active Processes, and even with Block/Allow panel. Also will crash with as little as 170 Tasks 800 Threads and >1.9GB free memory. Prevent App Nap enabled has no effect, and not yet confirmed whether I can reproduce same on other Macbook. As usual logs upload to Dropbox link.

 

Huston(Apollo13) - We have a problem!

I thought the code signing issue in Mavericks had been fixed in WSAC(Mac) 8.0.5.66 ?

OK may not be related to the GUI crash but while pursuing that specific issue I regressed to my Mountain Lion (10.8.5) boot partition on same MBP hardware which was still on WSAC 8.0.4.236.
Now there were no previous WSAC crash logs and as it was running it's initial scan and thus not autoupdating I played with System Control to see if I could force a crash.
Certainly in 15 min I tested I was unable to reproduce the issue so I manually forced update to 8.0.5.66 version.
That after 10min produced a GUI crash (actually while attempting a System Analysis!).
Checking the system & WSA install logs it appears 8.0.5.66 was throwing credential,authentication and code signing errors!

Since SA Report failed I copied those logs manually(+ the WSA dmg) to (yet another) subfolder "Tony Mountain Lion - Same MBP" under same Dropbox link as previous.

Now admittedly I'm getting a tad confused with this new unexpected revelation and wonder whether pursuing a gui crash further is worth my time/effort until this fundamental "code signing" issue is clarified?

EDIT1: If it helps - ~5:35GMT entry in system log illustrates repeated credential/authentication errors.

EDIT2: ....and I can confirm that I can also crash the WSA GUI on the other MBP system! Unfortunately the system/install logs have been rotated/archived to Time Machine so if you need these then I'll need to search over 800GB of my TM server!

 

Thanks - I'll pass the latest over to the team. The fix for the kernel panic will be in place in the next build, but I'm surprised to hear that there is a code signing issue still. I'll let you know what we find.

Thanks!

 

Frankly so am I, and given the thoroughness of your back room development guys if I hadn't seen the entries in system and install logs I wouldn't believe it myself!
Ref your PM therefore a Remote session is next obvious step, although I was trying to avoid that as given the lack of any other similar user reported issues on fora then I'm suspiciously inclined to think I've managed to induce another pathologically user specific configuration again!
(Like the ones you've "enjoyed" spending 5hrs remoting from Chicago/Idaho to Hove UK in previous years! )

So now here's the "interesting" confusion factor to muddy the waters further:
In preparation to contact support ref your PM, I created a Webroot (Admin) ID, opened WSAC (whilst it was performing it's initial scan on new id) and then checked Safari and also tried scrolling thru System Control which behaved itself for at least 5min duration without crashing. Also configured my TeamViewer to accept remote session (albeit it's not a business copy so WR Support presumably will prefer Logmein remote target client again?)

Closed Safari and in due course received the option for installing Safari WR Shield extension which when subsequently opening Safari again got the usual prompt to allow it's install.
When I restarted Safari again then my troubles began as the desktop totally locked! Cursor moved but no response to SHUTDOWN/RESTART et al nor via any DOCK item. Attempting to switch user got me to login screen but my userid just hung on the Login screen.

BRS time and subsequent reboot caused a lockout(hanging on login screen) from any userid I tried! (Worringly SAFE BOOT also failed to run!)
Having therefore rebooted back to my Mountain Lion, ran Disk Utility, and hardware diags and becoming increasing concerned when even my ML volume threw a kernel panic when attempting to shutdown, I eventually had to use OSX Mavericks recovery and re-install OSX 10.9 over the top of existing Mavericks boot volume!

Everything restored (including Webroot admin user account with Safari and it's Web Shield) but I'm a tad hesitant now to stress it further until I confirm it's stable enough to continue organising a Remote Support session?.
Otherwise if it's a hardware issue my diags are not recognising I'm going to waste your guys time further!

In meantime, one observation you might kindly bounce off Mac Team is that because I run with verbose boot log I noticed the occasional "NSPACE-HOLDER-UNBLOCK: DID NOT FIND TOKEN....." previously which hasn't reoccurred yet since the RECOVERY RESTORE?

 

I agree waiting for some semblance of stability prior to setting up a remote session. We'd use LogMeIn as normal if possible.

Also, the team has commented that while there are some system messages which might appear to indicate code signing problems, it looks like they are not. A remote session will still be more definitive but I suggest giving it a day or two to ensure you're back online and functioning relatively normally.

 

I don't seem to have the original LOGMEIN client anymore and I therefore presume it's generated per support session with a download link that WSA Support will provide when they’re ready?

That's interesting, but reassuring it was indeed a false+/“red herring” !

I've been testing and it appears stable enough to sustain a remote session as far as I can tell. I've already raised support request on link you pm'd along with some suggested times sufficient to cover most time zones I hope! However I think I’m prematurely and potentially wasting their time (see bottom of this epic tome)

In meantime I've continued checking various Maverick accounts and WSAC GUI and made the following observations (although not enough time to be conclusive):
1. So far haven't crashed the GUI.

2. On a non-admin account the Webroot extension refuses to be installed on Safari & Chrome. I assume this is a known problem?

3. Based on above I re-tried "user switching" again briefly and found if I shutdown WSAC and then "switched" to another ADMIN account, SHUTDOWN WSAC on that account first then I could logoff without inducing a kernel panic!

4. This failed on GUEST account which consistently threw a kernel panic. There again GUEST does attempt to delete all user docs/configs and I wonder if that also includes user tmp files/caches?

5. Another Mavericks user on Webroot forum also asked the question(to which he was referred to support so as yet no answer on forum) which I'd been pondering on concerning the System Analyser feature. It returns similar responses on his system as I'm experiencing regarding:

a) Large number of processes - which may be true as my other monitors also show 180 tasks and 970 threads with >2GB free memory. However running it twice (having subsequently deleted the kernel panics which initially were also flagged) didn't consistently produce the same result on second iteration?

b) High amount of RAM used by processes - have 721MB wired, 2.44GB Active, 2.09GB Inactive and 2.52GB free so difficult to relate this to whatever threshold is being used? Albeit I suspect Safari is leaking (4 JS Global "world leaks" detected via it's debug menu!) as the amount of free space reduces markedly faster than say when using Chrome.

c) Less than 30% hard disk space free - which is indeed correct but can be misleading if you have multi boot volumes as my monitors are showing 38GB used with 51GB free on the boot volume I’m currently using?

d) Large number of temporary & open files files -
The detail report displays this as:
Recoverable Space
--------------------------------------------------------------------------------
User Temporary Files 441786KB (/Users/Tony/Library/Caches)
System Temporary Files 518087KB (/tmp and /Library/Caches)
Recycle Bin 42KB (/Users/Tony/.Trash)
Safari Cache 72401KB (/Users/Tony/Library/Caches/com.apple.Safari)
------------------------
but doesn't other wise indicate the threshold? As the 8.0.5.66(Mac) doesn't yet have a System Optimiser [*]then when I run my 3rd party tools optimiser (cocktail) it still reports a similar amount after a restart:
Recoverable Space
--------------------------------------------------------------------------------
User Temporary Files 419068KB (/Users/Tony/Library/Caches)
System Temporary Files 517990KB (/tmp and /Library/Caches)
Recycle Bin 42KB (/Users/Tony/.Trash)
Safari Cache 49421KB (/Users/Tony/Library/Caches/com.apple.Safari)
————————————————————————————————
Again that’s a tad confusing because SA is stating “number of files” but detailing total size of files/cache? Of course with “high number of processes” you might expect higher number of open files and temporary files anyway perhaps, so the fact some tmp files/caches are regenerated after reboot might be expected?

All that laborious explanation and bottom line is I’m still leaning towards user specific (mis) configuration. Of course the original objective was to see if I could break WSAC - I certainly “broke” my Mavericks boot volume(as I never experienced kernel panics before on previous OSX releases) but I can’t conclusively see that I’ve pointed the finger at Webroot.

[*]The fact there is no System Optimiser in Mac WSAC agent is obvious - unlike PC/Windoze then most “cleaning utilities” that “remove tmp files/caches” and “defrag” are effectively “snake oil” on Apple Mac as effectively OSX Unix based then apart from corrupted (system) caches these 3rd party tools only achieve a temporary solution and sometimes are even counter productive(e.g. deleting boot caches that temporarily prolong boot times until regenerated).
I’ve just performed a massive wipe of system/global user caches as I was experiencing massive CPU loads on some Safari Webkit and Mail Web processes, which now have not yet re-occurred.

Despite my critique of SA feature I believe it’s concept is useful and I’m inclined to use it’s output (in conjunction with iStats menu monitor & etrecheck) continue and remove some of my test apps like SophosAV , launchdaemons/agents, and investigate potential leaks in Safari/plugins first?
Until WS Mac team have released a “kernel panic” fix they appear to have identified I think I’m wasting their (and your) time in pursuing other co-lateral GUI issues as i suspect other crashes are due to the panics corrupting key system caches despite the OSX’s inherent journalling feature?

 

I agree that it's probably worth waiting for the next build before digging in closer. LogMeIn clients are sent on a one-time-use basis so you'd receive a new one if/when we need to connect.

As for System Analyzer, this tool is used by several of our "tech bench" partners who want a quick view into a system, so there are a number of thresholds built into the product. We expose the same functionality to our direct users as well but the data needs to be interpreted a bit to fully understand it (as it is geared toward technical users).

 

Lucas has just given me Alpha build 8.0.5.74 to test and ironically Apple have also released some stability(?) fixes and thus I'm now on OS X 10.9.1 (13B42).

I've advised Lucas I'm away later today (caravan) and limited to somewhat erratic mobile connection. I'll update my local dropbox (link on my previous pm) with results/details as I test but obviously dropbox synch to cloud will be dependent on my somewhat unreliable connectivity.

Therefore in case I'm incommunicado do have a merry xmas & happy new year!
...with many thanks for your and support teams assistance!

 

Re: Update on Mac (10.9.1-13b42) WSAC 8.0.5.78:130 with user switching

Nearly two weeks later and WSAC is now at 8.0.5.78:130 and although I haven't stressed "user switching" as much as previous tests, it does seem to continue to function for short duration sessions without inducing further kernel panics.

Not sure whether this current version is still alpha/beta release? Webroot forum Release Notes only currently list 8.0.5.66 as latest production release?

 

Re: Update on Mac (10.9.1-13b42) WSAC 8.0.5.78:130 with user switching

Thanks for the update! At the moment, .66 is the live production release and .74 is the public beta release.

 

Re: Update on Mac (10.9.1-13b42) WSAC 8.0.5.78:130 with user switching

Joe, Happy New Year and many thanks for the info. Now back at home I've had the opportunity to stress test both Macs (now both on OSX 10.9.1 13B42 and WSAC 8.0.5.78:130) with "user switching" and "remote admin" and can happily report I've still been unable to incur any further kernel panics using alpha .78!

There are a few anomalies with graphics rendering and on the lower (4GB) spec'd MBP with WSAC disabling it's Webshield upon logon but suspect these may more likely be OSX related and/or possibly side effect of using WSAC alpha code?

Before I start re-installing Sophos (and any other apps I previously removed because of their kernel extensions) and re-testing again I'd appreciate some pointers on the various release versions. I'm somewhat reluctant to regress back to production release until it's at least at minimum .74 level but appreciate that continuing with alpha releases may "muddy-the-waters" further as by definition they are not necessarily guaranteed to be as stable?

As a long shot (I suspect the answer is no), are there any release notes from .74 thru .78 I can access or that you can send/PM?

I could compromise with Beta version (.74) albeit I did incur 2 sporadic traps at that specific level previously, but it will be less version volatile than the alpha fork?

 

Re: Update on Mac (10.9.1-13b42) WSAC 8.0.5.78:130 with user switching

I think it's worth keeping with the current alpha build. We don't have the changelogs available at this point but we do have another build which will be coming in the next handful of days that has some additional improvements which may correct the web filter issues you're referring to.

 

Re: Update on Mac (10.9.1-13b42) WSAC 8.0.5.78:130 with user switching

Many thanks again for your sage advice. Thus I'll stick with alpha builds on two Mac's I have easy access to, and patiently await opportunity to retest forthcoming version but avoid updating my nomadic son's Mac from his current .66 production release who's less likely to use "user switching" anyway.
The perceived anomalies in alpha build are relatively trivial anyway compared to enduring the more disruptive kernel panics!

Many thanks again.

EDIT: and I didn't have to wait long as just as you predicted 8.0.6.36:133 alpha has been pushed on both local Macs and initial indications are promising wrt to Webshield et al anomaly fixes.