Update or Installation Failure

7.10 Update or Installation Failure

Identify check, download, application closure, installer launch/execution, or post-update startup. The updater downloads/verifies an official EXE and exits after handoff, not after proving installation success.

7.10.1 Check and Download Failure

Preserve time, four-part version, and message. Check clock/network/proxy/space/temp rights and approved service access; general browsing is insufficient. Retry through normal controls, not incomplete files. Random download names can be legitimate; validate origin/workflow. The current scheme does not require ZIP passwords or third-party archive extraction. Stop on signature/publisher/integrity failure and contact support, never bypass checks or run renamed rejected packages.

7.10.2 Application Closure and Cancelled Elevation

Save design/edits/results, pause automation, and inspect queues/devices. A cancelled save prompt, remaining target-directory instance, or closure timeout can prevent installation. Resolve normally rather than ending all processes or unrelated installation roots. A cancelled native Windows elevation prompt means installation did not begin, not that files were replaced. Authorized staff enter credentials locally in Windows, never in feedback forms.

7.10.3 Installer Started but Upgrade Incomplete

Find the installer and its final message; do not restart updates/products because the updater vanished. Inspect pending license/directory/lock/elevation prompts. Keep temporary files while installation uses them. Preserve errors/stage/logs, including cancel/space/locks/restart. Use official retry/repair/rollback, not individual new files copied into the runtime root.

7.10.4 Interruptions, Historical Markers, and Data

For power loss/uncertain results, pause affected shared writes, preserve installer/current-directory evidence, and have maintenance determine transaction/recovery state. Program rollback and database recovery are separate; do not overwrite newer personnel simply because binaries roll back.

The current EXE handoff does not create old ZIP-style recovery artifacts. Existing historical .CREVIAUpdate.recovery requires the corresponding historical restore.txt procedure and maintenance verification, not marker deletion. With missing instructions/incomplete backups/mixed releases, preserve and escalate rather than uninstalling/clearing defaults, users, license, or business data. Follow current official installer data/rollback rules.

7.10.5 Acceptance and Complete Incident Record

After explicit installer completion, verify both shortcut paths/versions, layouts/users/data/photos/settings with automation off. Read/preview one sample, then approved save/print/device tests before full work.

This fictitious example shows the required reporting detail, not actual releases or a completed repair:

Incident: INC-DEMO-20261015-02
Product: COC, before 1.0.1.0, target 1.0.2.0 (illustrative)
Environment: Windows 11 x64, English, COC-DEMO-01
Time: 2026-10-15 14:20, UTC+08:00
Last good state: DEMO-017 read/preview works; automatic printing off
Steps: check > download > save/close both apps > installer opens
Observed: target file in use; installation not complete
Checked: another user session still runs COC from the same root
Business: no new tasks; 2 cards output, 0 queued, no pending encoding
Action: preserved message; asked user to save/exit, no forced termination
Request: confirm installer retry and post-install version checks
Attachments: redacted installer message, relevant events/available logs

Release builds need not contain debug logs; collect available events/installer output per 6.7 without whole databases, license contents, passwords, or keys. Record cause/change/retest/reopening time and verify all station targets/versions. If completed people or stored state remain uncertain, keep paused pending owner approval.