Bug 33970 - Refuses to start with roaming profiles and redirected folders
Summary: Refuses to start with roaming profiles and redirected folders
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: x86 (IA32) Windows (All)
: highest critical
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
: 32135 34817 35583 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-02-06 11:28 UTC by Philip M. White
Modified: 2011-05-20 03:24 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philip M. White 2011-02-06 11:28:02 UTC
I installed LibreOffice 3.3 on a standard image with Windows XP SP3 for a small private school.  I am able to run it as a non-administrative user before it's joined to a domain.  Once I join the machine to the domain, a non-admin user cannot start LibreOffice; it gives one of two errors:

The application cannot be started.
[context="bundled"] caught unexpected exception!

or

The application cannot be started.
[context="user"] caught unexpected exception!

with the second error being more common.  I did not modify the selection of components to install; I used the typical installation.  The standard image used to have OpenOffice 3.3 installed, but I did a clean uninstall of OOo before installing LibreOffice.

Some online research shows that other people are having the same problem.  For example, see http://en.libreofficeforum.org/node/180.

For reference, OpenOffice 3.3 has exactly the same issue.

My environment has roaming profiles and redirected folders.  I've not yet tried messing with group policy to see how LibreOffice reacts; I plan to, but I wanted to open the bug ASAP.  I will eagerly try whatever ideas you have, as the private school would love to get LibreOffice working.
Comment 1 vitriol 2011-02-06 22:58:15 UTC
> For reference, OpenOffice 3.3 has exactly the same issue.

Issue report for OOo:

http://www.openoffice.org/issues/show_bug.cgi?id=115778
Comment 2 Thorsten Behrens (CIB) 2011-02-07 00:20:41 UTC
Tor, any idea what could be the problem?
Comment 3 Don't use this account, use tml@iki.fi 2011-02-07 00:35:29 UTC
I quote from the OOo issue: "It looks like a problem related to the
UNC path used for the user profile within the deployment library which is
responsible for extensions."
Comment 4 Don't use this account, use tml@iki.fi 2011-02-07 05:48:40 UTC
*** Bug 32135 has been marked as a duplicate of this bug. ***
Comment 5 Patrick Oltmann 2011-02-15 18:48:50 UTC
I can confirm this bug (WinXP Pro SP3). Everything works nice when using a local sysadmin profile, however usage of a roaming profile triggers the two exceptions listed above. The issue persists in LibO 3.3.1 RC1.
Comment 6 Philip M. White 2011-02-16 10:39:33 UTC
Having reviewed the list of other blocker and critical LO bugs, I've raised this issue's importance.

On a related note, the equivalent OOo bug has been marked to be fixed by OOo 3.4.
Comment 7 Don't use this account, use tml@iki.fi 2011-02-16 14:26:26 UTC
It would be nice if we could fix this in 3.3.2. Does anybody know a way to reproduce it on a non-domain-member machine?
Comment 8 Philip M. White 2011-02-16 14:41:02 UTC
Tor, not sure about that, but here's an alternate approach: teach me to build the source from git for the Windows platform.  Assuming the issue was introduced sometime during LibreOffice's lifetime, I could bisect to the offending commit.

Or, build me the first revision from git and I'll try it.

Right now I cannot find any build-for-Windows instructions on libreoffice's site.
Comment 9 Don't use this account, use tml@iki.fi 2011-02-16 14:48:16 UTC
http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies and http://wiki.documentfoundation.org/Development/How_to_build should get you started. Then come to the IRC channel #libreoffice on freennode, or ask specific questions on the libreoffice mailing list. We very much want to help people in learning to build it!
Comment 10 Patrick Oltmann 2011-02-18 18:16:05 UTC
I have done some testing with the following betas of LibO 3.3:
- beta 1 (2010-09-27, OOo330m7, Build 9526, OOo-build 2010-09-24)
- beta 2 (2010-10-11, OOo330m9, Build 1, libreoffice-build 3.2.99.2)
- beta 3 (2010-11-15, OOo330m12, Build 2, libreoffice-build 3.2.99.3)

