mDicom.exe v2026.3.0.5126: SCP does not answer new A-ASSOCIATE requests during C-MOVE retrievals (per-study wedge, clear

clicker71 · Mon Sep 07, 2026 11:16 am

Product: MicroDicom DICOM Viewer, mDicom.exe v2026.3.0.5126.
Roles: DICOM SCU of C-MOVE (Study Root Query/Retrieve) AND DICOM Storage SCP (C-MOVE destination, port 11112).
Peer: Clarus PACS bridge (pynetdicom 3.0.4 based C-MOVE SCP / C-STORE SCU), same host loopback 127.0.0.1.

Observation:
During a batch retrieval (C-FIND study, C-FIND series, then one C-MOVE per study) the viewer's Storage SCP periodically stops answering NEW A-ASSOCIATE requests: the TCP connection is accepted, the A-ASSOCIATE-RQ PDU is sent, and no A-ASSOCIATE-AC/-RJ arrives until the requestor's ACSE timeout (10 s) fires. Existing associations continue to work. A given study can wedge repeatedly over minutes; only a MicroDicom restart clears the condition.

Sender log excerpt (Clarus bridge, 2026-09-07, local time):

Code: Select all

10:34:17 [ERROR] ACSE timeout reached while waiting for response to association request
10:34:17 [INFO]  [C-MOVE] main association ACSE timeout, retry 1/1 after 10s
10:34:37 [ERROR] ACSE timeout reached while waiting for response to association request
10:34:37 [ERROR] [C-MOVE] Cannot associate with MICRODICOM at 127.0.0.1:11112

90-second window, one peer, six jobs, alternating outcomes:

Code: Select all

Job #57 (1 instance, RLE):      main assoc answered (68 contexts accepted)
Job #57 fallback (US MF, RLE):  answered
Job #58 main assoc:             NO ANSWER (2 attempts, 10 s each)
Job #59 (2 instances):          main assoc answered
Job #59 fallback (JPEG 4.50):   NO ANSWER
Job #60 (432-slice study):      main assoc NO ANSWER (2 attempts)
Job #61 main assoc:             answered
Job #61 fallback (JPEG-LS 4.80): NO ANSWER
Job #62 main assoc:             answered
Job #62 fallback (JPEG 4.70):   NO ANSWER

Notable patterns:
- Fallback associations (a second A-ASSOCIATE from the already-associated peer while the main association is streaming) go unanswered 3 out of 4 times; the main associations work in the same window.
- The 432-slice study wedges on repeated attempts minutes apart and recovers only after a MicroDicom restart (operator-verified).
- The IDENTICAL study is delivered to another viewer (Weasis 4.7, port 11113) on the same bridge: 432/432 instances, 521,048,630 bytes, 17 seconds, zero failures.

Expected behavior:
Per PS3.8 9.2, an acceptor that has received an A-ASSOCIATE-RQ shall issue the A-ASSOCIATE response primitive (AC or RJ); the requestor aborts after its configurable ARTIM timer (PS3.8 9.1.5, "shall be configurable"). Starving new association requests while existing ones work is an interoperability defect: any retrieving system that opens a second association per study (standard practice for mixed transfer syntax studies) sees spurious failures.

Questions to the vendor:
1. Where does MicroDicom persist its network activity / DICOM logs (file paths, if any)? The "Network activity" pane appears to be in-memory only; no log location is documented on the website.
2. Is there a known defect in v2026.3.0.5126 where the SCP listener stalls after a transfer or after a second association from the same peer?

Evidence available on request: sender-side log excerpts with timestamps; cross-check run with another viewer against the same study and sender; reproduction recipe (retrieve the 432-slice study followed by a small mixed-transfer-syntax study back-to-back).

Reported by the Clarus PACS project: https://github.com/clicker71/clarus-pacs

clicker71 · Mon Sep 07, 2026 12:10 pm

Update (07.09.2026): decisive reproduction.

Same sender (same bridge build, same study, same destination 127.0.0.1:11112). A separate MicroDicom install used locally shows "2026.1" in the title bar - the wedge exists in BOTH 2026.1 and 2026.3 build 5126.

Code: Select all

12:46:58  C-MOVE 432-study -> Job #4: 3 x ACSE timeout (~15 s each), 0 delivered; the viewer got the C-MOVE-RSP Failure C000 "Unable to process"
12:47:55  sender-side peer eviction: Removed MICRODICOM@127.0.0.1 after 3 consecutive failures
12:48-49  Jobs #5, #6: same 3 x ACSE timeout each, 0 delivered
12:52:02  MicroDicom restarted, the SAME study re-requested
12:52:04  association accepted on the FIRST attempt (126 contexts requested, 122 accepted)
12:52:20  Job #7 finished: 432/432 success, 0 failed, 521,048,630 bytes, 16 s

The only variable between Job #4 (3 x ACSE timeout) and Job #7 (432/432 in 16 s) is the MicroDicom restart. The SCP listener state is the defect; the retrieving bridge behaved per PS3.8 throughout (configurable ACSE timeout, bounded retries, honest C-MOVE-RSP statuses).

Mon Sep 21, 2026 2:45 pm

Hello,

Thank you for the detailed reports and the clear reproduction.

Question 2 (known defect): Yes. We reproduced this and found the cause in the Storage SCP. When a new association reused a worker that was already idle, it ran on the same thread that accepts incoming connections. While that association was open, the listener couldn't answer any new A-ASSOCIATE request, so the requester waited until its ACSE timeout expired. This matches what you saw:

Existing associations kept working.
The fallback association from the same peer went unanswered.
The problem showed up on back-to-back retrievals.

Every association now runs on its own thread, so the listener always stays free to accept new requests. The fix is in our latest beta:https://www.microdicom.com/beta.html

We haven't reproduced your exact scenario, the 432-slice study followed by the mixed transfer syntax study. We'd appreciate it if you could retest with the beta and tell us whether the problem still occurs. If any wedge remains, please send the sender-side log excerpts with timestamps for that run.

Question 1 (logs): The Network activity pane is in-memory only, as you suspected, and the release build doesn't write a log file. For interoperability testing, the sender-side logs (as in your reports) are the best source.

Thank you again for the careful testing.