SQL Server connection from Windows Exit with Code 1

ptotushek

@Garry - Trying out the new SQL Server Connection to our dedicated SQL Server. When I connect to it from my Mac, it connects, and the tests that I've done so far work great. I tried the same test program from a Windows machine and as soon as it tries to connect to our SQL Server I get an Error - App exited with code 1. Even within a Try/Catch. I then tried the Example SQL Server app, and again it worked from the Mac, and I got the same Error - App exited with code 1 from my Windows machine.

@bgrommes were you able to do any testing yet? I don't know what else to try from my Windows machine as the error is not descriptive.

bgrommes

ptotushek No I'm waiting for a workaround for Windows Server. Can't specify the install drive with an .msix file and I'm short on space on C: -- this may actually in theory be an issue for anyone, it isn't Server specific, probably just more common there as an Azure VM of Windows server, and potentially other similar offerings, tends to specify a rather basic capacity for C: and then you add network attached storage under other drive letters and if you have a lot of apps to install you don't put them on C: -- I also moved my default downloads folder off C:, etc.

The other thing, which I could work around but for the above issue, is that you can't do a simple double-click install from an .msix on Server because it doesn't support the Windows Store architecture. It just requires a couple of config settings and install via PowerShell.

Garry

ptotushek Do you get any more detailed output in Studio's Console panel when you get the crash that you could share?

ptotushek

Hi Gary,

Here is the output from that window...

