SQL Server, consistency error that I can't fix

DBCC CHECKDB on a user database returns this error

Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3851, State 1: An invalid row (class=128,depid=65536,depsubid=0) was found in the system table sys.syssingleobjrefs (class=128).

This error is in a user database, not in master! Internet is full of articles dedicated to this error when people try to check the master database, restored on a different server. That's not the case.

I tried all usual magic without any success.

DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS
--error

ALTER DATABASE DBCopy SET SINGLE_USER WITH ROLLBACK IMMEDIATE

DBCC CHECKDB (DBCopy, REPAIR_ALLOW_DATA_LOSS) 
--output reports the same error

DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS
--error

--no hope but just in case
ALTER DATABASE DBCopy SET EMERGENCY

DBCC CHECKDB (DBCopy, REPAIR_ALLOW_DATA_LOSS) 
--the same error reported

DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS
--error

ALTER DATABASE DBCopy SET MULTI_USER

We don't have a backup that is free from this error.
This error appears completely harmless. The DB and apps work completely fine.

Microsoft SQL Server 2019 (RTM-CU14)

The DB is in-memory enabled.

Anything to try before I start to re-build the DB?

P.S. I rebuild the database.

It appears that you have a row in sys.syssingleobjrefs that does not correspond to rows in other system tables.

sys.syssingleobjrefs is listed as a System Base Table, and is only accessible over a DAC (administrator) connection. You can access it using sqlcmd.exe -A.

You also need to start SQL Server in Single User Mode. You do this by modifying the startup parameters of the service to -m, and restarting it.

The documentation says:

To bind to a system base table, a user must connect to the instance of SQL Server by using the dedicated administrator connection (DAC). Trying to execute a SELECT query from a system base table without connecting by using DAC raises an error.

Important

Access to system base tables by using DAC is designed only for Microsoft personnel, and it is not a supported customer scenario.

I would only ever advise to do so when there is literally no other option. Messing with system tables can destroy your database, and apparently it sets a flag in the database header which means Microsoft may decide not to give any support on that database.

So you connect while logged in as an Administrator, or by logging in as sa. You probably want to just delete the invalid row, hopefully that should fix the issue.

WARNING!:

Do this entirely at your own risk. I strongly suggest you take a backup of the database, restore it to an entirely different instance, and test this there first.

USE [DBCopy];
GO

ALTER DATABASE DBCopy SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

DELETE FROM sys.syssingleobjrefs
WHERE class = 128
  AND depid = 65536
  AND depsubid = 0;

GO

DBCC CHECKDB (DBCopy, REPAIR_ALLOW_DATA_LOSS)
  WITH NO_INFOMSGS, TABLOCK;

GO

StackExchange Database Administrators Q#303760, answer score: 2