Fix: 'Microsoft.ACE.OLEDB.12.0' Provider Is Not Registered on the Local Machine (Windows 10/11)

The error "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine" appears when your .NET application tries to open an Excel, Access or CSV file through OLE DB and Windows can't find a matching provider. The older 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine variant has the same symptom but a slightly different cause.

This article explains why the error happens, how to confirm which case you are in, and how to fix it in C# and VB.NET projects, IIS applications, SSIS packages and the SQL Server Import and Export Wizard.

You will typically see one of these two messages when reading or writing Excel, CSV, Access or text files from a desktop or web application:

1. The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine
2. The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine

The error is not tied to a Visual Studio version. It shows up in projects built with Visual Studio 2010 through the current release, and on Windows 10 and Windows 11 alike.

Why the 'Microsoft.ACE.OLEDB.12.0' Provider Is Not Registered

OLE DB is a Windows data-access API. A provider is a native component that knows how to talk to one kind of data source. Two providers matter here:

• Microsoft.Jet.OLEDB.4.0 (Jet) is the legacy provider for .mdb and .xls files. It exists only as a 32-bit component. There is no 64-bit Jet.
• Microsoft.ACE.OLEDB.12.0 (ACE, the Access Database Engine) is the successor. It reads .xls, .xlsx, .xlsm, .xlsb, .mdb and .accdb files, and it is not installed with Windows. It comes with Microsoft Office, the Access Runtime, or the standalone Access Database Engine redistributable.

Windows registers each provider separately for 32-bit and 64-bit processes. The error therefore means one of two things:

• The provider is not installed at all.
• The provider is installed, but with a different bitness than the process trying to use it. For example, your app runs as 64-bit but only the 32-bit engine is installed, or the reverse.

Here, bitness simply means whether something is 32-bit (x86) or 64-bit (x64). The bitness that matters is that of your running process, not of Windows. A project set to Any CPU runs as 64-bit on 64-bit Windows unless "Prefer 32-bit" is enabled, and that is why the error so often appears on an otherwise normal machine.

Warning: OLE DB is a Windows COM technology. Even with the System.Data.OleDb package on modern .NET, it works on Windows only and not on Linux or macOS.

Quick Diagnosis: Which Fix Do You Need?

Your situation	Most likely fix
Provider is Microsoft.Jet.OLEDB.4.0	Build the app as x86 (Solution 1), or switch to ACE (Solution 3)
Provider is ACE and Office or the engine is already installed	Match your app's bitness to the installed engine (Solution 1)
Provider is ACE and nothing is installed	Install the Access Database Engine or Access Runtime (Solution 2)
Web app on IIS	Enable 32-bit applications on the app pool, or install the 64-bit engine
SSIS package or Import and Export Wizard	Run the 32-bit or 64-bit tool that matches the installed engine

Work through the solutions in order and stop as soon as the error disappears.

Solution 1: Match Your App's Platform Target to the Installed Engine

Use this solution if you have 32-bit Office or the 32-bit Access Database Engine installed. In that case, make your application run as a 32-bit process by changing the target CPU from Any CPU to x86. This is also the only fix that works for the Jet provider, since Jet has no 64-bit version.

If you have the 64-bit version installed, do the opposite. Your application should target x64, or Any CPU with "Prefer 32-bit" unchecked. Forcing x86 there would cause the very error you are trying to fix.

Steps in Visual Studio

Step 1: Open your project in Visual Studio, then right-click the project name in Solution Explorer.

Step 2: Choose Properties.

Step 3: In the properties window, open Build in the left panel and change Platform target from Any CPU to x86. In newer Visual Studio versions this setting is under Build > General. The screenshot below is from an older version, but the option is the same.

Step 4: Save with Ctrl + S, rebuild the project and run it again.

Other ways to force a 32-bit process

