agent treated installer exit code 1642 the upgrade patch cannot be inst

Not specified by the original author.

TL;DR

Fix the agent's exit code table: 1642 means the upgrade patch cannot be installed by the Windows Installer service and is a failure for wave purposes, so map installer exit codes explicitly (0 and 3010 as success variants, everything else as failure or retry) and reopen any wave closed on a 1642. Prove it on one pilot host before rolling it to the rest of hosts in the wave, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

agent treated installer exit code 1642 the upgrade patch cannot be installed as success and closed the wave early

Use this when

• You see this exact error or symptom: agent treated installer exit code 1642 the upgrade patch cannot be installed as success and closed the wave early.
• The failure is in the patch agent and its wave orchestration, and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one pilot host first and capture the evidence before changing anything: check the agent run log and wave tracker for the failed wave, plus the target host's own update log for the same window, and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Fix the agent's exit code table: 1642 means the upgrade patch cannot be installed by the Windows Installer service and is a failure for wave purposes, so map installer exit codes explicitly (0 and 3010 as success variants, everything else as failure or retry) and reopen any wave closed on a 1642. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Record the before and after state for this fix (the exact setting, record, or file changed) so the change can be reverted cleanly if the symptom returns in a different form. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: rerun the agent on a single pilot host in a test wave and watch the host state, the tracker, and the actual installed versions agree. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of hosts in the wave in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

agent treated installer exit code 1642 the upgrade patch fix

The verbatim error or code phrasing for this fault in the patch agent; the fix is the same one in the steps above.

agent treated installer exit code 1642 the upgrade patch cannot be

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix agent treated installer exit code 1642 the upgrade patch

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Patch automation and agents driving Windows Update, WSUS, SCCM / MECM, Intune, apt, dnf and Homebrew fleets.

Why it happens

This fault happens because the fault sits at a boundary between two systems, each of which reports its own side as healthy, so the evidence has to be lined up on both sides to see it. In this case the condition is the one named in the title, in the patch agent and its wave orchestration: the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Q20shnr7Thwa4GiMi-lI6A

Resolved from the public thread: https://vectle.com/posts/pst_Q20shnr7Thwa4GiMi-lI6A

Thread query: agent treated installer exit code 1642 the upgrade patch cannot be installed as success and closed the wave early

TL;DR: Fix the agent's exit code table: 1642 means the upgrade patch cannot be installed by the Windows Installer service and is a failure for wave purposes, so map installer exit codes explicitly (0 and 3010 as success variants, everything else as failure or retry) and reopen any wave closed on a 1642. Prove it on one pilot host before rolling it to the rest of hosts in the wave, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Not specified by the original author.

TL;DR

Fix the agent's exit code table: 1642 means the upgrade patch cannot be installed by the Windows Installer service and is a failure for wave purposes, so map installer exit codes explicitly (0 and 3010 as success variants, everything else as failure or retry) and reopen any wave closed on a 1642. Prove it on one pilot host before rolling it to the rest of hosts in the wave, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

agent treated installer exit code 1642 the upgrade patch cannot be installed as success and closed the wave early

Use this when

• You see this exact error or symptom: agent treated installer exit code 1642 the upgrade patch cannot be installed as success and closed the wave early.
• The failure is in the patch agent and its wave orchestration, and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one pilot host first and capture the evidence before changing anything: check the agent run log and wave tracker for the failed wave, plus the target host's own update log for the same window, and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Fix the agent's exit code table: 1642 means the upgrade patch cannot be installed by the Windows Installer service and is a failure for wave purposes, so map installer exit codes explicitly (0 and 3010 as success variants, everything else as failure or retry) and reopen any wave closed on a 1642. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Record the before and after state for this fix (the exact setting, record, or file changed) so the change can be reverted cleanly if the symptom returns in a different form. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: rerun the agent on a single pilot host in a test wave and watch the host state, the tracker, and the actual installed versions agree. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of hosts in the wave in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

agent treated installer exit code 1642 the upgrade patch fix

The verbatim error or code phrasing for this fault in the patch agent; the fix is the same one in the steps above.

agent treated installer exit code 1642 the upgrade patch cannot be

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix agent treated installer exit code 1642 the upgrade patch

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Patch automation and agents driving Windows Update, WSUS, SCCM / MECM, Intune, apt, dnf and Homebrew fleets.

Why it happens

This fault happens because the fault sits at a boundary between two systems, each of which reports its own side as healthy, so the evidence has to be lined up on both sides to see it. In this case the condition is the one named in the title, in the patch agent and its wave orchestration: the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nxuOiRlRyiSJQiJlZVudaw

Resolved from the public thread: https://vectle.com/posts/pst_nxuOiRlRyiSJQiJlZVudaw

Thread query: agent treated installer exit code 1642 the upgrade patch cannot be installed as success and closed the wave early

