9 replies to this topic

[nkm]

Hi,

 

We recently rewrote the installation for our Software product using Installshield 2013 after years of using Wise. The installation works fine on a Windows 7 or Windows 8 and even Windows Server 2012 with a single user. However, with two or more users running our software at the same time, the users are getting "Please wait while Windows configure..." all the time. The Event Log shows the message:

 

"Detection of product '{GUID}', feature 'featurename, component '{componentID}' failed. The resource 'c:\Users\username\AppData\Roaming\OurCompanyName\' does not exist."

The directory does, however, exist and it's in the CreateDirectory Table. The old Wise-installation does not have this issue.

 

Does anyone have a clue what's going on here or what we could to do to find out more?

 

Any help is greatly appreciated!

 

Regards,

Morten

[Stefan Krueger]

Since it's a user specific directory, maybe it doen't exist for some users? Or it's a permission problem, i.e. it exists but user can't access it.

 

You could run Process Monitor from SysInternals to log activity and results such as access denied.

[Glytzhkof]

I have seen this before: it is the username that gets resolved during the installation and set in stone for all users, and the other users do not have access to the folder leaving the key path missing and inaccessible for writing:

 

Key path for Glytzhkof: 'c:\Users\Glytzhkof\AppData\Roaming\OurCompanyName\

Key path for Stefan: 'c:\Users\Glytzhkof\Roaming\OurCompanyName\

 

Set a HKCU key path for the component, and it should repair once per user. Or better yet eliminate the installation of per user files and generate them via the application executable or copy them from read only copies of the files in %PROGRAMFILES%. See this discussion: http://forum.install...showtopic=21552

 

Also check Stefan's MSI FAQ on the subject of repetitive self-repairs: http://www.installsi...ifaq/a/1037.htm

Edited by Glytzhkof, 01 April 2014 - 19:25.
Clarification

[nkm]

Thank you both for useful suggestions!

I am running this on a test server, where I control all users: user1, user2, user3.

If I run the software one user at a time, it's repaired the first time in order to copy a few files to the users profile. The next time, no repair happens, so everything works great.

 

However if I run the software for all the users at the same time, repairs starts to happen over and over. Studying the event log in detail I now see that the software starts reparing for user1 because it can't find/access the user2 profile etc. Like this:

 

User according to the Event log: user1, (Event ID: 1004)

"Detection of product '{GUID}', feature 'featurename, component '{componentID}' failed. The resource 

 'c:\Users\user2\AppData\Roaming\OurCompanyName\' does not exist."

 

User according to the Event log: user2, (Event ID: 1004)

"Detection of product '{GUID}', feature 'featurename, component '{componentID}' failed. The resource 

'c:\Users\user3\AppData\Roaming\OurCompanyName\' does not exist."

 

etc.

 

Of course it can't and shouldn't access other users profiles, but what could be wrong in the Installshieldproject in order for this to happen?

The directory under the userprofile does only contain some configuration files, no dlls etc. In the Component table the KeyPath is empty which should imply that the value given in Directory_ should be used.

The Event ID: 1001 refers to various dll's (COM) that requires access to files in the users profile.
 

Regards

Morten

[Glytzhkof]

A few comments on what you write:

• The solution to the problem you are seeing was specified in my previous answer: Set a HKCU key path for the component, and it should repair once per user.
• I would never have COM files depend on userprofile files! Very deployment smelly - is there another way? What files are these?
• A better way to deal with userprofile files is to install them to your main application folder and have your application copy them to the userprofile on launch. This avoids the whole self-repair issue.

A HKCU absolute path is the same for all users, but the value content varies. Each user has their own copy of the value and can set different values as applications operate. In your case all you need is a key path with the same value though:

• User 1: HKCU\Software\Application\Version\MyKeyPath - Value1 = 1
• User 2: HKCU\Software\Application\Version\MyKeyPath - Value1 = 1

 

A userprofile folder absolute path is different for every user, and the content can differ. Here MSI self repair run into permission problems:

• C:\Users\User1\Application
• C:\Users\User2\Application

A HKCU key path works because its path is the same for all users but the content is different and every user will have write access to their own value. This means self repair will run, but only once.

