SQL Connection w/Kerberos - Linux Ubuntu - Error Code 139

[ebeltran1981]

Description

I'm upgrading an app from .NET 5 to 6. Our SQL servers supports Kerberos. In Windows and macOS the .NET 6 upgraded app works fine, but in Linux Ubuntu 20.04 the dotnet watch run shows: watch : Exited with error code 139 when the app tries to execute a query against the SQL server.

The connection string I am using is this:

"Server=our-sql-server.com;Database=our-db;MultipleActiveResultSets=True;Max Pool Size=300;Trusted_Connection=True;"

Configuration

• Which version of .NET is the code running on? 6.0.102
• What OS and version, and for Linux, what distro? Linux Ubuntu 20.04
• What is the architecture (x64, x86, ARM, ARM64)? x64
• Do you know whether it is specific to that configuration? I tried on a Mac Mini w/ M1 and Dell w/ i7 and works fine

Regression?

• Did this work in a previous build or release of .NET, or from .NET Framework? I tried it with .NET 5.0.405 and works fine everywhere.

Other information

About the stack trace, there is none. When run with debug it simply dies with no message. When run with dotnet run it just quits with no error. When run with dotnet watch run it shows: watch : Exited with error code 139.

I do not have any works around. I've been trying different connections strings options, but no luck!

With this simple app throws the error:

using Microsoft.EntityFrameworkCore;

var contextOptions = new DbContextOptionsBuilder<AppDbContext>()
    .UseSqlServer(@"Server=our-sql-server.com;Database=our-db;MultipleActiveResultSets=True;Max Pool Size=300;Trusted_Connection=True;")
    .Options;

await using var context = new AppDbContext(contextOptions);
var response = await context.Database.ExecuteSqlRawAsync("SELECT * FROM AnyTable"); // <-- this makes the app crash with no message

Console.WriteLine(response);

internal class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options)
    {
        
    }
}

[danmoseley]

maybe #1390

[ebeltran1981]

maybe #1390

@danmoseley my google skills failed me on this one. Thanks for the issue #.

[danmoseley]

@ebeltran1981 no problem, there are many dupes - it's confusing. The workarounds are either change to Microsoft.SqlClient (nice if it's an option, as it's where new features are shipped) or stay on 5.0 (goes out of support in May) or paste in something like this until it's serviced in System.Data.SqlClient 6.0

[ebeltran1981]

@danmoseley thanks a lot!