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
- :
- Chained install performing rollback - returning 3010.
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
‎May 30, 2011
04:55 PM
Chained install performing rollback - returning 3010.
We have a chained install that has a bunch of products chained in it and during our testing we are testing upgrade senerios where we have the previous version of these apps installed on the machine, They were installed individually and not though a chained install.
Anyways the install is just about done, only one product left to install and it then does a rollback. Now it does mention the return of 3010 - a reboot is required, but this should NOT be triggering a rollback would it? That would be bad. Here is that portion of the log:
MSI (s) (D4:C0) [15:01:12:191]: Product: SMART Notebook -- Installation operation completed successfully.
MSI (s) (D4:C0) [15:01:12:191]: Windows Installer installed the product. Product Name: SMART Notebook. Product Version: 10.8.356.0. Product Language: 1033. Manufacturer: SMART Technologies ULC. Installation success or error status: 0.
MSI (s) (D4:C0) [15:01:12:191]: Value of RebootAction property is
MSI (s) (D4:C0) [15:01:12:191]: Windows Installer requires a system restart. Product Name: SMART Notebook. Product Version: 10.8.356.0. Product Language: 1033. Manufacturer: SMART Technologies ULC. Type of System Restart: 2. Reason for Restart: 0.
MSI (s) (D4:C0) [15:01:12:191]: Product: SMART Notebook. Restart required. The installation or update for the product required a restart for all changes to take effect. The restart was deferred to a later time.
MSI (s) (D4:C0) [15:01:12:191]: Attempting to delete file C:\Windows\Installer\5e15c8.mst
MSI (s) (D4:C0) [15:01:12:191]: Unable to delete the file. LastError = 32
MSI (s) (D4:C0) [15:01:12:222]: Deferring clean up of packages/files, if any exist
MSI (s) (D4:C0) [15:01:12:222]: Attempting to delete file C:\Windows\Installer\5e15c8.mst
MSI (s) (D4:C0) [15:01:12:222]: MainEngineThread is returning 3010
MSI (s) (D4:A8) [15:01:12:253]: RESTART MANAGER: Session closed.
MSI (s) (D4:A8) [15:01:12:269]: RESTART MANAGER: Session closed.
=== Logging stopped: 5/30/2011 15:01:12 ===
MSI (c) (D0:34) [15:01:12:269]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (D0:34) [15:01:12:269]: MainEngineThread is returning 3010
=== Verbose logging stopped: 5/30/2011 15:01:12 ===
MSI (s) (D4:A8) [15:01:12:332]: User policy value 'DisableRollback' is 0
MSI (s) (D4:A8) [15:01:12:332]: Machine policy value 'DisableRollback' is 0
MSI (s) (D4:A8) [15:01:12:332]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (D4:A8) [15:01:12:347]: Executing op: Header(Signature=1397708873,Version=500,Timestamp=1052669818,LangId=0,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
MSI (s) (D4:A8) [15:01:12:347]: Executing op: DialogInfo(Type=0,Argument=0)
MSI (s) (D4:A8) [15:01:12:347]: Executing op: DialogInfo(Type=1,Argument=SMART Notebook)
MSI (s) (D4:A8) [15:01:12:347]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
MSI (s) (D4:A8) [15:01:12:347]: Executing op: RegisterBackupFile(File=C:\Config.Msi\5e20e5.rbf)
Is there any indication here as to what is cauing the rollback that I just can not see?
Any help would be appreciated.
Anyways the install is just about done, only one product left to install and it then does a rollback. Now it does mention the return of 3010 - a reboot is required, but this should NOT be triggering a rollback would it? That would be bad. Here is that portion of the log:
MSI (s) (D4:C0) [15:01:12:191]: Product: SMART Notebook -- Installation operation completed successfully.
MSI (s) (D4:C0) [15:01:12:191]: Windows Installer installed the product. Product Name: SMART Notebook. Product Version: 10.8.356.0. Product Language: 1033. Manufacturer: SMART Technologies ULC. Installation success or error status: 0.
MSI (s) (D4:C0) [15:01:12:191]: Value of RebootAction property is
MSI (s) (D4:C0) [15:01:12:191]: Windows Installer requires a system restart. Product Name: SMART Notebook. Product Version: 10.8.356.0. Product Language: 1033. Manufacturer: SMART Technologies ULC. Type of System Restart: 2. Reason for Restart: 0.
MSI (s) (D4:C0) [15:01:12:191]: Product: SMART Notebook. Restart required. The installation or update for the product required a restart for all changes to take effect. The restart was deferred to a later time.
MSI (s) (D4:C0) [15:01:12:191]: Attempting to delete file C:\Windows\Installer\5e15c8.mst
MSI (s) (D4:C0) [15:01:12:191]: Unable to delete the file. LastError = 32
MSI (s) (D4:C0) [15:01:12:222]: Deferring clean up of packages/files, if any exist
MSI (s) (D4:C0) [15:01:12:222]: Attempting to delete file C:\Windows\Installer\5e15c8.mst
MSI (s) (D4:C0) [15:01:12:222]: MainEngineThread is returning 3010
MSI (s) (D4:A8) [15:01:12:253]: RESTART MANAGER: Session closed.
MSI (s) (D4:A8) [15:01:12:269]: RESTART MANAGER: Session closed.
=== Logging stopped: 5/30/2011 15:01:12 ===
MSI (c) (D0:34) [15:01:12:269]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (D0:34) [15:01:12:269]: MainEngineThread is returning 3010
=== Verbose logging stopped: 5/30/2011 15:01:12 ===
MSI (s) (D4:A8) [15:01:12:332]: User policy value 'DisableRollback' is 0
MSI (s) (D4:A8) [15:01:12:332]: Machine policy value 'DisableRollback' is 0
MSI (s) (D4:A8) [15:01:12:332]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (D4:A8) [15:01:12:347]: Executing op: Header(Signature=1397708873,Version=500,Timestamp=1052669818,LangId=0,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
MSI (s) (D4:A8) [15:01:12:347]: Executing op: DialogInfo(Type=0,Argument=0)
MSI (s) (D4:A8) [15:01:12:347]: Executing op: DialogInfo(Type=1,Argument=SMART Notebook)
MSI (s) (D4:A8) [15:01:12:347]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1])
MSI (s) (D4:A8) [15:01:12:347]: Executing op: RegisterBackupFile(File=C:\Config.Msi\5e20e5.rbf)
Is there any indication here as to what is cauing the rollback that I just can not see?
Any help would be appreciated.
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 21, 2011
01:10 PM
I am doing the same sort of thing with chained msi's. Although on the I am getting a file in use error:
Product: CSS Omgeo Alert STP - Client. The file C:\Program Files\CSS\InvestorView\Assemblies\CSS.Business.DataServices.dll is being used by the following process: Name: msiexec , Id 2568.
Is there a way to turn off reboot requests with chained msi's?
Product: CSS Omgeo Alert STP - Client. The file C:\Program Files\CSS\InvestorView\Assemblies\CSS.Business.DataServices.dll is being used by the following process: Name: msiexec , Id 2568.
Is there a way to turn off reboot requests with chained msi's?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 28, 2011
10:19 AM
Were you ever able to get this issue resolved? I am running into the same problem and have not been able to figure out how to get my installation to continue when one of my chained MSIs returns a 3010. I have tried passing REBOOT=ReallySuppress to the MSI but the result is the same.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 04, 2012
04:20 PM
REBOOT=ReallySuppress only prevents a reboot prompt from appearing with full UI or a reboot from occurring on silent installs. Return status 3010 is a success status that indicates a reboot is still required (http://msdn.microsoft.com/en-us/library/windows/desktop/ms681386(v=vs.85).aspx). Embedded chained installs don't really play nice with such a scenario and there aren't really many ways around the behavior except for using the non-embedded chaining support in an external bootstrapper.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 12, 2012
08:48 AM
Yeah, we have not resolved this as like joshstechnij states, Chaining does not play nice with the 3010 return....
So all we have done is created a KB article for our users that run into this issue. We do not see it that often, but we know of some of our older software installers that returned 3010 and therefore we just ask the users to uninstall those versions before installing our Chain.
Hopefully this is fixed in future releases...
So all we have done is created a KB article for our users that run into this issue. We do not see it that often, but we know of some of our older software installers that returned 3010 and therefore we just ask the users to uninstall those versions before installing our Chain.
Hopefully this is fixed in future releases...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 16, 2012
04:58 AM
Hello Tim,
you state that "Chaining does not play nice with the 3010 return".
I thin that is understatement. Chaining considers everything differnt from 1601 an error and rolls back the chain without even writign the reason into the log file.
I think this is a rather nasty bug...
Is any fix in sight?
Best regards
Matthias
you state that "Chaining does not play nice with the 3010 return".
I thin that is understatement. Chaining considers everything differnt from 1601 an error and rolls back the chain without even writign the reason into the log file.
I think this is a rather nasty bug...
Is any fix in sight?
Best regards
Matthias