Posts by ElRayOX

Marcel,

Thank you very much! I'll use the patch and give this a try.

Hello,

Is it possible to have Conquest act as a simple router and not store images? I'm sure there is a way to do it but I can't seem to figure it out.

This may be a duplicate post and, if so, I apologize.

Thanks very much.

I cloned the identity of Conquest using Etiam WinSCP and attempted a send from the Toshiba Aplio Ultrasound. It failed with no activity in the WinSCP log. I took this as a good sign thinking it could be a network issue. I then cloned the identity of the ultrasound unit with a laptop and successfully sent a study to Conquest. So the network is apparently OK. The situation is the Toshiba Aplio US could successfully communicate with the previous Agfa IMPAX but cannot do so with Conquest. Does the Toshiba Aplio use some proprietary non-DICOM method of communication that only Agfa can understand? Or has this ultrasound unit suddenly broken (which would be quite a coincidence). Other devices here communicate with Conquest just fine. It's a mystery right now.

This may not be a time-out issue. With a time-out extended to 2400 I still have the problem. Strange that I don''t see an association request from the ultrasound. I can successfully DICOM Echo ultrasound. I may try having them send images to another server application to see if the problems persist or go away.

I've never seen this error before.

Ultrasound is the only affected modality. The error is consistent. I'll try extending the time-out to see if that works and will let you know. Thank you.

The *** multiplex: connection terminated error persists at this location. The only unique thing I can think of is that all the modalities, including Conquest, have AETitles where the first 7 characters are the same. But this doesn't affect MR & CT, only US.

Ultrasound images generated from this ultrasound machine that were migrated from the previous archive to Conquest traveled fine. I'm only having a problem with images coming directly from the US to Conquest.

Hello All,

I've just came across the same problem with *** multiplex: connection terminated

I have a Conquest running 1.4.14 receiving images from CT, MR, CR & US. All studies are immediately forwarded to a workstation with no filtering. I do not know the AETitles of the devices so Conquest is set to be promiscuous. Images from all the modalities receive and forward fine with the exception of the Toshiba Ultrasound unit. I have only one ExportConverter on this machine.

I since learned the AETitle, IP and Port of the Toshiba Ultrasound and have entered that as a DICOM Peer in Conquest. I should know within the next 24 hours if this has made any difference. The odd thing is there is no information in the serverstatus.log file of any association request from the Toshiba Ultrasound. There is only the "*** multiplex: connection terminated" error and it takes a minute or two for it to appear.

This is puzzling...

There seems to be a couple of versions of Visual Studio Express. Which one should I use? I haven't worked with Visual Studio before.

Until then, here are Event Viewer entries from different server that crashed when running as a service. This one is using 1.4.12c, Windows Server 2003. It's been very reliable and this is the first failure in about 8 months.

Event Viewer:
Faulting application dgate.exe, version 0.0.0.0, faulting module dgate.exe, version 0.0.0.0, fault address 0x00050fcc

Dr. Watson:
The application, C:\dicomserver\dgate.exe, generated an application error The error occurred on 10/16/2008 @ 17:19:55.906 The exception generated was c0000005 at address 00450FCC (dgate)

Marcel,

Let me see about doing that. Yeah, this is a strange issue. I could have two identical servers running Conquest as a service. One will have no problems at all, the other would chronically crash.

I'll check into getting more details on the crashing to you.

Thanks very much...

This is using the standard dbaseIII database

Hello Marcel,

Thanks very much for your reply.

Here is the info from the Event Viewer:

Faulting application dgate.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.3959, fault address 0x0004afb2.

From bottom section:

In bytes:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 64 67 61 ure dga
0018: 74 65 2e 65 78 65 20 30 te.exe 0
0020: 2e 30 2e 30 2e 30 20 69 .0.0.0 i
0028: 6e 20 6e 74 64 6c 6c 2e n ntdll.
0030: 64 6c 6c 20 35 2e 32 2e dll 5.2.
0038: 33 37 39 30 2e 33 39 35 3790.395
0040: 39 20 61 74 20 6f 66 66 9 at off
0048: 73 65 74 20 30 30 30 34 set 0004
0050: 61 66 62 32 afb2

In words:
0000: 6c707041 74616369 206e6f69 6c696146
0010: 20657275 61676420 652e6574 30206578
0020: 302e302e 6920302e 746e206e 2e6c6c64
0030: 206c6c64 2e322e35 30393733 3539332e
0040: 74612039 66666f20 20746573 34303030
0050: 32626661

Hello All,

I have had repeated, unexpected failures with a server running 1.4.14 as a Windows service. The log files reveal no info, but the service unexpected stops. The Windows event viewer only showed one entry that dgate had failed, though this had happened more than once. The dicomserver log file shows no information related to the failure. The strange thing is, I have multiple servers running Conquest as a service but occasionally I have a machine where it doesn't run reliably as a service.

Are there any known issues with installing => uninstalling => reinstalling Conquest as a Windows Service or is there something else I need to look at.

The server is running Windows 2003 Server R2 Standard.

Thanks very much. This is a great meeting place.

Thank you all for your input. I had never thought of network problems triggering errors and this is something that maybe I should look into. The only modality here is an Agfa CR30 and I don't imagine there are any DICOM problems with it. Thank you.

Hello All,

I have Conquest running very reliably at several sites but one site has proven to be problematic. At random times dgate will simply quit. I have check marked the box "Keep Server Alive" (which it does) and the log files will state: "Restarted dead server after error 7".

This is a very low use environment that does maybe 3-5 CR studies per day. The only unusual thing is that this server is running Windows 2003 Small Business Server rather than Windows 2003 Server R2 Standard.

Any idea what Error 7 indicates? Is there any problem using Small Business Server?

Thank you for a great forum!

Solved!

Apparently a user managed to move an image from one study to another. Conquest rejected the study because of this (hence the log file entries above). This modified study sat in the CR queue and held up transferring of any subsequent studies.

Ultimately there was no server problem.

Suddenly started having issues receiving images from an Agfa CR. The log shows this:

[FPSRV1] 20080319 15:55:12 ***Refused to enter inconsistent link StudyInsta into DICOMSeries: PatientID = '204339' SeriesInst = '1.3.51.0.7.690386733.61509.5711.36549.6616.18443.55379' AND SeriesPat = '204339', Old='1.3.51.0.7.1252550629.25999.54080.41394.7364.28641.41066', Refused='1.3.51.0.7.204971267.44497.26957.43535.58473.54828.50827'
[FPSRV1] 20080319 15:55:12 ***Error saving to SQL: 204339\1.3.51.0.7.690386733.61509.5711.36549.6616.18443.55379_0003_000003_120596011202cb.v2

Does the "inconsistent link" error indicate this is this a CR issue?

I'm a little mystified...

Is there a way to simultaneously display multiple studies in iQ-VIEW? I've attempted to do this following the *sticky* instructions regarding K-PACS and it doesn't work. This would be valuable when comparing previous and current studies.

As it turns out, reverting back to 1412c did solve the problem. I did not think to try disabling LittleEndianExplicit but I might put them back to 1413 and disable it.

I ran into this problem with images from an ATL HDI5000 which would cause the memory error and the server to shut down. Reverting back to 1412c seems to have solved the problem. I'll know in the next few days. This is an old ultrasound system so its adherence to DICOM 3.0 is probably questionable.

Thanks very much! I'll give it a go.