Help → Installer crashes when installing on Windows Vista Ultimate (64 bit version)
Hi,
A user has reported that the Windows installer (v1.1.1) crashes when installing POPFile on Windows Vista Ultimate SP2 (64 bit version).
He says that the previous version (v1.1.0) does not have this problem.
The crash occurs when the installer shows "Please be patient. This may take a few seconds..." message after the "Display POPFile Release Notes ?" dialog.
The original report is here (written in Japanese):
http://getpopfile.org/discussion/4/238#1045
Brian, do you have any ideas? If you need further information, please ask me.
Naoki
-
Message #1049
The crash occurs when the installer shows "Please be patient. This may take a few seconds..." message after the "Display POPFile Release Notes ?" dialog.
A lot of changes went into the installer for the 1.1.1 release. One of these changes occurs at the point where the crash occurs.
After the "Please be patient" banner appears the v1.1.1 installer creates a temporary file in the "All Users" Application Data folder and then changes the access permissions on this temporary file so that the two installer processes can write to the temporary file.
Some data is supposed to be written into this file immediately after it is created.
I will see if I can recreate the problem on the 64-bit version of Windows 7 RC.
If I cannot, then I can make a small test installer which can be used to confirm that this is the code that is causing the problem.
Brian
brian10/19/09 14:40:52 -
-
Message #1051
Hi,
Some data is supposed to be written into this file immediately after it is created.
Then, is it worth to check the content of the temporary file?
I will see if I can recreate the problem on the 64-bit version of Windows 7 RC.
I'm sorry that I can't test because I didn't download the 64-bit version.
If I cannot, then I can make a small test installer which can be used to confirm that this is the code that is causing the problem.
OK. I'll ask the reporter to try the test installer when it is available.
Naoki
amatubu10/19/09 16:12:41 -
Message #1052
I will see if I can recreate the problem on the 64-bit version of Windows 7 RC.
I had no trouble when I tried to update from POPFile 1.1.0 to 1.1.1 on my 64-bit version of Windows 7 RC.
The 1.1.1 installer created a temporary file in the C:\ProgramData folder and was able to write to this file. The file had a "random" name which started with "ns" and ended in ".tmp" (nsi8A47.tmp). This file was a simple text file containing some information about the POPFile installation:
[POPFile] Installer=1.1.1 StartTime=19-Oct-2009 @ 14:01:58 [Elevated] UserName=Supervisor (Admin) [RealUser] UserName=Brian (User) POPFILE_ROOT=C:\PROGRA~2\POPFile RootDir_LFN=C:\Program Files (x86)\POPFile RootDir_SFN=C:\PROGRA~2\POPFile POPFile=found IMAP=missing NNTP=missing SMTP=missing Socks=missing SSL=missing XMLRPC=missing popfile.cfg=found Parser=kakasi
This file was created by the "Administrator" account and the "Security" tab in the file's "Properties" showed that "Users" had been given "Write" permission for this file. The file was deleted when the installer finished.
Since the 1.1.1 installer has been crashing, the user who reported the problem should be able to find several of these temporary files in the C:\ProgramData folder (I think these files will have names which start with "ns" and end in ".tmp"). It would help if the user could report whether or not there is any data in these files and whether or not ordinary users had been granted write permission for these files.
Brian
brian10/19/09 16:12:54 -
-
Message #1055
Hi,
I had no trouble when I tried to update from POPFile 1.1.0 to 1.1.1 on my 64-bit version of Windows 7 RC.
Hmm... this is a problem specific to Windows Vista 64-bit?
Since the 1.1.1 installer has been crashing, the user who reported the problem should be able to find several of these temporary files in the C:\ProgramData folder (I think these files will have names which start with "ns" and end in ".tmp"). It would help if the user could report whether or not there is any data in these files and whether or not ordinary users had been granted write permission for these files.
OK. I'll ask him to check the temporary files.
Naoki
amatubu10/19/09 16:25:32 -
-
Message #1056
Hmm... this is a problem specific to Windows Vista 64-bit?
It is probably too early to tell yet. The problem might be related to UAC.
Brian
brian10/19/09 16:28:33 -
Message #1061
Hi,
OK. I'll ask him to check the temporary files.
First, the reporter has reported that POPFile v1.1.1 installer did not crash after changing the permission of "C:\ProgramData" folder.
For his C:\ProgramData folder, Users had had the "Read, write and execute" permissions. And adding "Modify" permission to the folder has solved the problem.
It seems that the cause is the wrong permission to the folder.
But it's strange that after removing "Modify" permission, the installer still works.
And he also said that the problem does not occur on clean installation of Windows Vista 64-bit.
BTW, he said several temporary files exist in C:\ProgramData folder and their size are all 0 bytes. Users have "Read, write and execute" permissions to them.
I hope this report will help you.
Naoki
amatubu10/20/09 13:26:27 -
-
Message #1062
If the temporary files are empty (size 0 bytes) and Users have Read, Write and Execute permissions then it looks like the crash happened immediately after the permissions were changed.
The 1.1.1 installer will show some kind of UAC prompt because it needs to modify things that require Administrator privileges. After this the installer does some things as an Administrator and some as the user who started the installer. It will be easier to explain things if I assume a standard account (User) was used to start the installer.
A temporary file is created in the "C:\ProgramData" folder using the Administrator account (so this file belongs to an administrator).
After this empty file is created the Administrator part of the installer changes the permissions for this temporary file to enable standard users to write to this file.
After the permissions have been changed the Administrator part of the installer writes some data to the temporary file.
Then the User part of the installer adds more information to the temporary file. This is why the permissions had to be changed (otherwise Users only have read and execute permissions for this file).
The relevant code can be examined here (this is a long page so it may take a while for it load).
At the moment I don't know what went wrong. I have not looked at the permissions for the "C:\ProgramData" folder on my Windows 7 RC (64-bit) or Vista (32-bit) systems. I will need to see if I can re-create the problem by changing these permissions.
Obviously it would have been better if the Administrator part of the installer created the file then wrote some data to it before it changed the permissions to allow standard Users to write to the file. I'll change the installer to do this for the next release.
Brian
brian10/20/09 14:25:34 -
-
Message #1069
Hi,
Obviously it would have been better if the Administrator part of the installer created the file then wrote some data to it before it changed the permissions to allow standard Users to write to the file. I'll change the installer to do this for the next release.
I think that is a good idea.
And, I've found a page describes the error handling:
http://nsis.sourceforge.net/Talk:AccessControl_plug-in
I don't know if this is related to the problem, but it's a good idea to add an error handling routine.
Naoki
amatubu10/24/09 05:18:10 -
-
Message #1073
I think that is a good idea.
changeset:3637 was my first attempt at fixing this ... but I forgot to check the rest of the code (the uninstaller will need a similar fix)
I've found a page describes the error handling
Thanks for the link, Naoki. The plugin's documentation does not say much but I missed the part where it says "Error messages are now just returned on NSIS stack."
A quick check of the plugin's source code reveals that it can return a wide range of error messages. These messages will be a great help in diagnosing problems so the installer should display them.
The link you supplied suggests that the plugin only returns a single error message on the stack but I have found that it can return several strings on the stack. I'll update the installer and uninstaller to display them all.
Brian
brian10/24/09 14:51:04 -
-
Message #1074
I'll update the installer and uninstaller to display them all.
changeset:3641 implements these changes. The error message(s) are also stored in the temporary file.
Brian
brian10/24/09 19:51:18 -
-
Message #1081
Hi Brian,
changeset:3641 implements these changes. The error message(s) are also stored in the temporary file.
Looks good for me. Thanks.
Naoki
amatubu10/28/09 17:25:45
-
-
-
-
-
-
-
-
