This document describes troubleshooting SWIM, with practical checks, clear recovery steps, and information required to check prior to escalation.
In this document, CatC means Cisco Catalyst Center (CatC) and SWIM means Software Image Management (SWIM).
Before making any change, make sure console or management access is available, the target image is correct, a backout path exists, the device is not already running another install operation, and the change is approved.
The GUI gives useful context before you move to CLI or database checks.
This review must be one of the first checks before image distribution or activation troubleshooting.

Recommended TAC review flow:

What TAC verifies:
Why this step matters: This step helps you catch image-selection mistakes early. It also helps you explain whether the upgrade was driven by compliance, lifecycle alignment, or a security advisory.
If FIPS mode is enabled, URL-based image import must be restricted by platform security controls. In such cases, use a supported import method such as Cisco.com or a local file upload, then confirm that the image metadata and checksum are populated correctly after import.
![]() |
![]() |

If a remote distribution server is configured under System > Settings > Device Settings > Image Distribution Servers, include it in your analysis from the beginning of the case. It can affect transfer method, transfer timing, staging behavior, and the actual point of failure during image distribution.

What TAC checks:
Why this matters:
When a remote distribution server is in use, the image path is no longer a simple controller-to-device transfer. A failure is caused by the external server, protocol preference, reachability, image staging, or server-side availability rather than by the device itself.
Recommended TAC validation flow:
Common TAC issues to watch for:
Before deep troubleshooting, collect:
Recommended TAC collection order:
Why this matters: Collecting this information early reduces back-and-forth during escalation and helps TAC determine whether the issue is related to image selection, task orchestration, platform compatibility, or device state.
Check these items in the GUI:
Recommended TAC validation order:
Why this matters: These checks help TAC decide whether the issue is caused by image selection, assignment, controller task handling, inventory synchronization, or the device itself.
Run only the commands that fit the platform and software mode.
These install-related commands are especially useful during SWIM upgrade analysis. Theshow tech installcommand provides a broad technical snapshot of the install process and is commonly used to capture overall install-related evidence for review or escalation. Theshow platform software install-manager switch X R0 operation history detailcommand shows the detailed history of install-manager operations for a specific stack member and helps confirm which steps completed and where the process failed. Theshow platform software install-manager switch X R0 operation current detailcommand shows the live install status for that switch and is useful when the upgrade appears stuck or is still running. Therequest platform software trace archivecommand collects platform software trace data for deeper analysis, while therequest platform software trace slot switch X archivecommand collects the same trace data for a specific stack member. Together, these commands help teams understand what happened during the install, what is happening now, and what evidence must be collected for further analysis.
show tech install
show platform software install-manager switch X R0 operation history detail(stack)
show platform software install-manager switch X R0 operation current detail(stack)
request platform software trace archive
request platform software trace slot switch X archive(stack)
show version
show inventory
show platform
show boot
show running-config | include boot system
show startup-config | include boot system
show file systems
dir flash:
dir bootflash:
Use these commands to confirm the current version, boot settings, and available storage.
show install summary
show install active
show install committed
show install log detail
show install request
These commands help you check whether a previous install is still running, incomplete, or not committed.
show logging
show logging | include INSTALL|install|BOOT|boot|ERROR|FAIL|ROMMON
show archive log config all
show reload
show tech-support
show switch
show switch detail
show redundancy
show platform software status control-processor brief
show platform software package status
ping <gateway-or-management-peer>
show ip interface brief
show interfaces status
show processes cpu sorted | exclude 0.00
show processes memory sorted
show file systems
dir flash:
dir bootflash:
show logging | include SCP|SFTP|HTTP|TFTP|copy|transfer|flash
show processes cpu sorted | exclude 0.00
Confirm there is enough free space, check whether the management path is stable, and remove old files only after you confirm they are not in use.
GUI actions: Open the failed task, confirm the device is still managed, confirm the image is still present in the repository, check whether a remote distribution server is in use, and retry only after storage, credentials, and transfer path look good.
show version
show boot
show running-config | include boot system
show startup-config | include boot system
show install summary
Check whether boot variables still point to the old image. Correct the boot path if needed, then save the configuration before reload.
configure terminalno boot systemboot system flash:<target-image.bin>endwrite memoryshow boot
GUI actions: Review the task timeline, check whether the device came back after reload, run inventory sync if the GUI version is stale, and verify activation checks and cleanup settings before retrying.
show install summary
show install active
show install committed
show install log detail
show logging | include install|INSTALL
Check whether the package is already active but not committed. Do not start another install until you understand the current state.
install commit
First check whether a known-good image is still available locally and use the approved ROMMON recovery method for that platform.
dir flash:
boot flash:<known-good-image.bin>
show version
show boot
configure terminal
no boot system
boot system flash:<known-good-image.bin>
end
write memory
show switch
show switch detail
show version
dir flash:
show install summary
show logging | include switch|version|install
Confirm all members are present, verify image availability on all members, and retry only when the full stack is healthy.
show version
show inventory
show running-config | include boot system
If the device version is correct, suspect stale inventory or compliance data before treating it as a failed upgrade.
GUI actions: Refresh the device record, rerun compliance, confirm the golden image mapping is still correct, and review task history to confirm the expected target version.
dir flash:
dir bootflash:
delete /force flash:<unused-image.bin>
delete /force /recursive flash:<unused-package-directory>
show boot
configure terminal
no boot system
boot system flash:<target-image.bin>
end
write memory
show boot
reload
show install summary
install commit
show install committed
show version
show boot
show install summary
show logging | tail
show ip interface brief
13. TAC Workflow
Use this workflow after the main GUI and CLI checks. Treat it as the working sequence for a live TAC case.
Objective: Decide whether the problem started in Catalyst Center, in the transfer path, or on the device.
Working checks: Review the task details, timestamps, inventory state, and device reachability. Separate controller-side failures from transfer failures and device-side failures as early as possible.
Decision: If the task failed before the image reached the device, stay focused on inventory, credentials, repository state, and transfer path. If the image copied successfully but activation failed, move to boot variables, install state, and device logs.
Objective: Build a clean failure timeline.
Capture: Record the exact GUI error text, task ID, failure timestamp, and child task details if available.
Why this matters: Data needs to match the GUI event with device logs, SWIM logs, and database records.
Objective: Decide whether this is a single-device issue or a wider platform issue.
Check: Determine whether the issue affects one device, one stack, one site, one platform family, or many devices across the environment.
Decision: If the same failure appears on multiple devices, suspect image quality, platform compatibility, repository state, credentials, or controller-side task handling before blaming one device.
Objective: Find the last stage that completed successfully.
Track: Walk the workflow through image import, assignment, distribution, activation, reload, and post-upgrade sync.
Why this matters: This keeps you from repeating steps that already worked and helps you stay focused on the real failure point.
Objective: Confirm whether the transfer stage really completed.
Checks: Verify whether the image is present on flash: or bootflash:, confirm there is enough free space, confirm the file is complete, and confirm the image matches the intended platform.
Decision: If the image is missing, continue with transfer troubleshooting. If the image is present, shift to activation, boot selection, package state, or post-upgrade validation.
Objective: Place the failure at the correct point in the timeline.
Classify: Break the issue into one of these timing points: before reload, during reload, or after reload.
Decision: If the failure happened before reload, focus on install logic, boot settings, and task orchestration. If it happened during reload, check console output, reload reason, and boot behavior. If it happened after reload, focus on rediscovery, compliance sync, stack health, and service recovery.
Objective: Make sure the device is stable before you run anything again.
Confirm: Verify that software mode is understood, boot variables are correct, storage is healthy, install state is not incomplete, stack or HA state is normal, and no previous install operation is still active.
Exit criteria: Do not retry until all of these checks are clear or you have a documented reason to proceed.
Objective: Reduce risk while still moving the case forward.
Start with: Refreshing inventory, rerunning compliance, reviewing logs, correcting boot variables, or committing a package if activation already succeeded.
Guidance: Do not jump to database updates or forced cleanup unless the normal checks already show the task is stale and the device is no longer active in the workflow.
Objective: Set a clear decision point before the next attempt.
Retry only when: The current issue is understood, the device is healthy, no conflicting task is still open, the image and assignment are correct, and recovery changes have been saved and validated.
Decision: If these conditions are not met, stop the retry path and move to escalation with the evidence you already collected.
show version
show boot
show install summary
show install log detail
show logging
show switch
show redundancy
dir flash:
dir bootflash:
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
17-Jun-2026
|
Initial Release |