Repackaging causing a Windows to reconfigure app at Restart
Hi Folks, I need a tip.
I have a small application called Autobahn toolbar (a financial app), its in an *.exe format. I am trying to repackage it into a *.msi as per our corporate policy. The only change I make is I am changing the installdir from APPDATA in the user profile to C:\program files (x86).
The problem I have is after the repackaged msi is installed and the PC is restarted I get a windows installer message saying "Windows is configuring Autobahn". It does not do this with the *.exe obviously
The problem is that it is doing so at EVERY PC RESTART (take about 5-10 seconds to complete). The repackaged app works, but these setup messages are a nuisance.
Got a clue?
I just realized that the app is autostarting after login so I am checking this out.
0 Comments
[ + ] Show comments
Answers (8)
Please log in to answer
Posted by:
jagadeish
10 years ago
This could be because of the followings
1. You might have included any temporary files with keypath in the msi package. Exclude the unnecessary registry/files from the msi package
2. Permission issue, Use ProcMon to identify the registry/file/folder permission issue.
Posted by:
EdT
10 years ago
Specifying no shortcuts does not mean you are going to avoid the auto repair scenario as there are five different triggers for auto repair, at least in the MSI world. The fact that your installation is an EXE does not preclude it being a humble wrapper for an MSI stored internally. MSI installers are cached in the c:\windows\installer hidden folder so that is one absolute way to check whether there is an MSI at the root of all this. The other way is to open task manager and watch the install to see if there are multiple instances of the msiexec.exe app running during the install. You will typically see three instances while an MSI is installing.
As for using the default installation path - consider that the native installer is installing correctly for any user, so a capture has to be capable of being configured to do the same. Rather than having the user path hard coded, you can use environment variables such as USERPROFILE or APPDATA which are automagically set to the correct path.
Posted by:
dedenker
10 years ago
Of course first check the auto start, ether in RUN or RUNONCE in registry.
But I expect the application wants to apply something to the user space registry.
Perhaps you apply this from the MSI, Monitor what the application does
But I expect the application wants to apply something to the user space registry.
Perhaps you apply this from the MSI, Monitor what the application does
Posted by:
anonymous_9363
10 years ago
Easy.
You have a component in the MSI which contains both user and machine-level items. Since the user won't have permission to write the machine-level stuff, WI will attempt to repair its containing feature every time the app is started.
Separate them out. It's usually registry stuff so dragging the component into a new user-level feature will be straightforward.
You have a component in the MSI which contains both user and machine-level items. Since the user won't have permission to write the machine-level stuff, WI will attempt to repair its containing feature every time the app is started.
Separate them out. It's usually registry stuff so dragging the component into a new user-level feature will be straightforward.
Posted by:
EdT
10 years ago
It is inevitably a permissions issue. The APPDATA area in the user profile has full rights for the user. By moving the install to Program Files (x86), you are moving the install to a read-only area. This may well break the app depending on whether it uses the installation folder for working files. As a test, change the install folder back to appdata on your MSI and see if it starts working. If it does, you will know that you need to change permissions on the installation folder to full read-write. This may be against your corporate standards of course, but that's another battle.
Finally, consider downloading the Application Compatibility Toolkit from Microsoft. This includes a tool that analyses the accesses that an app makes as it runs and gives you a report of what access a user needs.
Posted by:
mmarsh
10 years ago
Hi again
Thanks for the help, not quite there yet but I have made progress.
Yes you are right its a permissions issue, and I have narrowed it down a bit further.
First of all the "Windows is configuring AutoBahn" on startup was due to me forgetting to delete the shortcut in the windows startup folder. Once I figured that out I made a bigger discover the "Windows is configring Autobahn" message ONLY happens when launched from shortcuts in the START MENU. If I launch the *.exe directly from the Install Directory the application launches immediately with no issues.
Never seen this behavior before, What should I be doing to fix this?
Posted by:
EdT
10 years ago
Autobahn is clearly an MSI based install, and you are experiencing normal MSI self healing behaviour whenever a shortcut is activated, regardless of whether it is in the startup folder or in the start menu. The cause of the self healing is a missing key path - for example a missing file or registry key (user registry keys are the most common cause). Advertised shortcuts such as your app has installed into the startup and start menu folders, cause windows installer to perform a check of the key paths in the entire installation, and if any are missing, a repair of the affected feature is triggered. Unless the user has adequate permissions to complete the repair of the entire feature, the self healing operation will bomb and will then be repeated whenever the app is started through any advertised entry point, such as a shortcut or file association.
The application event log will carry a record of which key path(s) were detected as missing, including a note of the component GUID that holds the resource(s) determined to be missing.
Any experienced application packager can locate the issue and find a workaround but if you don't have the necessary experience on tap, I would strongly recommend sticking to the default install location.
Posted by:
mmarsh
10 years ago
Its not an MSI, its a *.EXE that was created with Flexera INSTALLANYWHERE. I am not familiar with Installanywhere it appears to be an *.exe that acts like a *.msi, the problem is it cannot be modified using Installshield or any other tool I have. We don't use this software.
Nor can I use the default install path because that happens to be the user profile. When I repackage the *.exe its capturing MY profile, which of course works for me, but the moment anyone else logs in with a user account other than my own it will not work (as they lack the permisions to access my user account. This is why I wanted to install it to C:\program files (x86) to circumvent this little problem.
I tried declaring the shortcuts as non-advertised, but the auto-repair in still engaging itself. I am going to try the capture again and specify no shortcuts during the install on the start menu and try and recreate them manually.