• Prefer 32-bit: In .NET Framework projects that stay on Any CPU, the "Prefer 32-bit" checkbox on the Build page makes the executable run as 32-bit on 64-bit Windows. The checkbox only takes effect when the platform target is Any CPU. With an explicit x86 or x64 target it does not apply.
• SDK-style projects (.NET 5 and later): "Prefer 32-bit" is a .NET Framework setting, so set the platform target instead. Add <PlatformTarget>x86</PlatformTarget> to the project file, shown below. OLE DB is available on modern .NET through the System.Data.OleDb NuGet package.
• Solution platform: Check Build > Configuration Manager. If the solution platform is still Any CPU or the project is not ticked for the x86 platform, your change may not be applied at build time.

<PropertyGroup>
  <PlatformTarget>x86</PlatformTarget>
</PropertyGroup>

Add the OLE DB package from the command line if you are on modern .NET:

dotnet add package System.Data.OleDb

Building as x86 only works if a 32-bit provider is actually installed. If it still fails, continue with Solution 2.

A note for Visual Studio 2022

Visual Studio 2022 is a 64-bit application, while Visual Studio 2019 and earlier were 32-bit. This matters for anything that runs inside the IDE, such as the Server Explorer or Data Sources windows. Those tools use the IDE's own bitness, so testing a connection there generally needs the 64-bit ACE provider, even if your project targets x86.

In practice, if only the 32-bit provider is installed, the IDE's connection dialogs may not list it, even though the same connection works in your running application. Your compiled application follows its own platform target, so it is normal for a connection to work in your running code but fail in an IDE dialog, or the other way round.

Solution 2: Install the Access Database Engine That Matches Your App

If the ACE provider is not installed, install one. Two Microsoft packages provide it:

• Microsoft Access Database Engine 2016 Redistributable is a standalone installer offered in x86 and x64 versions (accessdatabaseengine.exe and accessdatabaseengine_X64.exe). Microsoft's download page states that support for it ended on October 14, 2025, and recommends the Microsoft 365 Access Runtime as its replacement. It is still downloadable and widely used, but it no longer receives updates, so prefer the Access Runtime for new projects.
• Microsoft 365 Access Runtime is the currently recommended replacement. It includes the Access Database Engine with OLE DB and ODBC drivers, and is available in 32-bit and 64-bit versions.

The older Office 2007 and 2010 driver packages are no longer the recommended route. Use one of the two packages above instead.

"But I already have Microsoft 365 installed"

Having Office installed does not always make the OLE DB provider usable from your own application. Office installed with Click-to-Run can keep its components separate from the rest of Windows, so an outside program may not see them. Microsoft's Access Runtime page also notes that the Access Database Engine is not exposed to applications outside Office with the volume-license version of Office 2019, and recommends Office LTSC 2021 in that case.

If your PowerShell check (below) shows no ACE provider despite Office being installed, installing the Access Runtime or the redistributable is the usual fix. Two constraints from Microsoft's documentation apply:

• When you install the Access Runtime next to an existing Click-to-Run Office, it matches that Office installation's bitness.
• The Access Runtime is not compatible with Office products installed with Windows Installer (MSI).

Choose the right bitness

• Install the x86 engine if your process runs as 32-bit (for example, after Solution 1).
• Install the x64 engine if your process runs as 64-bit.
• Microsoft's instructions say to remove any previous version of the Access Database Engine through Add or remove programs before installing the 2016 redistributable.

When the installer blocks the engine you need

The 32-bit and 64-bit engines generally cannot be installed side by side. If 32-bit Office is installed, the 64-bit installer typically stops with a message like You cannot install the 64-bit version of Microsoft Access Database Engine because you have 32-bit Office products installed. The supported fix is to match your app to the bitness already on the machine, which usually means Solution 1.

The same conflict applies in reverse. If 64-bit Office is installed and your application must run as a 32-bit process, you typically can't install the 32-bit engine next to it either. In that case the practical options are to move your application to 64-bit, or to stop depending on OLE DB for Excel files (see the alternatives section below).