All of them start-up normally in a local user context but produce the errors described above when used with roaming profiles. In addition, beta 1 sometimes gave the following error:

The application cannot be started
A general error occurred while accessing your central configuration

To me this suggests that this bug was probably introduced before the OOo/LibO fork, which would be in line with OOo330 facing the same problem.
Comment 11 Trever L. Adams 2011-02-21 04:04:19 UTC
This bug still exists in LibreOffice 3.3.1 RC2 (2011-02-18). This is sad that it existed in 3.3 final release. It is very disturbing that it exists in RC2 for another release. I am happy to test out nightlies or what not. I have several domains with XP SP3, Vista (latest SP) and 7 (latest).

I would help with the code/build, but it has been ages since I had MSVC setup on any machines and used it.
Comment 12 Don't use this account, use tml@iki.fi 2011-02-21 04:15:08 UTC
No need to point out that the bug has not been fixed; if it had, we (developers) would have marked it as fixed here.

Nobody can figure out a way to reproduce the problem on a non-domain-member machine (but with other Windows machines in the same workgroup, if needed)? That would obviously be very useful so that this can be debugged.
Comment 13 Trever L. Adams 2011-02-21 16:19:30 UTC
Due to the fact that the bug seems to be with roaming profiles, I am not sure you can reproduce it any other way. I am using Samba 4 for the server if that is the problem. If it is because you don't have Pro/Business/Enterprise/Ultimate clients, I am not sure how to go about doing it.
Comment 14 Don't use this account, use tml@iki.fi 2011-02-21 23:12:13 UTC
Many of the people who would be interested and capable of debugging this, including me, have access to MSDN, so if really really necessary, sure, I can set up a domain between two virtual machines. It's just a pain to do just for some debugging of what no doubt turns out to be a very easy to fix error once you find the root cause.

Hmm, actually, I might have a domain set up in a vmware virtual machine running Windows Server 2003 I haven't started for ages, will have to check. I could then set up roaming progiles, however one does that (I don't have any Windows domain sysadmin experience), and join another virtual machine to that domain, and debug LibreOffice on that. But that will have to wait until I get back from vacation next week.
Comment 15 Pål Kristiansen 2011-02-25 00:41:40 UTC
LibreOffice 3.3.0 and 3.3.1 gets fatal error if %appdata% is redirected.
Also happens with OpenOffice 3.3.

Only happens if the user never started LibreOffice before %appdata% was
redirected, the user has no problems if LibreOffice was started before %appdata%
was redirected.
Seems like the problem lies in %appdata%\LibreOffice.

I have tried to rename %appdata%\LibreOffice on a user that LibreOffice was
working for (did use LibreOffice before %appdata% was redirected), then
LibreOffice generated it again and Fatal error.
Put back the working %appdata%\LibreOffice folder and everything works.

Have tested this on Windows 2003 and 2008 R2 terminal servers.
Comment 16 Rossetti Danilo 2011-02-28 03:02:12 UTC
*** Bug 34817 has been marked as a duplicate of this bug. ***
Comment 17 Philip M. White 2011-03-02 09:02:46 UTC
(In reply to comment #15)
> LibreOffice 3.3.0 and 3.3.1 gets fatal error if %appdata% is redirected.

I can confirm this. I changed the group policy to redirect Application Data back to the user's profile (while leaving all other redirections in place), and the problem is solved.
Comment 18 Don't use this account, use tml@iki.fi 2011-03-03 02:02:31 UTC
So, on a machine that is not a member of a domain, to reproduce the problem, it is enough to set the APPDATA environment variable to a UNC path before starting LibreOffice the first time?
Comment 19 Marius Tolzmann 2011-03-04 06:33:59 UTC
just run into this bug on linux after upgrading from 3.3.0 to 3.3.1...

something is wrong with my config in .libreoffice may be some locking problem?

this suprisingly solved it for me:

mv ~/.libreoffice ~/.libreoffice.xxx
cp -vax ~/.libreoffice.xxx ~/.libreoffice

sounds and looks stupid but it now works again 8)

i also tried moving it back:

rm ~/.libreoffice
mv ~/.libreoffice.xxx ~/.libreoffice

