SQL Compare program does not exit completely.

skuhnskuhn Posts: 27 Bronze 3
edited April 16, 2012 11:22AM in SQL Compare Previous Versions
Hi,
I just happened to look at the Task Manager today and found that I had five instances of RedGate.SQLCompare.UI.exe running, though I had no visual instances running. I likely ran SQL Compare five times yesterday and though I closed it each time, it appears that some thread is still alive despite having closed the application.

I'm running Windows 7 64-Bit, SQL Compare 10.1.0.102 Professional Edition, SQL Server 2005/2008, Source Gear Vault 5.1.

Considering I've had other issues with SQL Compare complaining about being unable to delete files, I wonder if this is related. (I'm thinking that the instances that will not close out are holding onto files.)

Thanks,
Scott Kuhn

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hi Scott,

    I suspect there is a potential problem caused if you have an error in SQL Compare. If you get an error dialog, SQL Compare should terminate the main UI thread and that should also kill all of the background threads. However, if the threads were not properly configured as "background" by us, they may be left behind.

    If you still have this problem, please let me know and I will send instructions to attach a debugger and we'll see what these threads are actually doing and hopefully I can trace that back to some code and have a look.
  • skuhnskuhn Posts: 27 Bronze 3
    Hi Brian,
    I've used the Red Flag debugger before. I generated a trace/debug file this morning if you want to send me instructions on how to send it then I will.

    Basically all I did was open a project and run the compare. I did not have any differences so I just stopped there and closed SQL Compare. However, it was still running in the background. I detached the debugger at that point and saved the file.

    Thanks,
    Scott
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hi Scott,

    I think in this case you want to attach to the zombie SQL Compare and then use Actions->Dump Stacks and CTRL-C and paste into an email.

    I should be able to decode the "nonsense" stack trace and find the offending thread.
  • skuhnskuhn Posts: 27 Bronze 3
    Possibly related to Vault...


    Attached to pid:9088

    Thread 3820 [Status=Wait UserTime=15 Wait Reason=UserRequest]
    Callstack for Thread 3820

    Thread 4308 [Status=Wait UserTime=0 Wait Reason=UserRequest]
    Callstack for Thread 4308
    System.Threading.WaitHandle.WaitOne (source line information unavailable)
    System.Threading.WaitHandle.WaitOne (source line information unavailable)
    System.Threading.WaitHandle.WaitOne (source line information unavailable)
    System.Management.MTAHelper.WorkerThread (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart_Context (source line information unavailable)
    System.Threading.ExecutionContext.Run (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart (source line information unavailable)

    Thread 8080 [Status=Wait UserTime=31 Wait Reason=EventPairLow]
    Callstack for Thread 8080

    Thread 9256 [Status=Wait UserTime=0 Wait Reason=UserRequest]
    Callstack for Thread 9256

    Thread 9408 [Status=Wait UserTime=0 Wait Reason=ExecutionDelay]
    Callstack for Thread 9408

    Thread 1004 [Status=Wait UserTime=0 Wait Reason=ExecutionDelay]
    Callstack for Thread 1004
    System.Drawing.ImageAnimator.AnimateImages50ms (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart_Context (source line information unavailable)
    System.Threading.ExecutionContext.Run (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart (source line information unavailable)

    Thread 7708 [Status=Wait UserTime=15 Wait Reason=ExecutionDelay]
    Callstack for Thread 7708
    VaultClientOperationsLib.WatcherThread.Start (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart_Context (source line information unavailable)
    System.Threading.ExecutionContext.Run (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart (source line information unavailable)

    Thread 5280 [Status=Wait UserTime=0 Wait Reason=ExecutionDelay]
    Callstack for Thread 5280
    VaultClientOperationsLib.WatcherThread.Start (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart_Context (source line information unavailable)
    System.Threading.ExecutionContext.Run (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart (source line information unavailable)

    Thread 5344 [Status=Wait UserTime=639 Wait Reason=UserRequest]
    Callstack for Thread 5344

    Thread 7672 [Status=Wait UserTime=0 Wait Reason=ExecutionDelay]
    Callstack for Thread 7672
    VaultClientOperationsLib.WatcherThread.Start (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart_Context (source line information unavailable)
    System.Threading.ExecutionContext.Run (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart (source line information unavailable)

    Thread 9248 [Status=Wait UserTime=0 Wait Reason=ExecutionDelay]
    Callstack for Thread 9248
    VaultClientOperationsLib.WatcherThread.Start (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart_Context (source line information unavailable)
    System.Threading.ExecutionContext.Run (source line information unavailable)
    System.Threading.ThreadHelper.ThreadStart (source line information unavailable)
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Sorry, we are not able to work out why this is happening to you. Closing the program window should terminate all threads, even if they are executing. I'm vaguely aware that if there is an exception on one of the threads, it may be left hanging - however that should only leave one thread as far as I know.
Sign In or Register to comment.