When upgrading Entity Framework Core dependencies in an isolated Azure Functions worker project, you might encounter an unexpected crash during local debugging. While everything worked seamlessly on previous package revisions, testing your data queries locally now fails with an authentication exception:

Microsoft.Data.SqlClient.SqlException: Failed to acquire access token for ActiveDirectoryInteractive: A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handles
Fehlercodecode 0xwindow_handle_required

This article breaks down why this error occurs after updating EF Core and provides modern, robust solutions to authenticate against Azure SQL both locally and in production.

Why Does This Error Happen?

When you specify Authentication=Active Directory Interactive in your connection string, Microsoft.Data.SqlClient relies on the Microsoft Authentication Library (MSAL.NET) to negotiate authentication tokens.

In newer releases of Microsoft.Data.SqlClient (transitively pulled in by EF Core updates), MSAL defaults to using the Web Account Manager (WAM) broker on Windows. WAM requires an operating system window handle (HWND / IntPtr) to anchor the interactive modal dialog.

Because an Azure Functions Isolated Worker runs as a headless console application via the Azure Functions Core Tools host, there is no top-level graphical window handle available. MSAL fails to attach the login window to a parent process and throws the 0xwindow_handle_required exception.

Solution 1: Switch to Active Directory Default (Recommended)

The cleanest and most modern approach is to update your connection string to use Authentication=Active Directory Default instead of Active Directory Interactive.

Starting with Microsoft.Data.SqlClient 3.0 and newer, Active Directory Default delegates token retrieval to DefaultAzureCredential from the Azure.Identity library. It automatically checks credentials in a seamless order:

  • Locally: It pulls identity tokens from your active Visual Studio login, Visual Studio Code Azure Account, or the Azure CLI (az login).
  • In Azure: It automatically authenticates via your App Service / Function App Managed Identity.

1. Update your local.settings.json

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "SqlConnectionString": "Server=tcp:your-server.database.windows.net,1433;Database=your-db;Authentication=Active Directory Default;TrustServerCertificate=False;Encrypt=True;"
  }
}

2. Ensure your local environment is authenticated

Before launching local debugging, make sure you are signed in using any of the following:

  • Visual Studio: Tools > Options > Azure Service Authentication > Account Selection.
  • Azure CLI: Run az login in your terminal.
  • Azure PowerShell: Run Connect-AzAccount.

Because this flow relies on silent or CLI-based token caching, no browser popup or window handle is required, completely avoiding the WAM exception.

Solution 2: Pass an Azure Token Programmatically with DefaultAzureCredential

If you prefer full programmatic control over token acquisition in EF Core, configure an Azure.Identity token provider callback when registering your DbContext. This completely decouples authentication from the connection string syntax.

First, install the Azure.Identity package:

dotnet add package Azure.Identity

Then configure your DbContext in Program.cs:

using Azure.Core;
using Azure.Identity;
using Microsoft.Data.SqlClient;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices((context, services) =>
    {
        services.AddDbContext<ApplicationDbContext>((serviceProvider, options) =>
        {
            var connectionString = context.Configuration["SqlConnectionString"];
            
            // Build connection with standard connection string (no Authentication keyword needed)
            var sqlConnection = new SqlConnection(connectionString)
            {
                AccessTokenCallback = async (authParams, cancellationToken) =>
                {
                    var credential = new DefaultAzureCredential();
                    var tokenRequestContext = new TokenRequestContext(new[] { "https://database.windows.net/.default" });
                    var token = await credential.GetTokenAsync(tokenRequestContext, cancellationToken);
                    return token.Token;
                }
            };

            options.UseSqlServer(sqlConnection);
        });
    })
    .Build();

await host.RunAsync();

Solution 3: Pin or Downgrade Microsoft.Data.SqlClient (Temporary Workaround)

If you need an immediate workaround without modifying code or connection strings while working under a tight deadline, you can explicitly pin Microsoft.Data.SqlClient to an earlier patch version in your .csproj that used legacy system browser fallbacks:

<ItemGroup>
  <PackageReference Include="Microsoft.Data.SqlClient" Version="5.1.5" />
</ItemGroup>

Note: This is only recommended as a stopgap. Migrating to Active Directory Default or Azure.Identity is the long-term supported path for .NET microservices and serverless functions.

Summary

Updating EF Core pulls in updated versions of Microsoft.Data.SqlClient where Active Directory Interactive relies on WAM and strictly enforces window handles. Changing your local connection string to Authentication=Active Directory Default will resolve the issue immediately, ensuring seamless local debugging and secure deployments via Managed Identities.