Fatal VM exception: System.TypeLoadException
at Interop.Windows.Sni.SniNativeMethods.SNIAddProviderWrapper(SNIHandle pConn, Provider provider, AuthProviderInfo& pInfo)
at Interop.Windows.Sni.SniNativeMethods.SniAddProvider(SNIHandle pConn, Provider provider, AuthProviderInfo& pInfo)
at Microsoft.Data.SqlClient.SniNativeWrapper.SniAddProvider(SNIHandle pConn, Provider provNum, AuthProviderInfo& pInfo)
at Microsoft.Data.SqlClient.TdsParserStateObjectNative.EnableSsl(UInt32& info, Boolean tlsFirst, String serverCertificateFilename)
at Microsoft.Data.SqlClient.TdsParser.EnableSsl(UInt32 info, SqlConnectionEncryptOption encrypt, Boolean integratedSecurity, String serverCertificateFilename)
at Microsoft.Data.SqlClient.TdsParser.ConsumePreLoginHandshake(SqlConnectionEncryptOption encrypt, Boolean trustServerCert, Boolean integratedSecurity, Boolean& marsCapable, Boolean& fedAuthRequired, Boolean tlsFirst, String serverCertificateFilename)
at Microsoft.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlConnectionInternal connHandler, TimeoutTimer timeout, SqlConnectionString connectionOptions, Boolean withFailover)
at Microsoft.Data.SqlClient.Connection.SqlConnectionInternal.AttemptOneLogin(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, TimeoutTimer timeout, Boolean withFailover)
at Microsoft.Data.SqlClient.Connection.SqlConnectionInternal.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout)
at Microsoft.Data.SqlClient.Connection.SqlConnectionInternal.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance)
at Microsoft.Data.SqlClient.Connection.SqlConnectionInternal..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, DbConnectionPoolGroupProviderInfo providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnec
tionOptions, SessionData reconnectSessionData, Boolean applyTransientFaultHandling, String accessToken, IDbConnectionPool pool, Func3 accessTokenCallback, SspiContextProvider sspiContextProvider) at Microsoft.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionPoolGroupProviderInfo poolGroupProviderInfo, IDbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions) at Microsoft.Data.SqlClient.SqlConnectionFactory.CreatePooledConnection(DbConnection owningConnection, IDbConnectionPool pool, DbConnectionPoolKey poolKey, DbConnectionOptions options, DbConnectionOptions userOptions) at Microsoft.Data.SqlClient.ConnectionPool.WaitHandleDbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) at Microsoft.Data.SqlClient.ConnectionPool.WaitHandleDbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) at Microsoft.Data.SqlClient.ConnectionPool.WaitHandleDbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) at Microsoft.Data.SqlClient.ConnectionPool.WaitHandleDbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource1 taskCompletionSource, DbConnectionOptions userOptions, DbConnectionInternal& connection)
at Microsoft.Data.SqlClient.SqlConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) at Microsoft.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, SqlConnectionFactory connectionFactory, TaskCompletionSource1 retry, DbConnectionOptions userOptions)
at Microsoft.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, SqlConnectionFactory connectionFactory, TaskCompletionSource1 retry, DbConnectionOptions userOptions) at Microsoft.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource1 retry)
at Microsoft.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource1 retry, SqlConnectionOverrides overrides) at Microsoft.Data.SqlClient.SqlConnection.Open(SqlConnectionOverrides overrides) at Microsoft.Data.SqlClient.SqlConnection.Open() at Objo.StdLib.SQLServerDatabaseConnection.<>c__DisplayClass18_0.<Open>b__0() at Objo.StdLib.SQLServerDatabaseErrors.<>c__DisplayClass1_0.<Wrap>b__0() at Objo.StdLib.SQLServerDatabaseErrors.Wrap[T](Func1 action, String query)
at Objo.StdLib.SQLServerDatabaseErrors.Wrap(Action action, String query)
at Objo.StdLib.SQLServerDatabaseConnection.Open(DatabaseConnectionOptions options)
at Objo.StdLib.DatabaseConnectionMethods.ConnectInternal(ObjoInstance instance, DatabaseConnectionState state)
at Objo.StdLib.DatabaseConnectionMethods.<>cDisplayClass1_0.<Register>b0(VM _, ReadOnlySpan`1 args)
at Objo.VM.VM.Run(Int32 exitAtFp)
at Objo.VM.VM.InvokeMethod(ObjoClosure method, Value receiver, Value[] args, Boolean allowWhileStopRequested)
at Objo.StdLib.Desktop.ControlMethods.CallEventHandler(VM vm, ObjoInstance eventSource, Value handler, Value[] args)
at Objo.StdLib.Desktop.ControlMethods.FireEvent(VM vm, ObjoInstance instance, String declaringTypeName, String eventName)
at Objo.StdLib.Desktop.ControlMethods.FireEvent(VM vm, ObjoInstance instance, String eventName)
at Objo.StdLib.Desktop.ButtonMethods.<>cDisplayClass0_0.<Register>b7(VM _)
at Objo.VM.VM.ProcessPendingCallbacks()
at Objo.VM.VM.WaitForDesktopExit()
at Objo.VM.VM.RunApplicationEntryPoint()
at Objo.VM.VM.Execute(ObjoClosure closure)
at Objo.Host.Desktop.Program.<>c_DisplayClass0_0.<Main>b__5()

Garry

@ptotushek Thanks for the console dump. That identified the problem.

This was not a SQL Server login/query issue, and there is nothing wrong with your connection string. The crash was happening inside Microsoft.Data.SqlClient's Windows SNI layer while opening the connection. That path is Windows-specific, which explains why the same project worked on macOS.

I think the root cause was Objo's published Windows runtime being trimmed while SQL Server support was included. Microsoft.Data.SqlClient's native Windows SNI provider is not trim-safe, so the runtime could throw System.TypeLoadException during SQLServerDatabase.Connect.

I've fixed this for the next build:

Apps/runtimes that use SQLServerDatabase will no longer be published with trimming enabled.
Apps that do not use SQL Server will still be trimmed as before.
If the SQL Server provider fails to load in future, Objo will report it as a catchable database error instead of an uncaught fatal VM exception, so Try/Catch should behave properly.

https://feedback.objo.dev/bug/541

bgrommes

Garry Is it possible a similar issue could exist in projects that use introspection? ISTR that using reflection on the .NET side can cause such issues, so to whatever extent introspection delegates to the .NET reflection APIs, you may have to disable trimming.

I also have a vague recollection that you can use attributes to protect particular code paths from trimming, which might avoid an all-or-nothing, go/no go decision here, or at least you could refine around that later.

ptotushek

Excellent - Thank you Gary!

Garry

Good question. Objo introspection should not have the same failure mode as .NET reflection under trimming. TypeInfo(), HasMethod(), HasProperty(), Invoke(), etc. inspect Objo's own VM/compiler metadata - ObjoClass, ObjoClosure, native member metadata, and it's built-in type registry - rather than reflecting over the published .NET host assembly.

The related publishing concern is optional native stdlib support. Since introspection can resolve names from runtime strings, the feature detector is deliberately conservative when those APIs are used and keeps the optional stdlib slices rather than risking a publish-only missing type/member. On Windows, if SQLServerDatabase is included, the generated host now disables trimming because Microsoft.Data.SqlClient's Windows SNI path is not trim-safe.

So the SQL Server fix is provider-specific, not a general sign that Objo introspection itself needs trimming disabled. Trimming attributes may still be useful later for specific C# library paths, but they're not needed for Objo user-code introspection.