A workaround often mentioned online is to run the installer from a command prompt with the quiet switch:

accessdatabaseengine_X64.exe /quiet

Warning: Microsoft does not document this as a supported method. Forcing two bitnesses onto one machine can interfere with Office and its updates, so treat it as a last resort and avoid it on production or shared machines.

NOTE: If you are moving data between an Excel workbook and SQL Server, using the SQL Server Import and Export Wizard, C# or VB.NET, this is usually the solution you need. The wizard, SSIS and your own code all need an ACE provider whose bitness matches the tool that is running.

Solution 3: Use ACE Instead of Jet

If your connection string uses Microsoft.Jet.OLEDB.4.0 and you want to run as a 64-bit process, switch to the ACE provider. Jet cannot be installed as 64-bit, so this is the only route. The connection strings are almost identical:

File type	Provider	Extended Properties
.xls	Jet 4.0 or ACE	Excel 8.0
.xlsx	ACE only	Excel 12.0 Xml
.xlsm	ACE only	Excel 12.0 Macro
.xlsb	ACE only	Excel 12.0
.mdb / .accdb	Jet 4.0 (.mdb only) or ACE	Not required

Jet cannot open .xlsx or .accdb files at all, so an .xlsx file always needs ACE.

How to Check Which OLE DB Providers Are Registered

Instead of guessing, list the providers your machine actually has. The following PowerShell command shows the ACE and Jet providers visible to the shell you run it in:

Add-Type -AssemblyName System.Data

[System.Data.OleDb.OleDbEnumerator]::new().GetElements() |
    Where-Object { $_.SOURCES_NAME -like 'Microsoft.*OLEDB*' } |
    Select-Object SOURCES_NAME, SOURCES_DESCRIPTION

Run PowerShell as Administrator once in the regular 64-bit PowerShell and once in the 32-bit one. The easiest way to open the 32-bit shell is to type Windows PowerShell (x86) into the Start menu. It is a shortcut to C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe, which you can also run directly.

To confirm which shell you are in, run [Environment]::Is64BitProcess. It returns True in the 64-bit shell and False in the 32-bit one. Then compare the two lists:

• If the provider appears only in the 32-bit shell, your app must run as x86 (Solution 1).
• If it appears only in the 64-bit shell, your app must run as 64-bit.
• If neither shell lists an ACE provider, install one (Solution 2).

Checking the registry instead

If you can't run PowerShell, for example because of a restricted execution policy, you can look for the provider in the registry with Registry Editor. Provider registrations appear as keys named after the provider, such as Microsoft.ACE.OLEDB.12.0, Microsoft.ACE.OLEDB.16.0 or Microsoft.Jet.OLEDB.4.0:

• The 64-bit registrations are under HKEY_CLASSES_ROOT when you use the regular 64-bit Registry Editor.
• The 32-bit registrations on 64-bit Windows are under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes. Look for a subkey named after your provider, such as Microsoft.ACE.OLEDB.12.0.

If the key for your provider is missing in the relevant location, that provider is not registered for that bitness. If the key exists, it normally contains a CLSID subkey that points to the registered COM class. A key with a missing or empty CLSID subkey may indicate a broken registration, in which case repairing or reinstalling the engine is the next step. Registry Editor is a manual check, so treat the PowerShell result as the more direct answer where you can run it.

ACE 12.0 or 16.0?

Newer engines, such as the 2016 redistributable and the Microsoft 365 Access Runtime, are versioned 16.0. Many developers report that 12.0 connection strings still work against them, but this is not guaranteed on every machine, so don't rely on it.

The safest rule is to use the provider name that the PowerShell check lists on the machines where your app will actually run. If only Microsoft.ACE.OLEDB.16.0 is registered, change the provider name in your connection string:

Provider=Microsoft.ACE.OLEDB.16.0;

