Operating System
Windows Server 2025 Datacenter, 24H2 build 26100.32995
AMP Version and Build Date
2.8.0.4 (Proteus), Mainline/Release, built 24/07/2026
AMP Release Stream
Mainline
I confirm that
Intended Action
Update AMP and existing GenericModule instances through ADS across supported releases while preserving every instance's manually assigned ports and configuration.
Expected Behaviour
Existing game, query, remote-management, SFTP, and AMP management ports should remain assigned to the same instance during an update.
If ADS cannot confirm that the instance has stopped, or if update extraction encounters locked files, the update should abort without refreshing the instance configuration or reallocating any ports.
Actual Behaviour
This is a recurring, cross-version issue rather than an isolated 2.8.0.4 incident. It was first reported in the general Discord channel on 14 May 2026 after occurring at least three times during a week of successive AMP updates. It was reported again on 13 July 2026 because later updates through the web interface were still changing assigned ports.
It has affected multiple instance types across several AMP releases, although other instances updated individually during the same maintenance periods retained their assigned ports. Every application instance was updated separately using its Update Instance button. Update All was never used. The CLI updater was used only to update the main ADS instance.
During the latest observed incident, two comparison instances stopped normally before their GenericModule configurations were refreshed and retained their ports. The affected instance did not stop completely. ADS logged that its AMP executable and several plugin DLLs could not be extracted because they were still in use, but ADS continued by refreshing that instance's GenericModule configuration.
After the affected instance was eventually stopped, ADS refreshed its configuration again and restarted it. All three existing application ports were replaced with different unused ports. This caused dependent monitoring, firewall rules, and service integrations to fail until the changed assignments were discovered manually.
The original ports were within the configured Application Port Range, were already assigned to that instance, and did not conflict with any other configured instance. Manually restoring the original ports immediately restored connectivity.
sanitized-amp-port-reassignment-evidence.txt
Reproduction
This issue is intermittent and has not yet been reproduced from a clean installation. It has recurred across multiple AMP versions and instance types. Each affected instance was updated individually using its Update Instance button in the ADS web interface. Update All was never used.
Latest observed sequence:
- Start with an existing GenericModule instance using three manually assigned application ports within the configured ADS Application Port Range.
- Upgrade the main ADS instance using the CLI updater.
- Open an individual application instance in the ADS web interface and click Update Instance.
- During the latest incident, observe ADS report that the instance's AMP executable and several plugin DLLs could not be extracted because the files were still in use.
- Despite those extraction failures, observe ADS continue with Refreshing instance config for that same instance.
- After the instance is eventually confirmed stopped, refreshed, and restarted, inspect Network and Ports.
- Observe that its three existing ports have been replaced with different unused ports despite there being no external port collision.
The issue does not occur on every individual instance update. Other instances updated individually during the same maintenance period retained their assigned ports.
Suggested safeguards:
- Do not refresh or reallocate an instance configuration until the instance is confirmed stopped.
- Abort and roll back the instance update when extraction encounters locked files.
- Exclude the instance's own existing port reservations when validating that same instance during a template merge.
- Log the old and new port assignments together with the exact reason for any reassignment.
Operating System
Windows Server 2025 Datacenter, 24H2 build 26100.32995
AMP Version and Build Date
2.8.0.4 (Proteus), Mainline/Release, built 24/07/2026
AMP Release Stream
Mainline
I confirm that
Intended Action
Update AMP and existing GenericModule instances through ADS across supported releases while preserving every instance's manually assigned ports and configuration.
Expected Behaviour
Existing game, query, remote-management, SFTP, and AMP management ports should remain assigned to the same instance during an update.
If ADS cannot confirm that the instance has stopped, or if update extraction encounters locked files, the update should abort without refreshing the instance configuration or reallocating any ports.
Actual Behaviour
This is a recurring, cross-version issue rather than an isolated 2.8.0.4 incident. It was first reported in the general Discord channel on 14 May 2026 after occurring at least three times during a week of successive AMP updates. It was reported again on 13 July 2026 because later updates through the web interface were still changing assigned ports.
It has affected multiple instance types across several AMP releases, although other instances updated individually during the same maintenance periods retained their assigned ports. Every application instance was updated separately using its Update Instance button. Update All was never used. The CLI updater was used only to update the main ADS instance.
During the latest observed incident, two comparison instances stopped normally before their GenericModule configurations were refreshed and retained their ports. The affected instance did not stop completely. ADS logged that its AMP executable and several plugin DLLs could not be extracted because they were still in use, but ADS continued by refreshing that instance's GenericModule configuration.
After the affected instance was eventually stopped, ADS refreshed its configuration again and restarted it. All three existing application ports were replaced with different unused ports. This caused dependent monitoring, firewall rules, and service integrations to fail until the changed assignments were discovered manually.
The original ports were within the configured Application Port Range, were already assigned to that instance, and did not conflict with any other configured instance. Manually restoring the original ports immediately restored connectivity.
sanitized-amp-port-reassignment-evidence.txt
Reproduction
This issue is intermittent and has not yet been reproduced from a clean installation. It has recurred across multiple AMP versions and instance types. Each affected instance was updated individually using its Update Instance button in the ADS web interface. Update All was never used.
Latest observed sequence:
The issue does not occur on every individual instance update. Other instances updated individually during the same maintenance period retained their assigned ports.
Suggested safeguards: