Error Using Xlsread Excel Worksheet Could Not Be Activated

Getting Past the "Could Not Be Activated" Error in xlsread

Xlsread is MATLAB's standard way of pulling data out of Excel files, but it has always been one of those functions that quietly falls apart depending on what version of Office you're running, which service pack you applied, and whether something else has the Excel application open at the same time. The error message you're seeing isn't actually a problem with your data. It's a COM automation issue. The function is trying to talk to the Excel process through the Windows Component Object Model, and Excel refuses to respond. When xlsread runs, it launches or connects to an instance of Excel on your machine, opens the target workbook, activates a specific worksheet, reads the cells, then closes everything down. If any step in that chain gets blocked, you get the activation error. The most common reasons are straightforward: Excel is already open with the file in use, there's a permissions issue with the registry key that controls COM access, the installed version of Excel doesn't match what MATLAB expects, or the file path contains characters that break the automation call. I ran into this myself last year on a project where I was processing over two hundred Excel files from a shared network drive. The script worked fine for a week, then started failing on exactly three of the files. All three were .xlsx files that had been opened and left running by someone else on the team. The other hundred-and-ninety-seven files went through without a problem. The issue wasn't the code. It was that Excel puts a lock on the file when it's open, and xlsread's COM layer can't force its way past that lock. I switched to reading those files with the importdata function pointed at the CSV export instead, and the pipeline ran clean.

There are deeper causes too. On some machines, especially corporate ones with IT-managed configurations, the DCOM permissions are set so that the local system account can't launch Excel as an interactive process. This shows up most often when you run MATLAB from a scheduled task or through a remote desktop session. Excel won't activate because the COM security policy blocks the call. Another frequent trigger is having Excel 64-bit installed while running 32-bit MATLAB, or vice versa. The bitness mismatch breaks the COM bridge entirely, and the error message doesn't tell you that's what happened. File format matters more than people usually admit. Xlsread was written primarily for .xls files. When you point it at an .xlsx file, it still works through COM, but there's an extra translation layer between MATLAB and Excel's newer XML-based format. On some systems with older service packs, that layer is where the activation fails. The workaround is usually to save the file as .xls first, or skip COM altogether.

What to Check First

Close every instance of Excel on your machine. This sounds obvious, but it's the single most common fix. Even if Excel isn't visible on your screen, it can still be running in the background after a crash or a suspended session. Open Task Manager and look for Excel.exe. Kill it if it's there. Then run your xlsread command again. Check the file path. Xlsread doesn't handle certain characters well in longer paths. Spaces are fine, but characters like #, &, and parentheses can break the COM call on some Windows builds. If your path is long, try moving the file to a shorter location like C:\temp\myfile.xlsx and testing from there. Verify that the worksheet name you're requesting actually exists. If you pass an invalid sheet name to xlsread, it sometimes throws the activation error instead of a clearer "sheet not found" message. Try calling xlsread without specifying a sheet and see if it returns data from the first worksheet.

The Practical Fix That Actually Works

The most reliable approach I've found over the years is to avoid xlsread for anything beyond simple .xls files and straightforward workflows. Here's what I use instead: Read .xlsx files with readtable or readmatrix. These functions don't use COM. They read the file directly from disk using MATLAB's built-in parsing. This bypasses the entire Excel automation layer, which means Excel doesn't need to be installed on the machine at all, and you won't see the activation error under any normal circumstance. The syntax is almost identical. Instead of data = xlsread('file.xlsx', 'Sheet1'), you use data = readmatrix('file.xlsx', 'Sheet', 'Sheet1'). For tables with headers and mixed data types, readtable does the same job and handles column types much more intelligently. If you're stuck on an older version of MATLAB that doesn't support readtable or readmatrix, there's another path. Use the ActiveX interface directly with proper error handling. Create the Excel COM object yourself, check whether it connected, and handle the failure case before attempting to open the workbook. This gives you visibility into exactly where the connection breaks.

For network drive files, copy the file locally first. Network latency and SMB locking behavior can cause the COM activation to time out. I've seen this on UNC paths where the same file works fine from the local disk but fails across the network. Copy to a temp folder, run the read, then clean up. This adds maybe ten seconds to your workflow but eliminates a whole class of intermittent failures.

When Nothing Else Works

There are edge cases where even the workarounds above don't help. If your corporate IT environment has restricted DCOM access, if Excel is installed in a non-standard location, or if you're running MATLAB on a headless server with no graphical interface, xlsread simply isn't going to function. In those scenarios, the only real option is to export your Excel data to CSV or use a dedicated library that doesn't depend on the Excel application being present. Another hard limit is file corruption. If the Excel file itself has structural issues, xlsread may fail during activation even though the file opens fine in the Excel UI. Check the file by opening it manually. If Excel repair prompts appear, the file is damaged and no amount of MATLAB troubleshooting will fix it. The bottom line is that xlsread is a legacy function working through a fragile automation layer. It works well enough for quick scripts on a personal machine with a standard setup, but it's not robust for production use or anything that runs unattended. Switching to readtable or readmatrix for modern Excel files usually solves the problem immediately and removes the dependency on Excel being installed and available. That's the move I'd make without hesitation at this point.