Edited by Glytzhkof, 02 April 2014 - 19:37.

[nkm]

Thanks for your comments!

 

I've now set a HKCU key path for the component:

- In the Registry table I created a new row (named UPRegistry), gave it the correct Key, Name and Value. In the Component-column I assigned it to the component (named UPFiles) that writes files to the userprofile.

- In the Component table, for the row UPFiles, I changed the attribute to 4 and set the KeyPath to UPRegistry.

 

It still compiles and passes the MSI-validation, but the behavior is unchanged. Only one repair is needed when the software is run by one user at a time. While two or more users running the software at the same time makes MSI trying to chain-repair. As before the Event Log shows that this happens because the users tries to access each others profiles.
 

In the Wise-installation we didn't handle this in any particular way. It just worked out of the box. Up to now the transistion to Installshield has been going fairly well and I am still hoping the repair problems are due to some minor error in the installation.

 

Our software is module based and communicates for a large part through a COM-interface. We've had no problems using the userprofile in the software during it's 15 years history, so I doubt that could be the problem. Having the application copy the files to the user profiles seems like a good idea and will look further into that.

 

Regards,

Morten

[Glytzhkof]

You must not have set the key-path properly. Did you add the HKCU to the same component(s) that caused the self repair? It must be set in the same component or it will have no effect. There could also be problems with the installation directory set for the file. It must point to a generic location such as: [LocalAppDataFolder]\YourApp\File.txt or [AppDataFolder]\YourApp\File.txt. Non-roaming and roaming userprofile folders respectively. See more details here: http://msdn.microsof...7(v=vs.85).aspx

 

Wise handles these automatic folder target resolution slightly better than Installshield I think. And it is possible that Wise has done something automagic to prevent the self-repair problem from occurring.

 

You will also need to delete the HKCU value in the registry to trigger a new self-repair for every user where it has already run once. A trick to make the value a moving target that is set once for every install is to set the value equal to the value of the installer version, but I wouldn't do that until the overall self-repair issue is solved:

HKCU\Software\Application\Version\MyKeyPath - Value1 = [ProductVersion]

 

Be aware that self-repair is a worse idea to depend on for every year. For every new version of Windows some new obstacles are put in place for solutions that worked before. For example: normal users accessing client sessions on terminal servers using remote desktop can face situations where self-repair is forbidden altogether. There is no way you can guarantee that customers won't use this setup for their network.

 

This is one of the reasons why I consistently propose to use the application executable itself to copy user- profile files in place. The executable is always running in the right context to determine what rights the user can assume for the application to operate - and locking down the user-profile has so far not happened by default from Windows. And when you are dealing with an executable it is easier to "make it smarter" and investigate its running environment and make it degrade gracefully - with some rational message to the user telling them what is wrong. That makes support a lot easier. Otherwise you get customers faced with software that doesn't run at all. As I like to put it: the most expensive mistake to make in software development since the setup is the customers first encounter with the quality of your product.

Edited by Glytzhkof, 03 April 2014 - 10:44.

[nkm]

A few comments on what you write:

• The solution to the problem you are seeing was specified in my previous answer: Set a HKCU key path for the component, and it should repair once per user.
• I would never have COM files depend on userprofile files! Very deployment smelly - is there another way? What files are these?
• A better way to deal with userprofile files is to install them to your main application folder and have your application copy them to the userprofile on launch. This avoids the whole self-repair issue.

 

 

We followed your advice and are now letting the application copy the files to the userprofile. It seems to work very well in tests and hopefully will too when our customers get the next software release in a few months. Thank you for your help!

[Glytzhkof]

That's great to hear. Often it is enough to just copy the files from your per-machine installation folder once to get the userprofile set up. Other times you may need to patch the userprofile files or remove some of them because they are outdated, faulty or otherwise problematic. Then the approach discussed in this thread may be helpful: http://forum.install...showtopic=21552.

 

I think you are already doing the above, I just add the link for reference for others.

Edited by Glytzhkof, 31 August 2014 - 06:34.

[Glytzhkof]

For those who are looking for reasons why msiexec.exe kicks of self-repair for other reasons, please check this long reference article for possible causes: How can I determine what causes repeated Windows Installer self-repair?