Hi, I'm running into a problem which is sporadic but seems to have started with conquest v14 although I changed from MySQL to WAMP based MySQL at the same time. I am running on server 2003, native SQL client, MySQL v5.x(WAMP 2.0).
I have observed a problem in that I run taskmanager and find that one of the dgate.exe processes is utilizing 100% of a cpu (It's a quad core machine so 25% total). This persists even with no dicom activity. I have 4 instances of Conquest running on different ports so with time, all 4 of the instances will convert to high CPU and I get 100% CPU utilization. The machine then gets very slow and drops images.
Terminating the offending Dgate.exe process or rebooting solves the problem. Sometimes I don't see the high CPU utilization problem for days, other times it happens in hours after reboot.
I don't see anything in particular with the logs. The offending dgate.exe process continues to function without problems until all 4 hit 100% then the machine really slows and starts to fail.
Anyone have a similar experience?
High CPU
-
-
Hi,
Can I see you dicom.ini? It is lilely a problem with a thread - these are the threads: exportconverter, read-ahead (enabled by default), prefetcher (likely unused), mirror copy (likely unused), or a 'connection' that never terminates and keeps consuming CPU cycles. If you could attach a debugger to the offending dgate to see where it is running (addresses at a couple of pauses) that would be great. You might try disabling EnableReadAheadThread, and you could try and fish for a missing:
UPACS THREAD 16: ENDED AT: Wed Oct 31 22:01:35 2007
Marcel
-
I'm looking at the process right now. Memory usage is 25k, that seems about right. I/O usage is stable (no images coming in). CPU is 50% (on a quad machine...). I see 13 threads, 2 are consuming 25% CPU each. Both have a start address of 0x1ad2. Hmm, I see 4 TCP ports open, two labeled "CLOSE_WAIT", this does seem like a improper connection termination.
My dicom ini is:
# This file contains configuration information for the DICOM server
# Do not edit unless you know what you are doing[sscscp]
MicroPACS = sscscp
Edition = Personal# Network configuration: server name and TCP/IP port#
MyACRNema = FAIRLIGHT1
TCPPort = 5680# Reference to other files: known dicom servers; database layout; sops
ACRNemaMap = acrnema.map
kFactorFile = dicom.sql
SOPClassList = dgatesop.lst# Host, database, username and password for MySql database
SQLHost = localhost
SQLServer = conquest
Username = root
Password = orion
MySql = 1
DoubleBackSlashToDB = 1# Configure database
TruncateFieldNames = 10
MaxFieldLength = 254
MaxFileNameLength = 255
FixPhilips = 0
FixKodak = 0
KeepAlive = 60
LargeFileSizeKB = 1024
ZipTime = 05:
UIDPrefix = 1.2.826.0.1.3680043.2.135.733151.17777964
EnableReadAheadThread = 1
PatientQuerySortOrder =
StudyQuerySortOrder =
SeriesQuerySortOrder =
ImageQuerySortOrder =
IndexDBF = 1
PackDBF = 0
LongQueryDBF = 1000
TCPIPTimeOut = 300
FailHoldOff = 60
RetryDelay = 100
QueueSize = 128
WorkListMode = 0
DebugLevel = 0
Prefetcher = 0
LRUSort =
AllowTruncate =
DecompressNon16BitsJpeg = 1
UseBuiltInDecompressor = 1
IgnoreOutOfMemoryErrors = 0
PadAEWithZeros = 0
FileNameSyntax = 4# Configuration of compression for incoming images and archival
DroppedFileCompression = uj
IncomingCompression = uj
ArchiveCompression = as# Names of the database tables
PatientTableName = DICOMPatients
StudyTableName = DICOMStudies
SeriesTableName = DICOMSeries
ImageTableName = DICOMImages
DMarkTableName = DICOMAccessUpdates
RegisteredMOPDeviceTable = RegisteredMOPIDs
UIDToMOPIDTable = UIDToMOPID
UIDToCDRIDTable = UIDToCDRID# Banner and host for debug information
PACSName = FAIRLIGHT1
OperatorConsole = 127.0.0.1# Configure email of error messages
MailHost =
MailSignon =
MailFromName =
MailRcptName1 =
MailCollectTime = 1
MailWaitTime = 10# Configuration of disk(s) to store images
MAGDeviceThreshhold = 0
MAGDevices = 1
MAGDevice0 = F:\DICOM\DICOMND\
NightlyCleanThreshhold = 0# Configuration of mirror disk(s)
MIRRORDevices = 1
MIRRORDevice0 = \\n5200\usbhdd\fairdicom\NorthDakota\# Configuration of forwarding and/or converter programs to export DICOM slices
ForwardAssociationLevel = IMAGE
ForwardAssociationCloseDelay = 5
ForwardAssociationRefreshDelay = 3600
ForwardAssociationRelease = 0ExportConverters = 6
ExportConverter0 = forward patient age -1000+0 modality CR to FAIRLIGHT5
ExportConverter1 = forward to FAIRLIGHT5
ExportConverter2 = forward patient age -1000+0 modality CR to FAIRLIGHT6
ExportConverter3 = forward patient age -400+0 modality MG to FAIRLIGHT6
ExportConverter4 = forward to FAIRLIGHT6
ExportConverter5 = between "17", "06"; forward to risviewjhForwardCollectDelay = 300
MaximumExportRetries = 0
MaximumDelayedFetchForwardRetries = 0ignoreoutofmemoryerrors = 1
ForwardAssociationRelease = 1 -
How do you display the start address?
Marcel
-
I use a program called process explorer. It's free from Microsoft, used to be sysinternals before they were bought up by MS.
http://download.sysinternals.com/Files/ProcessExplorer.zip -
Hi,
can you copy the list of threads on a 'hanging' dgate, and can you show me the stack for the thread that takes a full cpu. Maybe ask for the stack a few times and see if it reproduces, and send me the copy.
In any case, I found that start address 0x1ad2 is a worker thread for a connection (started in DriverApp:Server).
This is a stack dump during a query:
ntoskrnl.exe!ExReleaseResourceLite+0x1a8
ntoskrnl.exe!PsGetContextThread+0x329
ntoskrnl.exe!KeSaveFloatingPointState+0x324
hal.dll+0x2c35
dgate.exe+0x121a4
dgate.exe+0x1435e8
dgate.exe+0x1a87I am not sure yet how to translate the addresses shown here into the addresses in dgate.map
Marcel
-
Will do, it may be a couple of days until the next hang.
-
I have been experiencing the same thing after upgrading to 1.4.14, and it also happens in 1.4.15alpha.
In both cases I am running on 64 bit windows on 8 cpu machine, it starts taking fully 2 cores, then 4, then 6 and finally all 8 cores.
I have not run older versions on the 64 bit windows server, and am not experiencing this on older 32 bit windows conquest 1.4.13.
(Changed the server and conquest version at the same time)This happens on 2 sites, on one of the sites, within 48 hours all 8 cores will be fully loaded. On the other site it takes weeks.
Best regards
steini, service engineer Iceland.
-
Forgot...
MySQL 64 bit. Used ODBC connector, am now trying the Native connection.
Best regards
steini.
-
Hi Steini,
can you get process explorer (see above) and get me the same stack information? AND show me your dicom.ini (exportconverters).
Marcel
-
Hi,
a main change in the worker thread between 1413 and 1414 is the start on storage commitment (not functional yet). This may screw things up. Can you look in the serverstatus and see if there is any line which says "hi" only? This is a message from the storage commitment code.
Marcel
-
Hello Marcel.
There is NO line that I could find the last 3 days in serverstatus that says "hi"
I tryed the sysinternals process explorer, but I need some instructions on how to use it
Below is my dicom.ini
(I discovered that I had debugging turned on, if that makes any difference, I will let you know)
Code# This file contains configuration information for the DICOM server# Do not edit unless you know what you are doing[sscscp]MicroPACS = sscscpEdition = Personal# Network configuration: server name and TCP/IP port#MyACRNema = ICSREMOTEBACKUPTCPPort = 5678# Reference to other files: known dicom servers; database layout; sopsACRNemaMap = acrnema.mapkFactorFile = dicom.sqlSOPClassList = dgatesop.lst# Host(ignored), name, username and password for ODBC data source# SQLHost = localhost# SQLServer = MFP_conquest# Username = xyz# Password = xyz# DoubleBackSlashToDB = 1# UseEscapeStringConstants = 0# Host, database, username and password for MySql databaseSQLHost = localhostSQLServer = conquestUsername = xyzPassword = xyzMySql = 1DoubleBackSlashToDB = 1UseEscapeStringConstants = 0# Configure databaseTruncateFieldNames = 10MaxFieldLength = 254MaxFileNameLength = 255FixPhilips = 0FixKodak = 0KeepAlive = 60LargeFileSizeKB = 16384PrintSquareLandscape = 0ZipTime = 05:UIDPrefix = 1.2.826.0.1.3680043.2.135.733381.56617265EnableReadAheadThread = 1PatientQuerySortOrder = StudyQuerySortOrder = SeriesQuerySortOrder = ImageQuerySortOrder = EnableComputedFields = 0IndexDBF = 1PackDBF = 0LongQueryDBF = 1000TCPIPTimeOut = 300FailHoldOff = 60RetryDelay = 100QueueSize = 128WorkListMode = 0WorkListReturnsISO_IR_100 = 1DebugLevel = 0Prefetcher = 0LRUSort = AllowTruncate = DecompressNon16BitsJpeg = 1UseBuiltInDecompressor = 1IgnoreOutOfMemoryErrors = 0PadAEWithZeros = 0FileNameSyntax = 3# Configuration of compression for incoming images and archivalDroppedFileCompression = n4IncomingCompression = n4ArchiveCompression = as# Names of the database tablesPatientTableName = DICOMPatientsStudyTableName = DICOMStudiesSeriesTableName = DICOMSeriesImageTableName = DICOMImagesDMarkTableName = DICOMAccessUpdatesRegisteredMOPDeviceTable = RegisteredMOPIDsUIDToMOPIDTable = UIDToMOPIDUIDToCDRIDTable = UIDToCDRID# Banner and host for debug informationPACSName = ICSREMOTEBACKUPOperatorConsole = 127.0.0.1# Configure email of error messagesMailHost =MailPort = smtp MailSignon = MailFromName = MailRcptName1 = MailCollectTime = 1MailWaitTime = 10# Configuration of disk(s) to store imagesMAGDeviceThreshhold = 0MAGDevices = 2MAGDevice0 = F:\DICOM_MAG0\MAGDevice1 = G:\DICOM_MAG1\NightlyCleanThreshhold = 0And I added "loads" of "columns" to this server that only needs few hours to get to 100% cpu time.
(I needed some DICOM tags into the database.)
On the server that needs longer to reach 100% cpu time (some weeks) I only added 3 or 4 lines to DICOM.SQL (for e-Film)
My modified DICOM.SQL is here below.Code# InstitutionalDepartmentName in study (should officially be in series, but eFilm expects it in study)# Revision 8: Denormalized study table (add patient ID, name, birthdate) to show consistency problemsBest regards
steini.
-
Hi,
I do not believe adding columns to dicom.sql would affect this problem. To get the info from process explorer proceed as follows:
Start process explorer
Seek conquestdicomserver.exe
Seek dgate.exe below it
double click dgate.exe
click tab page threads (there is a warning somewhere - ignore it)
find the thread that consumes 100% (1/N) CPU
double click it to show the stack
select all lines
push copy
here is what it looks like:ntkrnlpa.exe!KiUnexpectedInterrupt+0xbc
ntkrnlpa.exe!PsLookupThreadByThreadId+0x4aaa
ntkrnlpa.exe!KiDeliverApc+0xb3
hal.dll+0x2ef2
dgate.exe+0x1204a
dgate.exe+0x1457a8
dgate.exe+0x1a82Hope you can catch the hanging thread this way.
Marcel
-
Hi,
I have encountered a similar problem when using 1.4.14 release. It seems to be related to the number of export converters and or import converters.
This observation comes from the fact that it appeared in my setup when I started using more than 3. This went away when I reduced this to 3. Maybe you can try reducing the numbers and see
if it resolves the problemajg
-
Hello Marcel.
Sorry for my late reply, I have been really busy lately.
I have spent some time on this now and have some additional info.
I have NO export or inport converters (see dicom.ini file in previous post)
I had to get the server working this afternoon (release the cpu from 100%) so I killed and restarted the server.
It is now 4 hours later at 14% cpu time, one core running full time, how ever this load has jumped between all the cores in about 30 minutes (only stopping for few seconds on 2 of them). Process ID (PID) did not change (4308)This might also be related to SQL writing errors, this server has loads of them for some reason.
I have turned on debugging now to figure out a little more about the SQL errors.
(Since I restarted it I have had SQL errors)Code20090514 20:38:47 *** connection terminated20090514 20:39:31 *** connection terminated20090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000001_12423335720000.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000002_12423335720001.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000003_12423335720002.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000004_12423335720003.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000005_12423335720004.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000006_12423335720005.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000007_12423335720006.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000008_12423335720007.v220090514 20:40:15 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000001_12423336150008.v220090514 20:40:15 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000002_12423336150009.v220090514 20:40:15 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000003_1242333615000a.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000004_1242333616000b.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000005_1242333616000c.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1242333616000d.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1242333616000e.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1242333616000f.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000001_12423336370010.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000002_12423336370011.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000003_12423336370012.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000004_12423336370013.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000005_12423336370014.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000006_12423336370015.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000007_12423336370016.v220090514 20:40:53 Inconsistent StudyTime in DICOMStudies: PatientID = 'uuuuuuuuuu' StudyInsta = '1.2.392.200036.9116.7.8.6.48513238.5.0.198671771682584', Old='090058.343000', New='090058'20090514 20:40:53 Inconsistent StudyModal in DICOMStudies: PatientID = 'uuuuuuuuuu' StudyInsta = '1.2.392.200036.9116.7.8.6.48513238.5.0.198671771682584', Old='US', New='SR\\US'Images sent to this server are LARGE 20MB or so each (Mammograpy images), but not that many. (less than 1000 images each day)
About the Process explorer.
I tryed opening up ConquestDICOMserver.exe but under that there was no CPU usage.
I found the CPU usage under dgate64.exe - It keeps changing, these below were taken with approx 10 seconds between....
I sure hope this is helpful in figuring out what is going on.
Best regards
steini.
-
Hi Steini,
these are the correct dumps. I hope to get a few more from the others as well. By the way, we have seen this problem in our hospital as well, after I asked.
Marcel
-
Hi,
Digging a little into debugging on vista64 bits: this download will allow you to give me more info from the 64 bit version:
ftp://ftp-rt.nki.nl/outbox/Mar…er/dgate64withsymbols.zip
Is the server core (64 bits), with debug information (pdb file). If you place both in the dicomserver directory, process explorer will show you symbols for the thread stack - that makes it much easier for me to find the culprit!
And here is the same set for 32 bits:
ftp://ftp-rt.nki.nl/outbox/Mar…rver/Dgate32withdebug.zip
Stack traces with these versions would be highly appreciated.
By the way, these server cores contain debug information but are identically optimized, so performance should be identical.
Thanks,
Marcel
-
Hi Marcel.
I have been really busy last couple of days, sorry for late reply.
I found out what is causing the SQL write errors (a program that changes Pat ID without modifing UID´s)
They are retried every now and then. I am wondering if that causes the dgate64.exe process to hang
(because I have similar setup in another location that does NOT hang so frequently)
I will now "cleanup" the mess so that the images can be sent from the archive that keeps trying to send them.On to the debug versions of Dgate.
I replaced dgate64.exe with the one in the .zip file and the .pdb file is there as well.
Killed the server and waited (about 2 hours)Now I have 2 "cpus" at 100%.
But I cant see any difference in the Stack data (maybe you can) (will post "stack" below)
The Dgate64.exe taking up the cpu time is under DgateServ.exe (running as service) see below.
[Blocked Image: http://www.skrani.com/conquest/ProcessExplorer.GIF]
Stack data - Again it keeps changing....
I hope this helps (guess not though)
Best regards
steini. -
Found one more thing...
in the PacsTrouble.log file there are these 2 lines (I have 2 hanging Cores now)
20090529 21:35:07 *** connection terminated
20090529 21:36:45 *** connection terminatedand in the log at the same time...
5/29/2009 8:54:04 PM killed and restarted the server
5/29/2009 8:55:38 PM killed and restarted the server
5/29/2009 9:35:07 PM [ICSREMOTEBACKUP] *** connection terminated
5/29/2009 9:36:45 PM [ICSREMOTEBACKUP] *** connection terminated
5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000001_12436330260000.v2
5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000002_12436330260001.v2
5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000003_12436330260002.v2
5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000004_12436330260003.v2
5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000005_12436330260004.v2
5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000006_12436330260005.v2
5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000007_12436330260006.v2
5/29/2009 9:38:35 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000001_12436331150007.v2
5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000002_12436331160008.v2
5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000003_12436331160009.v2
5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000004_1243633116000a.v2
5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000005_1243633116000b.v2
5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1243633116000c.v2
5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1243633116000d.v2
5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1243633116000e.v2
5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000001_1243633143000f.v2
5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000002_12436331430010.v2
5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000003_12436331430011.v2
5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000004_12436331430012.v2
5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000005_12436331430013.v2
5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000006_12436331430014.v2
5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000007_12436331430015.v2Will fix the PatID - UID collision and see if that helps keeping the server cpu load down.
Best regards
steini. -
Hi,
Strange the the PDB does not give debug info in process explorer - it does for me. Maybe it depends on a part of visual studio 2008. The '*** connection terminated' message is interesting. Can you show a more complete log around this line?
Marcel
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!