and it stopped working again..

my home is on a NFS3 Server so i suggest some locking problem but i don't have the time right now for further investigation..(like tracing NFS traffic or removing files one by one from .libreoffice) ..but i still have my ~/.libreoffice.xxx to test again later..

i am using a linux from scratch based distribution with kernel 2.6.35.10 and glibc 2.12.1.. arch=x86_64.. libreoffice is installed using the rpms for 64bit linux downloaded from the official website..

may be this information helps solving this bug.. i can provide more information if needed later..

bye.. marius tolzmann..
Comment 20 Marius Tolzmann 2011-03-04 06:37:43 UTC
i forgot to mention that the problem still existed after downgrading to 3.3.0 again..
Comment 21 Don't use this account, use tml@iki.fi 2011-03-04 08:12:35 UTC
Marius, whatever problem you have on Linux, it has nothing at all to do with what this bug report is about. This bug report is about a Windows-specific issue. Please file a separate bug.
Comment 22 Don't use this account, use tml@iki.fi 2011-03-09 00:15:17 UTC
Pål, when you say "LibreOffice 3.3.0 and 3.3.1 gets fatal error if %appdata% is redirected" what do you mean exactly? (I asked the same question to you in the OOo issue, see details there...)

I would very much like to fix this, but first I need to reproduce it, on a machine that is not a member of a domain.
Comment 23 Don't use this account, use tml@iki.fi 2011-03-09 00:25:25 UTC
It's interesting that even if I set an APPDATA environment variable in Control Panel:System:Advanced:Environment Variables, if I then run cmd.exe, it still has the normal value for APPDATA (C:\Documents and Setings\N.N\Application Data , on XP). So is APPDATA treated specially, does cmd.exe override any setting of it in its environment? Does explorer.exe ignore attempts to set APPDATA?
Comment 24 Don't use this account, use tml@iki.fi 2011-03-09 09:00:05 UTC
If nobody can come up with a way to reproduce this in a non-domain-member machine, could somebody at least give *exact* instructions how to set up "roaming profiles" and "redirected folders" when I have a Windows Server 2008 R2 running with the Active Directory Domain Services role activated, and have joined a XP workstation to that domain. (Both are virtual machines, and yes, I can ping one from the other.)

If you want this problem fixed, please at least help me to reproduce it! You who have the problem, can't you ask your sysadmin to write here a step-by-step guide how to set up a minimal temporary test domain with "roaming profiles" and "redirected folders", huh? Or are you attempting to use LibreOffice without the sysadmins knowing?
Comment 25 Trever L. Adams 2011-03-09 09:05:34 UTC
This is from a windows XP perspective. I do not have the updated instructions in front of me:

Click Start, point to Programs, point to Administrative Tools (Common), and then click User Manager for Domains or Active Directory Users and Computers
Select all relevant users, right-click one of the users, and then click Properties.
Click on Profile
User Profile Path type “\\SERVER_NAME\profiles\%USERNAME%” in the box, and then click OK. 
User Home Path type “\\SERVER_NAME\homes\%USERNAME%” in the box, and drive letter and then click OK. 
Right click on domain, do new GPO for full domain
1. User Configuration/Folder Redirection/My Documents to drive letter

Default Policy/User Configuration/Windows Settings/Folder Redirection/AppData
Basic
Create a folder for each user under the root path
\\%FILESERVER%.%DOMAIN\appdata
Settings: Grant user exclusive, move contents, also apply to 2000, XP, etc., leave when deleted
Default Domain GPO "Exclude Directories in roaming profile"
Comment 26 Trever L. Adams 2011-03-09 09:09:54 UTC
appdata is a share I setup, btw.
Comment 27 Don't use this account, use tml@iki.fi 2011-03-09 09:22:19 UTC
Thanks. There were indeed a couple of points there that I wouldn't have realized myself. Will try that out tomorrow. If anybody else has more hints, please add comments!
Comment 28 Trever L. Adams 2011-03-09 09:27:36 UTC
Sorry, forgot a few others %FILESERVER%.%DOMAIN are not real variables. They are just my way of remembering in my own instructions. %USERNAME% is a real one.
Comment 29 Don't use this account, use tml@iki.fi 2011-03-10 01:58:47 UTC
In WS2008R2, the "Profile" tab of the domain user properties has one entry box for "Profile path", so that should be \\%server%\profiles\%username% as you say in comment #25 then, OK. (Where %server% and %username% are replaced with the actual server and user names.) This is fairly clear.

