This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Installation issues with InstallShield 2008 under Windows XP
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 04, 2010
04:48 PM
Installation issues with InstallShield 2008 under Windows XP
We have the following installation problem under Windows XP SP 3 using InstallShield 2008 Professional Edition Version 14.
1. A user is logged in on the target machine as a user without administrative rights, a member of the Users group.
2. The user has opened a session with the website and a self-registering component is in use.
3. The installation is started from a self-extracting installer using "Run as" with administrator credentials.
4. The installation finishes with the prompt that the machine must be rebooted.
5. The machine reboots.
6. As a result the access rights to the self-registering component for the Users group members is lost.
7. The component cannot be instantiated if you belong to the Users group.
8. The component is properly instantiated by the members of the Administrators group.
Is there a way to monitor what happens after the reboot because the access rights are still there before the reboot?
Any ideas how to overcome this situation?
1. A user is logged in on the target machine as a user without administrative rights, a member of the Users group.
2. The user has opened a session with the website and a self-registering component is in use.
3. The installation is started from a self-extracting installer using "Run as" with administrator credentials.
4. The installation finishes with the prompt that the machine must be rebooted.
5. The machine reboots.
6. As a result the access rights to the self-registering component for the Users group members is lost.
7. The component cannot be instantiated if you belong to the Users group.
8. The component is properly instantiated by the members of the Administrators group.
Is there a way to monitor what happens after the reboot because the access rights are still there before the reboot?
Any ideas how to overcome this situation?
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 08, 2010
10:17 AM
I used the sysinternals tools PendMoves and AccessChk to diagnose the issue.
PendMoves reports 3 objects including the one in question - dll3.dll to rename after reboot.
Source: c:\Program Files\..\dll1f0g.rra
Target: c:\Program Files\..\dll1.dll
Source: c:\Program Files\..\dll2h3t.rra
Target: c:\Program Files\..\dll2.dll
Source: c:\Program Files\..\dll3u6g.rra
Target: c:\Program Files\..\dll3.dll
running accesschk against dll1f0g.rra and dll2h3t.rra for "users" returns R, i.e. members of "users" have Read privileges.
running accesschk against dll3u6g.rra for "users" returns
No security Information available for c:\Program Files\..\dll3u6g.rra
No matching objects found.
running accesschk against dll3u6g.rra for "administrators" returns RW, i.e. read/write privileges.
How could the privileges been revoked for the dll3u6g.rra file and subsequently for dll3.dll for the "users" group?
PendMoves reports 3 objects including the one in question - dll3.dll to rename after reboot.
Source: c:\Program Files\..\dll1f0g.rra
Target: c:\Program Files\..\dll1.dll
Source: c:\Program Files\..\dll2h3t.rra
Target: c:\Program Files\..\dll2.dll
Source: c:\Program Files\..\dll3u6g.rra
Target: c:\Program Files\..\dll3.dll
running accesschk against dll1f0g.rra and dll2h3t.rra for "users" returns R, i.e. members of "users" have Read privileges.
running accesschk against dll3u6g.rra for "users" returns
No security Information available for c:\Program Files\..\dll3u6g.rra
No matching objects found.
running accesschk against dll3u6g.rra for "administrators" returns RW, i.e. read/write privileges.
How could the privileges been revoked for the dll3u6g.rra file and subsequently for dll3.dll for the "users" group?
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)