Disabling .NET Installer Class removes automatically injected InstallUtil actions that conflict with chained MSI execution in InstallShield 2023. This restores normal install behavior. No added actions, no rollback.
Why is my Windows Installer package rolling back after Setup Complete Success dialog?
I'm not sure if this is the correct place, but I'm having a problem with a Windows Installer package. The install seems to complete successfully as the Setup Complete dialog (again, success) is displayed. Then, the desktop shortcuts disappear and it seems something is failing that rolls things back.
I have a log, but I'm not seeing the cause of the issue.
Any help with this mystery would be greatly appreciated!
Windows for home | Windows 11 | Performance and system failures
Answer accepted by question author
5 additional answers
Sort by: Most helpful
-
April P 5,435 Reputation points Independent Advisor
2025-10-02T06:58:38.93+00:00 InstallShield 2023 adds GUID-named custom actions during compilation likely for telemetry, licensing, or runtime checks. These actions don’t appear in older versions like 2018 and can fail silently in chained installs due to context mismatches, triggering rollback. Recompiling the chained MSI with the same InstallShield version or conditioning out those actions can help resolve the issue.
-
Matt W 41 Reputation points
2025-10-02T03:47:54.35+00:00 The Execute Sequence records lead me to the cause of the issue. The .NET Installer Class setting was inadvertently set to Yes for the EntityFramework.dll component. I'm sure this occurred during recent, fairly significant changes for Core support.
That was brutal, but I'm relieved!!
-
April P 5,435 Reputation points Independent Advisor
2025-10-01T10:29:04.5833333+00:00 You’re absolutely right that moving from InstallShield 2018 to 2023 can cause subtle but important changes in how chained MSIs are executed, validated, and rolled back.
Best Practices for Handling Chained MSIs in InstallShield 2023
Prefer the Prerequisite Editor
• Instead of direct chaining, use the Redistributables view or Prerequisite Editor when possible.
• This gives you better control over sequencing and rollback in the newer InstallShield versions.
Test with IgnoreExitCode
• Temporarily configure the chained MSI to ignore return codes.
• If the parent installation succeeds, that confirms the rollback was triggered by a silent failure in the chained package.
Enable Detailed Logging
• Pass logging parameters to the chained MSI so you can capture errors inside it.
• This makes it easier to isolate the exact cause of the failure.
Watch for UI Conflicts
• If the chained MSI displays its own UI, it may clash with the parent installer.
• Configure it for silent execution (/qn) or basic UI (/qb) to prevent interference.
Run ICE Validation
• Validate both installers with ICE tools (Orca or InstallShield’s built-in validators).
• Pay special attention to ICE33, ICE57, and ICE71, as these often reveal sequencing or rollback risks.
-
April P 5,435 Reputation points Independent Advisor
2025-09-30T05:44:32.9733333+00:00 Hi Matt,
This is April, I'll be happy to assist you. Sorry to hear that you're having issue with Windows Installer. Let me help you out.
Based on the description you provided, the Windows Installer shows a successful setup dialog, but then unexpectedly rolls back the installation, removing shortcuts and undoing changes likely due to a hidden failure during the final commit or a custom action.
Even if Windows Installer shows a "success" dialog, a rollback may still occur if issues are detected during the commit phase or deferred custom actions. Silent failures, non-zero exit codes, or actions scheduled after InstallFinalize can trigger rollback. One clear sign is the removal or shortcuts created during the install, which confirms rollback rather than normal cleanup.
Here's how to Fix or Investigate the issue further:
- Enable Verbose Logging
- If not already enabled, use: msiexec /i yourpackage.msi /L*v install.log
- This gives full detailed including property values and custom action output.
- Review Custom Action Setup
- Inspect the CustomAction table in the MSI.
- Confirm actions are assigned the correct type (immediate, deferred, rollback, commit , etc.).
- For scripts or executables, verify they return the correct exit codes.
- Examine with Orca or InstEd
- Open the MSI in Orca or InstED and check the sequence tables (InstallExecuteSequence, InstallUISequence, etc.).
- Pay special attention to actions that run after InstallFinalize.
- Test Without Custom Actions
- Build a simplified MSI without custom actions to confirm whether they're the source of the rollback.
Let me know the result. If you need further assistance you can reply to this message. We’re here to help, and we appreciate your continued trust in us.
Thank you,
April P.
Independent Advisor
- Enable Verbose Logging