Do I need to create this "profiles" share on the server beforehand, and set its owner to the domain user in question? Or is "profiles" some kind of "magical" share name?

But then about the "Home  folder", it is not so clear. There are two alternatives here, "Local path" and "Connect" (connect a drive letter to what I assume should be a UNC path). You mean I should use the latter alternative? Should I then create the "homes" share you mention and a subdirectory for the user under it, or will it be created automatically when the user logs in to a domain member?

I already yesterday had entered into "Profile path" a UNC path to a directory for the user I had created on the server (and left the "Home folder" entries empty), but when I logged in on the domain member machine, it complained it couldn't connect to the profile folder, or something like that. I guess I should try to figure out that first, or will filling in the "Home folder" stuff automatically make that work OK, too?

Thanks in advance for any further advice...
Comment 30 Don't use this account, use tml@iki.fi 2011-03-10 02:33:58 UTC
I think my current problem now is firstly to make it possible for the XP domain member to see and mount shares on the ws2008r2 server... that seems to require some extra trick I haven't figure out yet, I just get error 5 if I try "net view \\server" or "net use \\server\scratch x: /user:foo" where scratch is a share I made as wide-open as possible, and foo is a domain user. Hmm....
Comment 31 Trever L. Adams 2011-03-10 03:37:03 UTC
The homes share is a share I created. For me (XP, Vista, 7) it auto-creates the path for the user when you set it up, but you do have to create the share. And yes, I meant where you connect a drive letter to a UNC.