Changing the provider name does not mean changing the Extended Properties value. Keep the values from the table in Solution 3. For an .xlsx file, that value is still Excel 12.0 Xml, even when using the 16.0 provider.

If you are writing new code for machines you control and know they have the 16.0 engine, using 16.0 from the start avoids depending on 12.0 compatibility. If your app must run on machines with older engines, check what those machines have registered before choosing.

Complete Example: Read an Excel File With ACE and Diagnose the Error

The example below reads the first worksheet of an .xlsx file into a DataTable. If the provider is missing or has the wrong bitness, it prints the process bitness so you can see immediately which case you are in.

// On .NET 5 and later, first add the NuGet package: System.Data.OleDb
// (not needed on .NET Framework, where this namespace is built in)
using System;
using System.Data;
using System.Data.OleDb;

internal static class Program
{
    private static void Main()
    {
        // Change this to a real workbook path on your machine.
        string filePath = @"C:\Data\Employees.xlsx";

        // "Excel 12.0 Xml" is for .xlsx files. HDR=YES treats the first row as column names.
        string connectionString =
            "Provider=Microsoft.ACE.OLEDB.12.0;" +
            "Data Source=" + filePath + ";" +
            "Extended Properties=\"Excel 12.0 Xml;HDR=YES\";";

        try
        {
            using (var connection = new OleDbConnection(connectionString))
            using (var adapter = new OleDbDataAdapter("SELECT * FROM [Sheet1$]", connection))
            {
                var table = new DataTable();
                adapter.Fill(table);
                Console.WriteLine("Rows read: " + table.Rows.Count);
            }
        }
        catch (InvalidOperationException ex)
        {
            // This is the exception type thrown when the provider is not registered
            // for the current process, but it can have other causes, so read the message.
            Console.WriteLine("64-bit process: " + Environment.Is64BitProcess);
            Console.WriteLine(ex.Message);
        }
    }
}

What the Code Does

• Connection string: Provider selects the ACE engine, Data Source is the file path, and Extended Properties tells the provider the file format. The inner quotes must be escaped in C#, which is why \" appears in the string.
• Extra settings: Any additional option, such as IMEX=1 (which reads mixed-type columns as text), belongs inside the quoted value, for example Excel 12.0 Xml;HDR=YES;IMEX=1.
• Sheet name: [Sheet1$] refers to a worksheet named "Sheet1". The trailing $ and the square brackets are required.
• DataAdapter.Fill: OleDbDataAdapter.Fill opens the connection if it is closed and closes it again when it finishes, so no explicit Open() call is needed.
• Diagnostics: Environment.Is64BitProcess reports the bitness of your running process. Compare it with the PowerShell output from the previous section.

The equivalent VB.NET only differs in syntax. The provider name, connection string and bitness rules are the same.

Getting the Sheet Name Right

Once the provider error is fixed, the next error people often hit is The Microsoft Access database engine could not find the object 'Sheet1$'. It means the name in your SQL doesn't match a worksheet in the file. Use the worksheet's tab name followed by a dollar sign, so a tab named "Data" is queried as SELECT * FROM [Data$].

To see the names the provider actually exposes, ask the connection for its schema. This snippet uses the same using System.Data; and using System.Data.OleDb; directives and the same connectionString as the example above:

using (var connection = new OleDbConnection(connectionString))
{
    connection.Open();

    DataTable sheets = connection.GetOleDbSchemaTable(
        OleDbSchemaGuid.Tables, new object[] { null, null, null, "TABLE" });

    foreach (DataRow row in sheets.Rows)
    {
        Console.WriteLine(row["TABLE_NAME"]);
    }
}

Worksheet names are returned with the trailing $. Depending on the workbook, named ranges may appear in the list as well.

Special Cases

ASP.NET and IIS

