SQL Compare program does not exit completely.

[skuhn]

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

[Brian Donahue]

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.
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521

[skuhn]

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 Donahue]

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.
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521

[skuhn]

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 Donahue]

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.
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521