Profiles I think is magic if you are using Windows, but I do NOT know that. I have to set it up manually as I am using Samba 4. (http://wiki.samba.org/index.php/Samba4/HOWTO may or may not help as it is where I got a lot of the information, or at least where I started from.)

If you setup the paths correctly and they point to valid shares, then everything should automatically work. At least it does here for me.
Comment 32 Don't use this account, use tml@iki.fi 2011-03-10 03:39:06 UTC
OK, after explicitly creating the appdata\%username%, homes\%username% and profile\%username% folders on the server and making sure that user has max permissions to them and is their owner I think I got it working to some extent. At least I now can log in to the client without warnings.

But the AppData is still not redirected, I still see the LibreOffice folder being created in the XP client locally in C:\Documents and Settings\%username%\Application Data .

Maybe I really need to set up a Windows 7 client? (Unfortunately the one Windows 7 virtual machine I already have is in Chinese (I once wanted to check how something worked in a Chinese localisation...), and that is a bit hard to use...)
Comment 33 Trever L. Adams 2011-03-10 03:45:50 UTC
Ok, I think you must have failed to setup a GPO that applies to the user in question (mine are all domain wide at this time).

In group policy editor do the following (some things may be different if you are setting things up on Windows Vista/7 vs XP, so if the client is XP, do it there, also some locations may be correct for Vista/7, others for XP so you may have to search a bit):

Default Policy/User Configuration/Windows Settings/Folder Redirection/AppData
Basic
Create a folder for each user under the root path
\\%FILESERVER%.%DOMAIN\appdata
Settings: Grant user exclusive, move contents, also apply to 2000, XP, etc.,
leave when deleted
Default Domain GPO "Exclude Directories in roaming profile"

I think on the local machine it may show things still being in that directory as some of them are remapped, the question is to see if it exists in appdata\%USERNAME% on the server.

Check the APPDATA environment variable as well, see if it changed.
Comment 34 Pål Kristiansen 2011-03-11 04:36:52 UTC
(In reply to comment #22)
> Pål, when you say "LibreOffice 3.3.0 and 3.3.1 gets fatal error if %appdata% is
> redirected" what do you mean exactly? (I asked the same question to you in the
> OOo issue, see details there...)
> 
> I would very much like to fix this, but first I need to reproduce it, on a
> machine that is not a member of a domain.

I have replied in the OOo issue but I reply here too.

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
Comment 35 Don't use this account, use tml@iki.fi 2011-03-13 01:45:41 UTC
Pål, ok, so you use the normal \users folder on the server for the redirected app data. Should it be possible to reproduce the problem using *only* the redirected app data folder like that (and \users then shared, presumably)? I.e. redirection of "documents" is not needed, nor is it needed to set up separate homes, profiles or appdata shares? What do you do for profiles, do you set up anything in the "Profile" tab of the domain user properties?

I prefer to have an as minimal way as possible to reproduce the problem.
Comment 36 Pål Kristiansen 2011-03-13 03:51:11 UTC
(In reply to comment #35)
> Pål, ok, so you use the normal \users folder on the server for the redirected
> app data. Should it be possible to reproduce the problem using *only* the
> redirected app data folder like that (and \users then shared, presumably)? I.e.
> redirection of "documents" is not needed, nor is it needed to set up separate
> homes, profiles or appdata shares? What do you do for profiles, do you set up
> anything in the "Profile" tab of the domain user properties?
> 
> I prefer to have an as minimal way as possible to reproduce the problem.

When you say the normal \users folder on the server do you think of C:\Users?
If so I do not use the normal users folder on the server.

I have created a personal home folder for every user, lets call it homes instead of users. This folder is then shared and every user has it's own personal folder in here for personal stuff that only that person and domain admins has access to.

AppData(Roaming) Target Root path = \\server\homes

Ex. For user Clair, this folder will be redirected to:
\\server\homes\Clair\Application data

I also redirect Desktop, Documents, Pictures, Music and Videos folders to \\server\homes, but this should not have anything to do with LibreOffice/OOo error!

The only thing I do in the "Profile" tab of the user properties is:
Home folder, Connect = H: to \\server\homes\%username%

The User profile, Profile path is blank!
Comment 37 Don't use this account, use tml@iki.fi 2011-03-13 03:58:09 UTC
OK, thanks. I was misunderstanding your comment #34.
Comment 38 mal 2011-03-22 14:19:33 UTC
This seems to be fixed in the Oracle OO 3.4 alpha that has just been released
Is the plan to try and fix this for 3.3.3 or 3.4. As a XP site with 500+
machines this bug is a complete show stopper. :-(

M
Comment 39 Don't use this account, use tml@iki.fi 2011-03-23 00:52:39 UTC
Great, will have to look how they fixed it then and see if it can easily be adapted to 3.3 (as we presumably will continue releasing new 3.3.x versions once a month or so). But in any case the fix will naturally then be in our 3.4, too. We merge in OOo changes in LibreOffice in general.
Comment 40 Don't use this account, use tml@iki.fi 2011-03-23 01:58:34 UTC
*** Bug 35583 has been marked as a duplicate of this bug. ***
Comment 41 Don't use this account, use tml@iki.fi 2011-03-23 02:28:04 UTC
I see no mention in the OOo issue (http://openoffice.org/bugzilla/show_bug.cgi?id=115778 ) that it would have been fixed intentionally.
Comment 42 Don't use this account, use tml@iki.fi 2011-03-23 02:55:09 UTC
*** Bug 35583 has been marked as a duplicate of this bug. ***
Comment 43 Pål Kristiansen 2011-03-23 03:28:01 UTC
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.
Comment 44 Wilco Baan Hofman 2011-03-28 04:27:53 UTC
I'm also hitting this bug.

If this helps testing:

If you follow these steps, it will also fail:
 * create a new local account
 * Log in with the new account
 * change HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\AppData to REG_EXPAND_SZ with value C:\test-appdata (or whatever)
 * Create the folder C:\test-appdata and if necessary give permissions to the new local account
 * Log out and log in again
 * Start a command prompt and verify the content of %APPDATA% (echo %APPDATA%)
 * Start LibreOffice

This is what the group policy object changes under the hood.
Comment 45 Don't use this account, use tml@iki.fi 2011-03-28 04:41:48 UTC
Wilco, thanks a lot! I didn't try yet but your instructions sound very promising.
Comment 46 Don't use this account, use tml@iki.fi 2011-03-28 05:44:04 UTC
Wilco, using c:\test-appdata for that Registry value I had no problem starting LibreOffice.

But if I use a UNC path (in my case, \\vmware-host\Shared Folders\tmp\test-appdata) I can indeed reproduce the problem. Yay, finally!

Wilco, thanks once more. This kind of trivial way to reproduce the problem was what I was asking for already in comment #7.
Comment 47 Don't use this account, use tml@iki.fi 2011-03-28 06:47:12 UTC
Debugging this now; in case I get interrupted, here is the stack trace at an interesting spot, and some musings:

>	deploymentmi.uno.dll!dp_registry::backend::BackendDb::getDocument()  Line 95	C++
 	deploymentmi.uno.dll!dp_registry::backend::configuration::ConfigurationBackendDb::getAllDataUrls()  Line 144 + 0xf bytes	C++
 	deploymentmi.uno.dll!dp_registry::backend::configuration::`anonymous namespace'::BackendImpl::BackendImpl(const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & args=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xComponentContext={...})  Line 216 + 0x16 bytes	C++
 	deploymentmi.uno.dll!cppu::ImplInheritanceHelper1<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl,com::sun::star::lang::XServiceInfo>::ImplInheritanceHelper1<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl,com::sun::star::lang::XServiceInfo><com::sun::star::uno::Sequence<com::sun::star::uno::Any>,com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> >(const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & arg1=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & arg2={...})  Line 187 + 0x36 bytes	C++
 	deploymentmi.uno.dll!comphelper::service_decl::detail::OwnServiceImpl<cppu::ImplInheritanceHelper1<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl,com::sun::star::lang::XServiceInfo> >::OwnServiceImpl<cppu::ImplInheritanceHelper1<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl,com::sun::star::lang::XServiceInfo> >(const comphelper::service_decl::ServiceDecl & rServiceDecl={...}, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & args=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xContext={...})  Line 182 + 0x36 bytes	C++
 	deploymentmi.uno.dll!comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl>::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl>(const comphelper::service_decl::ServiceDecl & rServiceDecl={...}, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & args=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xContext={...})  Line 211 + 0x3a bytes	C++
 	deploymentmi.uno.dll!comphelper::service_decl::detail::CreateFunc<comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl>,comphelper::service_decl::detail::PostProcessDefault<comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl> >,comphelper::service_decl::with_args<1> >::operator()(const comphelper::service_decl::ServiceDecl & rServiceDecl={...}, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & args=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xContext={...})  Line 263 + 0x31 bytes	C++
 	deploymentmi.uno.dll!boost::detail::function::function_obj_invoker3<comphelper::service_decl::detail::CreateFunc<comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl>,comphelper::service_decl::detail::PostProcessDefault<comphelper::service_decl::detail::ServiceImpl<dp_registry::backend::configuration::`anonymous namespace'::BackendImpl> >,comphelper::service_decl::with_args<1> >,com::sun::star::uno::Reference<com::sun::star::uno::XInterface>,comphelper::service_decl::ServiceDecl const &,com::sun::star::uno::Sequence<com::sun::star::uno::Any> const &,com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const &>::invoke(boost::detail::function::function_buffer & function_obj_ptr={...}, const comphelper::service_decl::ServiceDecl & a0={...}, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & a1=0x00e9f408 {size=0x00000003}, const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & a2={...})  Line 131 + 0x18 bytes	C++
 	comphelp4MSC.dll!00edf63a() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for comphelp4MSC.dll]	
 	comphelp4MSC.dll!00edf6df() 	
 	cppuhelper3MSC.dll!00370c0c() 	

The m_urlDb at that top of the stack location is "file://vmware-host/Shared%20Folders/tmp/test-appdata/LibreOffice/3/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml" which IMHO is bogus. UNC paths should not be represented as file: URLs where the host part is the server name. More correct would be "file://///vmware-host/Shared%20Folders/..." IMHO. But as such, as long as the conversion from an UNC path to an URL and back results in the same UNC path as it started with, it shouldn't be a problem if the file: URL for the UNC path is bogus. But does it? Debugging...
Comment 48 Don't use this account, use tml@iki.fi 2011-03-28 07:53:35 UTC
Yeah, I am fairly sure I understand the problem now. It is basically a mismatch between how OOo/LO represents UNC paths as URLs format, and what libxml2 is prepared to handle.

The correct syntax for file: URLs on Windows is severely under-specified. Historically even for local file names various incompatible formats have been used, like Mozilla (Netscape?) at some point using | instead of :.

But by now, I think the form generally agreed upon for local file names, at least when ASCII only is involved (yeah... a big "only") is file:///x:/rest/of/path , where x: is the drive letter.

For UNC paths there is much less consensus. OOo/LO uses the form file://server/share/rest/of/path . But libxml2 does not handle that. Look at the code in xmlIO.c:xmlNoNetExists().

Now, this bug would have been *much* easier to solve if only the error handling would have been saner. In unoxml/source/dom/documenthandler.cxx:warning_func(), the nice verbose error message from libxml2 is used, we get 

libxml2 warning
failed to load external entity "file://vmware-host/Shared%20Folders/tmp/test-appdata/LibreOffice/3/user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/backenddb.xml"

And then in throwEx() in the same file we still have that message around, and it is stored in a com::sun::star::xml::sax::SAXParseException, which is thrown. 
But that exception is then caught in desktop/source/deployment/manager/dp_manager.cxx:dp_manager::PackageManagerImpl::create() with just:

    catch (Exception &) { ... }

How nice. If the actual exception object would be captured here, we would see that it contains a nice verbose message "Extension Manager: failed to read data entry in configuration backend db: file://vmware-host/Shared%20Folders/tmp/test-appdata/LibreOffice/3/user/uno_packages/cache/registry/com.sun.star.comp." Yes, the URL is truncated (!), but still, showing that to the user would have been more useful than just saying "caught unexpected exception".
Comment 49 Don't use this account, use tml@iki.fi 2011-03-29 00:46:04 UTC
This problem has been fixed in OOo 3.4 as a side-effect of them fixing their issue http://openoffice.org/bugzilla/show_bug.cgi?id=109096 , in CWS jl164. Cherry-picking just the lines that help this problem is trivial. Will commit to the libreoffice-3-3 branch after I get one approval. (We presumably don't want to cherry-pick all of that CWS to our 3.3 branch, even if it fixes other symptoms of the same basic problem, too. But so far nobody seems to have reported the other symptoms for us, so maybe they are rare.)

Patch:

--- desktop/source/deployment/registry/dp_backenddb.cxx
+++ desktop/source/deployment/registry/dp_backenddb.cxx
@@ -92,7 +92,10 @@ css::uno::Reference<css::xml::dom::XDocument> BackendDb::getDocument()
         ::osl::File::RC err = ::osl::DirectoryItem::get(m_urlDb, item);
         if (err == ::osl::File::E_None)
         {
-            m_doc = xDocBuilder->parseURI(m_urlDb);
+            ::ucbhelper::Content descContent(
+                m_urlDb, css::uno::Reference<css::ucb::XCommandEnvironment>());
+            Reference<css::io::XInputStream> xIn = descContent.openStream();
+            m_doc = xDocBuilder->parse(xIn);
         }
         else if (err == ::osl::File::E_NOENT)
         {
Comment 50 David Tardon 2011-03-29 00:52:10 UTC
+1 for 3.3 from me
Comment 51 Don't use this account, use tml@iki.fi 2011-03-31 01:02:51 UTC
Fixed now in the 3.3 branch. (In master also fixed as part of the merge of OOo DEV300 stuff.)
Comment 52 mal 2011-05-20 03:24:40 UTC
Nearly fixed. I built an XP pro SP3 machine from scratch
Installed LO 3.4 B5 syspreped the machines and imaged it.
Then downloaded the image to another machine. The first 
user ( with a redirected home / application data /etc )
to log in got the '[context=user]' error. Subsequent launches
of LO by that user worked and all other users also worked
afterwards

M