GNOME Bugzilla – Bug 668891
gnucash 2.4.9 runs only as administrator on Windows 7
Last modified: 2018-06-29 23:05:34 UTC
After installing gnucash 2.4.9 on a Windows 7 machine, the program runs only with administrator rights. The problem has been reported in a gnucash-user post [http://lists.gnucash.org/pipermail/gnucash-user/2012-January/042704.html] with subject "gnucash 2.4.9 crashes on Windows7" and has been confirmed by several correspondents on the same thread. The problem persists even if the previous installation had been uninstalled and all gnucash elements removed. Unfortunately, I am not able to provide a stack trace since this is a Windows issue, and I lack the expertise.
Dup of bug 666849 or bug 614638?
Maybe, and no. Bostjan, please check the permissions/ACL of .gnucash and .gconf* in the non-priv user's home directory. If you run Gnucash first as the admin user, will it then run from the non-priviledged account? Check the permissions/ACL first; if running as admin first allows Gnucash to run for the non-priv user, see if the permissions changed.
Never mind about the file permissions, the problem from 666849 has to do with setting up the catalog for slib. If you can run from an unpriv user after running from an admin, we can be pretty sure this is the same problem.
Hopefully, I have done what you asked me: (1) clean-installed gnucash 2.4.9 (2) examined permissions for .gconf and .gnucash ( right-click .gconf -> Properties -> Security -> Advanced There are 4 permission entries: AccountUnknown..., SYSTEM, Administrators, Bostjan (my unpriviledged account). AccountUnknown... has read and execute priviledges, others have full control ) After successfully running as Administrator, priviledges do not change, and am NOT able to run as unpriviledged user
OK, Thanks. This isn't a duplicate of 666849, then. Since it does run from the admin account, it must be a privs problem somewhere. Check the permissions of c:\Program Files\gnucash\share\guile\1.8\slibcat. On my XP Home system, it required an admin user's running Gnucash to be able to create that file, but once created an unpriv user could run... but XP Pro has a, um, richer security model, so perhaps your unpriv user can't read slibcat. If that's not it, I'm stuck.
The reporter in 668403 found a clue to his problem in the Windows "logging journal". Can you look to see if you have any errors logged there?
I looked in the event log and couldn't find anything. Likewise, I couldn't find anything wrong with c:\Program Files\gnucash\share\guile\1.8\slibcat. I added my local (unprivileged) account as user of this file with full control, but this did not resolve the problem. If the problem is one of insufficient privilege as hypothesized above there ought to be some way of finding which component of gnucash or a subordinate package accesses a file without the required privilege. At the moment I have no idea how.
There was an old problem where an unprivileged user didn't have write privs in his $HOME (which, for the record, is Documents and Settings\user). I think that you've already checked that, but it's the only other thing I can think of so early in the startup process.
This is just to notify that the problem described in this bug report persists in version 2.4.10 as well. Regards, bostjanv
Yeah, no surprise. We can't fix it until we know what's wrong. Ooh, here's another thought: Several users have reported problems with other Gtk-based packages that pollute the global path and cause dll conflicts with Gnucash. Might the paths of your unprivileged user and admin user be different?
Created attachment 207450 [details] env. vars and gnucash environment file for gnucash 2.4.8 & 2.4.10
Couldn't find anything along those lines. Am attaching a file containing my environment variables and gnucash environment file for gnucash installation 2.4.8 (which works) and 2.4.10 (which can only be used by an administratior) Regards, bostjanv
How did you install GnuCash ? Via the installer on the GnuCash website ? I notice that you have c:\Program Files\GNU\gnucash\bin in your PATH. This is certainly something the official installers don't do. Can you check where this comes from ? Perhaps gnuwin32 ?
Hi, I think I placed it in PATH myself. I didn't realize that it was not advisable. However, after your remark I removed the item from PATH, reinstalled v. 2.4.10 (I had already started using 2.4.8 again), but the result was the same; i.e., gnucash runs only when called by an administrator). Therefore, the cause must be elsewhere. Regards, bostjanv
I realized that I did not answer your first question: yes, I used the installer on the GnuCash website. bostjanv
Just for the heck of it, and to completely rule out the path being part of the problem, could you create a new user, verify that the path has only the Microsoft defaults, and try running Gnucash in that user's account?
I followed your instructions, and used gnucash in my guest account, and IT WORKED. Now I have to figure out which path components conflict with gnucash. I haven't the faintest idea. I hope you can give me some ideas. Regards, bostjanv
Anything that uses Gtk is a suspect, but another user found a conflict with Gpg, which I noticed on your list.
This is really becoming something of a mystery. I wrote a .cmd script that sets my environment variables exactly to what they are in the guest account (which permits gnucash calls), modulo such things as the difference in the user name, and then terminated the script with a cmd /K command. I then called the script, and called the gnucash-launcher script. The result was a crash! Just in case, I also called gnucash.exe directly, with the same result. So, if the environment variables have no effect on this problem, what could? Perhaps some registry elements are causing this? Regards, bostjanv
Here is an additional experiment that might throw light on the problem: I hypothesized that the mere fact of declaring an account to include administrative privileges produces the phenomenon that unprivileged calls of gnucash are impossible. Therefore, I declared a new account, and checked that I can call gnucash (2.4.10). The answer was YES. I next added administrative privileges to the account, and again checked whether I can call gnucash as an unprivileged user. The result was again YES (i.e., I am able to call gnucash from an unprivileged command line within an account that includes administrative privileges). Therefore there must be something peculiar to my account that causes the offending behavior, and furthermore, that something is not related to the values of the environment variables. The latter claim is based on the experiment in Comment 19. But here a new question arises in my mind: the experiment in Comment 19 assumes that the values of the environment variables are obtained from the calling shell (i.e. from the environment of the calling command line); however, is it possible that gnucash obtains the values of the environment variables in some other way? For example, from some global context? Regards, bostjanv
> But here a new question arises in my mind: the experiment in Comment 19 assumes > that the values of the environment variables are obtained from the calling > shell (i.e. from the environment of the calling command line); however, is it > possible that gnucash obtains the values of the environment variables in some > other way? For example, from some global context? Win32 handles environment variables differently from Unix, and Win32 shells work differently from Unix shells. What I think is going wrong for you isn't about environment variables in general, though. It's about dynamic library resolution at load time. That's independent of Gnucash's obtaining environment variables: You're apparently crashing before Gnucash begins to read the environment.
One more comment: I just discovered that apart from being able to be launched by an administrator in my installation of Windows 7, gnucash 2.4.10 also runs in XP (Service Pack 2) compatibility mode. Doesn't that somehow invalidate the designation that the installer is intended for Microsoft Windows XP/Vista/7 ? Regards, bostjanv
No, since it does run on Win7. We're building on XP, so it's not surprising that it doesn't support whatever makes it Win7 native.
The fact that gnucash is being built on XP explains why it can fail (in some ways) on Win7. However you characterise the situation, maybe it would be a good idea to warn users about possible problems (perhaps in the README.win32-bin.txt file), and instruct them to use XP (Service Pack 2) compatibility mode if they have difficulties, at least until you uncover the cause of the problem and fix it. Such a warning could save some time for people who have reported the problem and others who could encounter the problem in the future and prevent frustration over an otherwise great product.
Reopening as I don't see any open non developer question atm.
On the contrary, the user has (or had) a conflicting package that didn't do a good job of keeping to itself. Since nothing has been heard from him in 4 months, I think we can close this.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=668891. Please update any external references or bookmarks.