For a web application on IIS, open the application pool's Advanced Settings and set Enable 32-Bit Applications to True if you only have the 32-bit engine. Alternatively, install the 64-bit engine and leave the pool as it is. Microsoft states that the Access Database Engine redistributable is not intended as a replacement for the Jet OLE DB provider in server-side applications, so for a production web app consider moving the data into SQL Server or another database.

SSIS Packages

The package designer runs inside the IDE's process, which is 32-bit in Visual Studio 2019 and earlier and 64-bit in Visual Studio 2022. A provider whose bitness doesn't match the IDE can therefore be invisible at design time. When you run a package, the Run64BitRuntime project debugging property decides whether the 32-bit or 64-bit runtime is used. Set it to match the engine you installed.

SQL Server Import and Export Wizard

Windows ships separate 32-bit and 64-bit versions of the wizard. Launch the one that matches the ACE engine you installed. If the Excel option fails in one version, try the other.

Common Mistakes

• Fixing the wrong bitness: Installing the 64-bit engine while your project still runs as a 32-bit process, or the reverse. Always check the process bitness first.
• Forcing x86 when only 64-bit is installed: Targeting x86 fixes the error only if a 32-bit provider exists. With 64-bit Office or the 64-bit engine, target x64 instead.
• Changing the platform but not rebuilding: The old Any CPU binary keeps running until you rebuild, and Configuration Manager can silently override the project setting.
• Using Jet for .xlsx files: Jet does not support them at all. Use ACE.
• Mismatched Extended Properties: A different error, External table is not in the expected format, commonly means the Extended Properties value doesn't match the real file format, for example Excel 8.0 used on an .xlsx file. Check the table in Solution 3.
• Password-protected workbooks: Excel files encrypted with a password generally can't be opened through the ACE OLE DB provider. Remove the password first, or use a library that supports encrypted workbooks.
• File locked by another program: If the workbook is open in Excel or held by another process, you may get access errors, especially when writing to it. Close the file before running your code.
• Skipping the uninstall step: Old Access Database Engine versions and Office click-to-run installs can conflict with the standalone installer.
• Testing in the IDE only: The IDE, IIS Express and the deployed server can run with different bitness. Test in the environment where the error happens.

Alternatives to OLE DB for Reading Excel Files

Many people hit this error because OLE DB depends on a native provider that has to be installed, and registered with the right bitness, on every machine that runs your app. If all you need is to read or write Excel workbooks, a managed library avoids that dependency entirely.

• ClosedXML and EPPlus work with .xlsx files.
• ExcelDataReader reads both .xlsx and the older .xls format, and returns data as a DataSet.

Check each library's licence before using it in a commercial project. For example, EPPlus versions 5 and later use a licence that requires a commercial licence for commercial use.

None of these replace OLE DB for querying Access .accdb or .mdb databases. If you need that, the ACE provider is still the route, and the fixes above still apply.

Frequently Asked Questions

Can I install both the 32-bit and 64-bit ACE engines?

Generally no. The installers conflict with each other, and the 64-bit installer typically refuses to run if 32-bit Office is installed. Pick the bitness that matches your application, or change the application to match what is installed.

Is there a 64-bit version of Microsoft.Jet.OLEDB.4.0?

No. Jet exists only as a 32-bit component. To run as 64-bit, use the ACE provider instead.

Should I use Microsoft.ACE.OLEDB.12.0 or 16.0?

Use whichever name the PowerShell check lists on the machines where your app runs. If only 16.0 is registered, update your connection string.

Do I need Microsoft Office installed?

No. The Access Database Engine or the Access Runtime provides the driver without a full Office installation.

Does this work on Linux or macOS?

No. OLE DB is Windows-only. On other platforms, read Excel and Access files with a different library.

Summary

The "'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine" error means the provider is missing or its bitness does not match your process. Identify the provider and your process bitness first, then either match your platform target to the installed engine, install the matching Access Database Engine or Access Runtime, or replace Jet with ACE. For 64-bit Jet errors, the only fix is switching to ACE or running as 32-bit.