Ultrasound C-MOVE Retrieve Failed: Find the Reverse Link
Same symptom on your system?
Tell us your model and what it is doing. A GEPROBE engineer replies with a diagnosis path, part options and pricing — usually within 6 hours, with no obligation.
Chat on WhatsApp
An ultrasound C-MOVE retrieve failed alert sends most teams to the hardware cupboard. The usual cause is a second connection that the archive was supposed to open, and did not.
Query and retrieve run in opposite directions. A search rides a link the scanner opens. A retrieve asks the archive to dial back toward the machine that asked.
Either leg can work alone. That is why finding the patient and failing to pull the study is a location, not a contradiction.
Why a working query tells you almost nothing
During a search, the scanner sends a C-FIND request to the archive's address and port. It names itself as the calling entity, names the archive as the called entity, and receives matches on that same link.
Retrieve changes the question. The scanner sends a C-MOVE request naming a Move Destination, which the standard defines as an entity title and nothing more: no address, no port (PS3.4 C.4.2.1.3, accessed 2026-11-02).
The archive must resolve that title in its own node table, choose a host, and start the transfer. The store leg runs on a different association, with the query provider acting as storage user (PS3.4 C.4.2, accessed 2026-11-02).
A note in the same clause gives the reason: the receiver need not be the requester. C-MOVE exists so a cart can push a study to a colleague's workstation. When the cart names itself, the archive still dials out.
So the failing leg begins in archive configuration, crosses a firewall the other way, and ends in the scanner's receiver. A successful query touches none of those three.
Confirm the operation before you touch the network
Open the scanner's DICOM configuration or conformance statement and write down which operation the Retrieve button uses. That one line decides whether the reverse-connection model applies at all.
| Operation | Who dials the images | What a good query proves | Check first |
|---|---|---|---|
| C-MOVE | Archive, to the destination title | Archive port answers | Node record, path |
| C-GET | Nobody; stores share the link | Both directions work | Contexts, syntaxes |
| HTTP | Nobody; client pulls | The endpoint answers | Auth, path |
C-GET inverts the picture. Its store sub-operations run over the association that already carried the request (PS3.4 C.4.3, accessed 2026-11-02).
If the site uses C-GET, the failure sits in a link that already works, usually as refused presentation contexts or an unsupported transfer syntax.
HTTP retrieval routes the same way. Neither alternative fixes a C-MOVE failure today, but either one changes which half of the diagram you investigate.
The three application entity titles that must agree
Most "destination unknown" tickets are a string comparison, and the comparison fails because three strings get discussed as if they were one.
| Title | Who owns it | Must match |
|---|---|---|
| Scanner calling title | Scanner service | The archive's caller list, if any |
| Archive storage title | PACS administrator | Sender entries on the cart |
| Move Destination | Scanner entry | A node record in the archive |
Two of these are visible at the cart. The middle one lives in the archive log or the conformance statement, which is where the ticket stalls.
A title is a 16-byte value, and leading or trailing spaces do not count (PS3.5 Table 6.2-1, accessed 2026-11-02). Embedded characters do count: case, an underscore where a hyphen was meant, a letter O where a zero was typed.
There is no wildcard. If the node table holds US_ROOM3 and the cart sends US-ROOM3, both machines behave correctly and no image will ever arrive.
Read the response before you read the log
The C-MOVE response comes back on the link that already works, which makes it the cheapest evidence available. Table C.4-2 lists what each status may carry (PS3.4 Table C.4-2, accessed 2026-11-02).
| Status | Meaning | Counts | First move |
|---|---|---|---|
| A801 | Destination title unknown | None | Compare the strings |
| A702 | Stores could not be done | All three counts | Read its delivery log |
| A900 | Identifier malformed | Error comment | Check level and keys |
| B000 | Some stores failed | Completed above zero | Read the failed list |
| FE00 | Cancelled | All four | Find who cancelled |
Missing counts on a failure are normal. The remaining count is required only in a pending response, and the completed, failed and warning counts may appear in a final one (PS3.4 C.4.2.1.6–.9, accessed 2026-11-02).
The failed instance list is the other useful field. It is carried in cancel, failure and warning responses, and absent when nothing failed (PS3.4 C.4.2.1.4.2, accessed 2026-11-02).
On a half-arrived study that list shows whether the missing objects share a class or an encoding. A cine loop stored one way beside stills stored another is the pattern worth chasing.
Evidence that survives the handoff
Rank what you have before you call anyone. The top two items close tickets; the bottom one starts arguments.
The archive's delivery log line. It names the address the archive dialled, and usually why the attempt ended. Ask for this first.
The scanner's service log. It may record the inbound association it refused, which the archive cannot see.
The status and counts, written down. Include the time, the study and the attempt number. Two presses later the original is gone.
The console pop-up. Client-side text, often generic, and the reason a real status code never reaches the person who could act on it.
Ask the archive owner for the delivery attempt itself, not for "the logs":
Time of failure: 2026-11-02 09:14 (fictitious)
Cart: US_ROOM3, 192.0.2.41, port 104 (fictitious)
Move Destination sent: US_ROOM3
Final C-MOVE status: A801, no counts returned
Ask: did a node record for US_ROOM3 exist then, and what address did it hold?When secure DICOM changes the question
TLS often moves the listening port. A firewall rule written for the old port now fails in a way that looks exactly like a policy block, so confirm the port from the scanner's own configuration.
Encryption also limits a capture. A handshake still proves reachability from the archive's subnet; the association inside it stays unreadable, so the reason has to come from the endpoints.
It adds a failure ahead of DICOM as well: trust. A destination that rejects a certificate never reaches title matching.
Where a plain test path exists, the reject message separates the cases. Result 1 is permanent and 2 transient; source 1 means the receiving application refused (PS3.8 Table 9-21, accessed 2026-11-02).
With source 1, reason 3 is an unrecognised calling title and reason 7 an unrecognised called title. Reason 3 is the classic "the archive dialled us and we do not know it" — a configuration entry, not a broken network.
The arithmetic of a partial retrieve
Intermittent retrieves are usually a timing argument dressed as a hardware argument. Three lines settle it with numbers you can obtain on site.
delivery_seconds = (instances x average_instance_MB) / sustained_MB_per_second
retry_load = attempts x instances
margin_seconds = archive_message_timeout - delivery_secondsA fictitious example: 240 instances at 1.8 MB is 432 MB. At a measured 6 MB/s that is 72 seconds of transfer. If the archive abandons an outbound association after 60 slow seconds — a site setting, not a standard value — the margin is negative.
Then large studies fail while small ones pass. That gets read as a cart that cannot handle big exams, and it ends in a board swap.
The middle line is the forgotten one. Five presses on a 240-instance study can produce 1,200 store attempts, some succeeding on the second pass and burying the first failure.
Acceptance checklist before you close the ticket
- Operation confirmed as C-MOVE, not C-GET or HTTP.
- Destination string recorded exactly as sent.
- Archive node record confirmed, with address and port.
- Three titles compared character by character.
- Final status and any counts written into the ticket.
- Archive delivery log line for that attempt attached.
- Reachability tested from the archive side to the port.
- Partial retrieve reconciled against the failed list.
- Security layer checked for its own port and trust entries.
- Case reproduced once, not five times, after the change.
When it really is a part
Configuration errors do not damage hardware, and hardware faults do not produce a clean C-MOVE status from a healthy archive. That distinction is worth money, because the alternative is buying a component to solve a string mismatch.
Five signatures justify opening the machine: no link or no address on any service; the same failure from a known-good modality on that switch port; and a disk or storage error during the local write.
Two more: a receiver that accepts no association from any sender, and a power or connector fault that also breaks probe recognition.
A control test costs nothing. If the cart can send a study out to the archive, its interface and stack are working, and the retrieve problem is about who may connect inward.
What this means for a repair decision
We repair transducers and parts. We do not sit inside your archive's node table, and we would rather see a cart with a real fault than one with a mistyped destination.
Our published process includes a free evaluation before quotation, OEM-standard restoration, a warranty on repairs, and a test report with a cosmetic checklist (repair process, accessed 2026-11-02).
Coverage is listed for probes and parts.
When the checklist ends in a title, a port or a rule, the fix belongs to the PACS administrator, and no part will help. When it ends in a dead interface or a failed local write, that is a component question, and one we answer.
Sources and verification notes
- DICOM PS3.4, section C.4.2 with Table C.4-2: https://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.4.2.html — accessed 2026-11-02.
- DICOM PS3.4, C.4.3 C-GET Operation: https://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.4.3.html — accessed 2026-11-02.
- DICOM PS3.5, Table 6.2-1, AE representation: https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.2.html — accessed 2026-11-02.
- DICOM PS3.8, 9.3.4 and Table 9-21: https://dicom.nema.org/medical/dicom/current/output/chtml/part08/sect_9.3.4.html — accessed 2026-11-02.
- GEPROBE repair process: https://www.geprobe.com/repair — accessed 2026-11-02.
- GEPROBE product scope: https://www.geprobe.com/about — accessed 2026-11-02.
Addresses, entity titles, study sizes and transfer rates above are fictitious examples. Site timeouts and ports are configuration values, not standard requirements. No patient data is included.
Related Articles
Ultrasound Probe Repair: Evidence Hospitals Can Defend
Probe-level acceptance for hospital ultrasound maintenance: capture a baseline before shipment, test imaging after repair, and price the downtime honestly.
Ultrasound Probe Repair Loaner: When One Transducer Fails
Choose ultrasound probe repair loaner cover properly: triage the failure level, cost the downtime, and compare a probe loan against a console rental.
An Import Alert Is Not a Recall: Reading Olympus 89-04 Into a Spares File
Two FDA documents name the same five Olympus devices under different dates. Neither date is wrong; together they decide which field a fleet and spares record has to cite, where the Red List files each model, and where the capital-equipment boundary sits.