We have a problem in our test runs that use Sap.Data.SQLAnywhere. The test run never finishes.

Each test case finishes, but the vstest.console execution never finishes because it's waiting on an instance of Sap.Data.SQLAnywhere.SAUnmanagedDll's finalizer.

Here's a C# repro, as far as I can narrow it down:

using System;
using System.Data.Common;

class Repro : MarshalByRefObject
    public string Get()
        using (var connection = DbProviderFactories.GetFactory("Sap.Data.SQLAnywhere").CreateConnection())

            connection.ConnectionString = "Host=MyServer;DatabaseName=Northwind;Integrated=True";
            //TODO Uncomment connection.ConnectionString += ";Pooling=False";


        return "DONE";

    public static void Main(string[] args)
        AppDomainSetup newSetupInfo = new AppDomainSetup
            ApplicationBase = typeof(Repro).Assembly.Location

        AppDomain testDomain = null;
            testDomain = AppDomain.CreateDomain("TestDomain");

            Repro remoteObj = (Repro)testDomain.CreateInstance(

            Console.WriteLine("BEFORE TEST");
            Console.WriteLine("AFTER TEST");
            if (testDomain != null)
                Console.WriteLine("BEFORE UNLOAD");
                Console.WriteLine("AFTER UNLOAD");

If you compile and run this against .NET 3.5, it prints "BEFORE UNLOAD" but then hangs at the call to AppDomain.Unload().

If I pause in the managed debugger, the .NET finalizer thread has made an unmanaged call at Sap.Data.SQLAnywhere.v3.5.dll!Sap.Data.SQLAnywhere.SAUnmanagedDll.Finalize(). For whatever reason, this call hanging is blocking the finalizer thread.

In the unmanaged debugger, the call stack is:

ntdll.dll!_RtlEnterCriticalSection@4() Unknown
dbdata17.dll!0f49918f() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for dbdata17.dll]  
dbdata17.dll!0f49a22c() Unknown
dbdata17.dll!0f498d18() Unknown
dbdata17.dll!0f49c037() Unknown
[Managed to Native Transition]  
Sap.Data.SQLAnywhere.v3.5.dll!<Unknown function>    Unknown

(If you uncomment the //TODO to disable connection pooling, then Unload() is instant.)

My version of Sap.Data.SQLAnywhere is Sap.Data.SQLAnywhere.v3.5, Version=

It also (hangs on both .NET 4.5, which loads Sap.Data.SQLAnywhere.v4.5, Version= )

Is this a bug in Sap.Data.SQLAnywhere? Is there a way to fix the finalizer hang without disabling connection pooling? Is there some other workaround that would prevent the Unload() hang ?

asked 14 Oct '15, 20:04

carlwalsh's gravatar image

accept rate: 0%

edited 14 Oct '15, 21:02

I don't know whether that is a bug or not, but you can check yourself if it is contained in the latest (and first) released v17 EBF here:


(15 Oct '15, 05:58) Volker Barth

Update: This issue has been fixed as of and will be released in upcoming support packages.

Thanks for the concise reproducible - I can also reproduce this using a blank database, without Integrated Logins enabled:

dbinit -dba dba,sql -mpl 3 demo17.db
dbsrv17 demo17.db

connection.ConnectionString = "uid=dba;pwd=sql;server=demo17";

I also can confirm that it seems that disabling connection pooling changes the hang behaviour - I would recommend using that workaround until we can better understand the interaction and provide a fix.

I have opened CR #791082 to investigate further.

permanent link

answered 15 Oct '15, 12:37

Jeff%20Albion's gravatar image

Jeff Albion
accept rate: 24%

edited 19 Oct '15, 12:01

I don't know what difference pooling=true or pooling=false could make since connection pooling really doesn't pool integrated logins in the current implementation and the pooling implmentation should be independent of the unmanaged code where the hang seems to be occuring.

So if disabling connection pooling would be a viable interim solution to this issue until it can be investigated in more detail. {... at which point I would recommend opening up a support incident and provide your example code and database for review...}

I did notice you do not have a catch block in the main part of your code, so might this have something to do with an unhandled exception and side-effects from that maybe? Also if there is something special around the way you have your integrated logins set up and mapped, that may be important to know.

There have been some recent corrections made to our integrated login support around group membership but I don't recognize this as being a matching symptom of any of that.

Either way the fact that pooling is playing any role in any of this seems very odd and unexpected.


permanent link

answered 15 Oct '15, 09:23

Nick%20Elson%20SAP%20SQL%20Anywhere's gravatar image

Nick Elson S...
accept rate: 32%

As @Jeff points out, this also reproduces with username and password auth, and in both cases turning off pooling fixes the problem.

(15 Oct '15, 14:34) carlwalsh
Your answer
toggle preview

Follow this question

By Email:




Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • numbered list: 1. Foo 2. Bar
  • basic HTML tags are also supported

Question tags:


question asked: 14 Oct '15, 20:04

question was seen: 2,307 times

last updated: 19 Oct '15, 12:01