Fix ERROR_INVALID_TABLE 0X0000065C on Windows

This error means a table reference is broken, usually in SQL Server or ODBC. It's not a Windows kernel bug—it's almost always a corrupt schema or bad query. Here's how to squash it.

Quick answer for advanced users: Run DBCC CHECKDB on the database and rebuild the suspect table's indexes. If it's an ODBC linked table, drop and re-link it from the source.

What the hell is 0X0000065C?

You'll see this error pop up when Windows (or more often, SQL Server or an ODBC driver) tries to reference a table that either doesn't exist, has a corrupt metadata entry, or has a mismatched schema. The actual error code ERROR_INVALID_TABLE (0X0000065C) comes from the Windows NT status layer, but in practice I've only ever seen it bubble up through database applications. The biggest trigger? A linked server query that hits a table that was dropped or renamed on the source, or a SELECT from a view with a broken underlying table.

Don't bother rebuilding the OS or reinstalling .NET—the culprit is almost always the database itself or the connection config.

Step-by-step fix

Find the exact failing query. Check the application logs or SQL Server error log. The error message usually includes the object name. Fire up SELECT @@SERVERNAME to confirm which instance is throwing it.
Verify the table exists. Run:

USE [YourDatabase]
GO
SELECT OBJECT_ID('YourTableName') AS ObjectID;

If it returns NULL, the table is gone. That's your problem.

Check for schema corruption. Run:

DBCC CHECKDB ('YourDatabase') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Look for any message about corruption in sys.sysschobjs or sys.objects. If you see that, you've got a corrupt system table—don't ignore it.

Rebuild the suspect table's indexes. If the table exists but CHECKDB flags it, rebuild:

ALTER INDEX ALL ON YourTableName REBUILD;

For bigger tables, use ONLINE = ON to avoid blocking.

Fix linked server tables. If you're using a linked server, go to the source and verify the table exists with the same name/case. Drop and re-add the linked table:

EXEC sp_dropserver 'LinkedServerName', 'droplogins';
EXEC sp_addserver 'LinkedServerName', 'local';
-- Then re-create the linked server connection

Or just delete and re-add the linked table in your SQL query.

Check ODBC DSNs. If you're connecting via ODBC, open the ODBC Data Source Administrator, go to the System DSN tab, and test the connection. If the table isn't showing up in the DSN's table list, the schema has changed and you need to update the DSN or the query.

Alternative fixes if the main steps don't work

Restore from backup. If DBCC CHECKDB finds corruption you can't repair, restore the database from the last good backup. Seriously, skip the REPAIR_ALLOW_DATA_LOSS unless you're desperate and have a backup of the backup.
Drop and recreate the database object. If it's a view or stored procedure referencing the missing table, drop it and recreate it with the correct table name.
Check for permission issues. Rarely, the error shows up when the login doesn't have SELECT permissions on the table. Run EXEC sp_helprotect 'YourTableName' to confirm.
Update driver or provider. If you're using an older ODBC driver (SQL Server Native Client 10.0 or earlier), upgrade to ODBC Driver 18 for SQL Server. Old drivers handle schema changes poorly.

How to avoid this in the future

Most cases of ERROR_INVALID_TABLE I've seen trace back to schema changes that weren't communicated to the application team. Put all table changes (rename, drop, column changes) through a change control process. If you're using linked servers or ODBC, document the source schema and check it before every deploy.

Also—run DBCC CHECKDB as part of your nightly maintenance. It catches corruption before it bites you. Yes, it has overhead. Plan it during off-hours. Still worth it.

And for god's sake, if you're renaming a table, update your stored procs and views at the same time. I've pulled more all-nighters because someone dropped a table and didn't tell anyone than I care to count.