High CPU

    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?

    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 = 0


    ExportConverters = 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 risviewjh


    ForwardCollectDelay = 300
    MaximumExportRetries = 0
    MaximumDelayedFetchForwardRetries = 0



    ignoreoutofmemoryerrors = 1
    ForwardAssociationRelease = 1

    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+0x1a87


    I am not sure yet how to translate the addresses shown here into the addresses in dgate.map


    Marcel

    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.

    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   = 0



    And 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.





    Best 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+0x1a82


    Hope 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 problem


    ajg

    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)


    Code
    20090514 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....

    Code
    ntoskrnl.exe+0x549c5dgate64.exe+0x14fafc


    Code
    ntoskrnl.exe+0x549c5dgate64.exe+0x279f0dgate64.exe+0x33aeadgate64.exe+0x55db8dgate64.exe+0x33aeadgate64.exe+0x1896c0


    Code
    ntoskrnl.exe+0x549c5

    dgate64.exe+0x279f0

    dgate64.exe+0x33aea

    dgate64.exe+0x55db8

    dgate64.exe+0x33aea

    dgate64.exe+0x1896c0


    I sure hope this is helpful in figuring out what is going on.


    Best regards


    steini.

    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....

    Code
    ntoskrnl.exe+0x549c5dgate64.exe+0x1f5282dgate64.exe+0x442d8


    Code
    ntoskrnl.exe+0x549c5dgate64.exe+0x5539ddgate64.exe+0x82b86dgate64.exe+0x553badgate64.exe+0x2426c0


    Code
    ntoskrnl.exe+0x549c5

    dgate64.exe+0x44150

    dgate64.exe+0x553ba

    dgate64.exe+0x82c58

    dgate64.exe+0x553ba

    dgate64.exe+0x2426c0


    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 terminated


    and 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.v2


    Will 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!

Register Yourself Login