Apache OpenOffice (AOO) Bugzilla – Issue 115778
Launch of OOO 3.3rc6 fails with "fatal error [context=user] caught unexpected exception"
Last modified: 2017-05-20 10:32:08 UTC
When OO.o 3.3rc6 is launched on a Windows XP machine that was previously running 3.2.1 without issues, it fails during launch with the error: --------------------------- OpenOffice.org 3.3 - Fatal Error --------------------------- The application cannot be started. [context="user"] caught unexpected exception! --------------------------- OK --------------------------- this error is displayed after the Oracle/OOO splash appears, around when you'd expect the first progress bar step. In case it matters, this machine has a roaming profile with %APPDATA% redirected to a Windows 2008 server, with the path: \\servername\sharename\appdata\username\AppData\Roaming Redirection is configured using Group Policy features as standard on Windows systems. This is a common configuration on business machines. I have not yet tested to see if I can reproduce the failure without folder redirection, as I don't have an un-redirected Windows XP machine to test with at present. I'll attach a Process Monitor log showing the event trace from oo.o startup. For those not familiar with it, Process Monitor from Microsoft Sysinternals: http://technet.microsoft.com/en-us/sysinternals/default.aspx is kind of like strace for Windows with built-in filtering and analysis. The log may be informative. It ends when the fatal error dialog is displayed.
Created attachment 75128 [details] Process Monitor log (zipped)
Note that I'm uncertain the version selected is correct. The installer used was today's 3.3 as shown on the website front page. The file name is OOo_3.3.0rc6_20101120_Win_x86_install-wJRE_en-GB.exe .
I can confirm this bug with OO.o 3.3rc10. Windows XP SP 3. It has also a roaming profile. Same configuration as above. Setting up a clean Win XP (but same profile) doesn't helped. The error seems to be within the roaming profile. OOo 3.2.1 worked well.
On the same PC: local account - OK domain account, this error
I confirm this bug with OO.o 3.3 final. I have roaming profiles with user folder "Application Data\OpenOffice.org" on network share. With local profile works.
Add me to CC
confirmed by various people - regression
,
cd->ringerc: Thanks for the Process Monitor log file. This log file helped a lot to understand what's going on and wrong. It looks like a problem related to the UNC path used for the user profile within the deployment library which is responsible for extensions. cd->jl: Please take over.
cd: Set myself on CC.
Also seeing this with release version: fails with roaming profile, works using a local profile. Added to CC.
windows server 2003 TS
FYI, I opened a similar bug for LibreOffice: https://bugs.freedesktop.org//show_bug.cgi?id=32135 IMHO, this is as critical as they come. This defect makes it impossible to use OOo and LO in a corporate environment -- redirected folders and roaming profiles are a mainstay. The worst part is that this defect probably catches most people (including me) by surprise -- my master PC image isn't joined to the domain, so I upgraded to the latest version, verified that the upgrade worked, and rolled out the new image to my private school, re-joining each machine to the domain. Later I was notified by a student that LibreOffice is entirely broken for them, so they now use Microsoft Office 2003 which happened to be installed as well. This is a significant setback for the OOo/LO marketing, promotion, and adoption efforts, so I'd love to fix it ASAP. I'll be happy to test patches / nightly builds; just let me know.
Setting target 3.4
I have the same bug except that: OOO 3.3 is installed system-wide on an XP virtual machine. Il I launch it with my administrator loging, it runs well. But the issue appears if I launch it with another account (restricted) with te comment : context = [shared] An I confirm no issue on 3.2.1 release. Under Linux, this bug does not appear.
It's a problem in release version, only seems to affect network users with profiles on a network share (which is all of them except the administrator!)
i can confirm this bug. BUT i am not using a networked profile. the problem exists only if i install oo for my user account. reinstalling it system-wide works. system is windows 7 ultimate x64.
OpenOffice 3.3 gets fatal error if %appdata% is redirected. Only happens if the user never started OpenOffice before %appdata% was redirected, the user has no problems if OpenOffice was started before %appdata% was redirected. Seems like the problem lies in %appdata%\openoffice.org. I have tried to rename %appdata%\openoffice.org on a user that openoffice was working for (did use openoffice before %appdata% was redirected), then openoffice generated it again and Fatal error. Put back the working %appdata%\openoffice.org folder and everything works. Have tested this on Windows 2003 and 2008 R2 terminal servers.
paalfe, when you say "OpenOffice 3.3 gets fatal error if %appdata% is redirected", that exactly do you mean? Do you mean if the environment variable APPDATA as its value has an UNC path? Do you set that environment variable in the Control Panel as a User variable, or as a System variable, do you set it in a cmd.exe prompt using the set command before starting soffice.exe (or soffice.bin)? Or what? (I tries most of this, but could not reproduce the problem.)
(In reply to comment #19) > paalfe, when you say "OpenOffice 3.3 gets fatal error if %appdata% is > redirected", > that exactly do you mean? Do you mean if the environment variable APPDATA as > its value has an UNC path? Do you set that environment variable in the Control > Panel as a User variable, or as a System variable, do you set it in a cmd.exe > prompt using the set command before starting soffice.exe (or soffice.bin)? Or > what? (I tries most of this, but could not reproduce the problem.) I mean I have used Group Policy in Windows Active Directory Domain to create a policy that redirects everyone's appdata folder to the same location, also called roaming. The reason I do this is that we have terminal servers at work and a lot of data is stored at appdata, if we did not redirect appdata it would be copied to the terminal server every time they logon witch give a longer logontime. This is how I have set up the redirect policy. Windows server 2008 R2 -> Group Policy Management -> New Policy -> User configuration\Policies\Windows Settings\Folder Redirection\AppData(Roaming): Target: Setting = Basic - Redirect everyone's folder to the same location. Target folder location = Create a folder for each user under the root path. Root path = \\server\users Settings (enabled): On - Move the contents of AppData(Roaming) to the new location. On - Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP, and Windows Server 2003 operating systems. On - Leave the folder in the new location when policy is removed. Ex. For user Clair, this folder will be redirected to: \\server\users\Clair\Application data
Got this bug too on my Dutch Win7 64 machine with local profile. Had OOo 3.2 running for some time which told me there were updates, when using the update button it said I had no browser. So I deinstalled and installed OOo 3.3. Now I have MS-Office....
Looks like the problem is solved in OpenOffice.org 3.4 Alpha Release (build DEV300m101). I have tested it and the problem did not occur.
This was fixed in cws jl164. The fix for supporting long path names apparently fixed this issues as well. @tm: Please verify this issues on the the current milestone.
Checked and verified in the current milestone -> OK !
Hi, I was unable to run version 3.3.0 due to this bug. I downloaded 3.4B and it works fine. Thanks for all the hard work folks put into this product! My platform: Win 7 64bit Dual quad core 2.5GHz C: 647GB Again, Thanks!!!
Looks not totally fixed as it posp up in OO 3.4.1.
Created attachment 79934 [details] screen shot of exception pop-up Looks like not totally fixed as appearing in OO 3.4.1 (see attachment).
(In reply to comment #27) > Created attachment 79934 [details] > screen shot of exception pop-up > > Looks like not totally fixed as appearing in OO 3.4.1 (see attachment). you error is likely unrelated to this original bug, but related to a known bug listed in the release notes: http://www.openoffice.org/development/releases/3.4.1.html#AOO3.4.1ReleaseNotes-KnownIssues Apache OpenOffice 3.4.0 and 3.4.1 manage the user profile differently than previous versions. The old user profile is automatically converted so that users can keep their extensions and settings. In a minority of cases, especially with highly customized profiles (many extensions or customizations) the conversion doesn't succeed. Common symptoms are: frequent application crashes, problems with dictionaries or thesaurus, OpenOffice starting and crashing after a few seconds. To solve this, just reset/rename your user profile as explained in the official OpenOffice forum. http://user.services.openoffice.org/en/forum/viewtopic.php?t=12426
(In reply to comment #28) > (In reply to comment #27) > > Created attachment 79934 [details] > > screen shot of exception pop-up > > > > Looks like not totally fixed as appearing in OO 3.4.1 (see attachment). > > you error is likely unrelated to this original bug, but related to a known > bug listed in the release notes: > > http://www.openoffice.org/development/releases/3.4.1.html#AOO3.4. > 1ReleaseNotes-KnownIssues > > Apache OpenOffice 3.4.0 and 3.4.1 manage the user profile differently than > previous versions. The old user profile is automatically converted so that > users can keep their extensions and settings. In a minority of cases, > especially with highly customized profiles (many extensions or > customizations) the conversion doesn't succeed. Common symptoms are: > frequent application crashes, problems with dictionaries or thesaurus, > OpenOffice starting and crashing after a few seconds. To solve this, just > reset/rename your user profile as explained in the official OpenOffice > forum. http://user.services.openoffice.org/en/forum/viewtopic.php?t=12426 TNX Ariel for pointing this out. I'll have a closer look.