Generically, a number of things have caused the application to crash, often with no clear cause or easy resolution, but we're not having this trouble with 14.0.0.
Jabber 14.0.1 "crashes" (it looks like a bug check, it doesn't actually crash just open the "Jabber has stopped working" box) and pops up Sennheiser SDK boxes.
If it's acceptable, clear the application's local data and install Jabber fresh instead of an over the top install, and see if it continues. I've had to do this before where for whatever reason one of the local databases is corrupt.
With the software upgrade URL defined, I have had this cause Jabber to crash. I'd wonder if you have an e911 popup that could do the same thing.
Generally if I had the time to go through this myself, I'd:
- Remove the configuration/local data from the machine and start fresh. Sign in and see if it crashes. Test with another JID as well. This ensures the client isn't trying to render chat history content (I believe since 11.7 it will 'restore' all the chats automatically) that it is unhappy with.
- See if you can catch in the log before it crashes out what it was trying to do, what was being passed to the renderer.
- Examine the configuration file Jabber is loading and any custom tabs/rendered content that may come with, such as the e911 notification or software update URL.
- Try with a dummy user that isn't dragging XMPP rosters/locations/etc with them to see if this is related, but it shouldn't be related to Chromium crashing.
- Delete/Rebuild the UCM device's configuration, which similarly should not be related.
- Last ditch would be to see if there's some sort of DNS/proxy based item that may be intercepting content, should your Jabber client be off parsing telemetry/webex content from the internet. I don't know if any of this touches libcef, but if you're intercepting some call and injecting content perhaps that is an issue, but I've never heard of such a thing happening, just musing.