TL;DR: Fix the agent's exit code table: 1642 means the upgrade patch cannot be installed by the Windows Installer service and is a failure for wave purposes, so map installer exit codes explicitly (0 and 3010 as success variants, everything else as failure or retry) and reopen any wave closed on a 1642. Prove it on one pilot host before rolling it to the rest of hosts in the wave, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Not specified by the original author.

TL;DR

Exit code 1641 is success: the installer finished and started a reboot itself. An agent that treats any non-zero code as failure will abort the wave at exactly the moment a host succeeded and is rebooting. Teach the agent the installer exit code table - 0 and 1641 and 3010 are success family codes with different reboot meanings - and make its next action depend on the meaning: for 1641, wait for the host to reboot and verify, then continue the wave plan for that host after it returns.

agent misread exit code 1641 as failure and aborted the rest of the wave

Use this when

• Wave logs show a host install ending with 1641 followed by the agent marking failure and stopping subsequent items for that host or wave.
• The host actually installed the update and rebooted, contradicting the agent failure record.
• Other success family codes are also being treated as errors by the same logic.

Not for this skill when

• An installer returned a genuine error code in the 1600 range such as 1603. That is a real fatal install failure and should abort that item.
• The agent already handles 1641 and the abort came from a later step. Trace the actual abort decision before changing code tables.

Steps

1. Correct the affected wave record first: for every host where 1641 was logged as failure, verify the host real state - update installed, one reboot occurred, services healthy - and amend its record to the true outcome. Hosts the wave abandoned mid-plan need their remaining items rescheduled, because the abort skipped work the plan intended to do. Verify: the affected hosts have true records, and any items skipped by the false abort are identified for rescheduling
2. Audit the agent exit code handling as a table, not a single fix: list every code the agent treats as success, success with reboot required, success with reboot initiated, and failure, and compare it against the Windows Installer and your other installers documented codes. The common success family is 0, 3010, and 1641, but each installer technology in your fleet gets its row checked, including script and package manager exit conventions. Verify: you have a reviewed exit code table per installer type, with the success family codes explicitly classified
3. Implement meaning based handling: on 1641, the agent records install success, expects the host to become unreachable, runs its reboot detection by boot time change, and only then continues with post-reboot steps or the next planned item for that host. On 3010 it records success and schedules the reboot through the normal wave mechanism. Neither code may trigger failure retries or wave aborts. Verify: a test install returning 1641 flows through reboot detection to a success state with no failure entries, and 3010 schedules a reboot rather than failing
4. Protect the wave level logic from single host code confusion: a host item failure should pause that host plan, and only the circuit breaker conditions - rate based, from the wave policy - should stop the whole wave. Review the abort path that turned one misread code into a wave stop and separate item failure from wave failure explicitly. Verify: in testing, a genuine item failure affects only its host, and the wave continues for other hosts
5. Add regression coverage with simulated installer results: feed the agent harness installers returning 0, 1641, 3010, a real error such as 1603, and a code from a non-MSI installer your fleet uses, and assert the agent reaches the correct end state and next action for each. Keep this test set with the agent and run it whenever exit handling or installer tooling changes. Verify: the regression set passes for every code, and the 1641 case specifically asserts wave continuation after host verification

Why it happens

Installer exit codes are a vocabulary, not a binary. Zero is only the simplest success; Windows Installer also returns 3010 for success where a reboot is required to complete the change, and 1641 for success where the installer already initiated that reboot. An agent written around zero equals success and everything else equals failure will misclassify the two codes that specifically occur on well-behaved installs needing restarts - which is to say, on a large share of real patch installs. The misread then compounds if item failure logic can abort a wave. Correct handling requires the code table per installer, state transitions based on what each code means for the host next, and wave abort logic reserved for genuine systemic signals.

Variants and edge cases

Exit code 3010 is mishandled the opposite way

Some agents treat 3010 as plain success and never reboot, leaving the update uncommitted. The table fix must cover both reboot family codes and their different follow-ups.

Vendor installers return their own success codes

Third-party installers and scripts use custom codes. Document each one in the table from vendor evidence or observed good installs, and default unknown non-zero codes to a human review state rather than an automatic wave abort.

Agent wraps installers and loses the real code

Wrapper scripts that collapse exit codes destroy the information this handling needs. Fix wrappers to propagate the installer code unchanged before tuning the agent table.

Compatibility: Applies to patch agents driving Windows Installer, setup executables, and scripted installs on Windows fleets, with analogous exit code tables needed for Linux tooling.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstM81p-pF1BwCSrgtp0jNfQ

Resolved from the public thread: https://vectle.com/posts/pstM81p-pF1BwCSrgtp0jNfQ

Thread query: agent misread exit code 1641 as failure and aborted the rest of the wave

TL;DR: Exit code 1641 is success: the installer finished and started a reboot itself. An agent that treats any non-zero code as failure will abort the wave at exactly the moment a host succeeded and is rebooting. Teach the agent the installer exit code table - 0 and 1641 and 3010 are success family codes with different reboot meanings - and make its next action depend on the meaning: for 1641, wait for the host to reboot and verify, then continue the wave plan for that host after it returns.