Fix XACT_S_MADECHANGESINFORM 0x0004D006 SQL Server

Quick Fix: Check Transaction Log Space (30 seconds)

I had a client last month whose entire inventory system locked up because of this exact error. The root cause? The transaction log had filled up to 100% and SQL Server couldn't write any more changes. Here's what to do first.

Run this query against your database:

USE your_database_name;
DBCC SQLPERF(LOGSPACE);

Look at the Log Space Used (%) column. If it's over 95%, your log is basically full. That's likely your culprit. Check also the Log Size (MB) — if it's tiny (like under 100 MB) and your database sees heavy writes, it'll fill up constantly.

What to do next: If the log is full and you're in a simple recovery model, you can shrink it immediately. But don't just shrink — that's a band-aid. The real fix is to back up the log or switch to a model that auto-manages growth. More on that in the moderate fix.

Moderate Fix: Grow or Shrink the Transaction Log (5 minutes)

So the log is full. Let's handle it based on your recovery model.

If you're using FULL recovery model

You need to back up the log to free up space. Use this:

BACKUP LOG your_database_name TO DISK = 'C:\Backups\your_db_log.trn';

Then check the log space again. If it's still high, you might have an active transaction that hasn't committed. Run this to see what's blocking:

SELECT * FROM sys.dm_tran_active_transactions WHERE state = 2;

If you see an old transaction, kill it (carefully — only if you know it's safe):

KILL transaction_id;

If you're using SIMPLE recovery model

You can shrink the log directly:

DBCC SHRINKFILE(your_database_log_file_name, 100); -- targets 100 MB

Find the log file name with:

SELECT name FROM sys.master_files WHERE database_id = DB_ID('your_database_name') AND type = 1;

I've seen cases where shrinking doesn't work because the log file has grown huge and has internal fragmentation. In that case, use this trick from a senior DBA I worked with: set the log file to a smaller initial size, then shrink again:

ALTER DATABASE your_database_name MODIFY FILE (NAME = your_log_file, SIZE = 500 MB);
DBCC SHRINKFILE(your_log_file, 100);

If the error still shows up, move to the advanced fix.

Advanced Fix: Permissions or Corruption (15+ minutes)

When the log has space and it still errors, you're looking at something deeper. I've run into this twice in the last year — once on a client's SQL Server 2019 instance, again on 2016.

Check file permissions

The SQL Server service account needs full control on the folder where the log file lives. Open Windows Explorer, right-click the folder (usually C:\Program Files\Microsoft SQL Server\MSSQLxx.MSSQLSERVER\MSSQL\DATA), go to Properties > Security. Add the account NT SERVICE\MSSQL$your_instance with Full Control if it's missing. I've seen a Windows update reset these permissions in 2023 — cost a friend half a day.

Verify the log file isn't corrupt

Run DBCC CHECKDB on the database:

DBCC CHECKDB(your_database_name) WITH NO_INFOMSGS;

If you see corruption messages, you've got a bigger problem. Restore from a clean backup. If no backup exists (ouch), try this last resort:

ALTER DATABASE your_database_name SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB(your_database_name, REPAIR_ALLOW_DATA_LOSS);

This can lose data but gets the database running again. I'd only recommend it if you're desperate and have no backup.

Free up OS disk space

Check if C: or the drive holding the log file has less than 5% free space. SQL Server can't log if the disk is full. A client's SQL Server 2022 instance crashed daily because the log drive had only 200 MB free — a quick cleanup of old backups fixed it.

Quick tip: Set the log file's MAXSIZE to something reasonable, like 10 GB, and enable AUTOGROW by 500 MB. That stops sudden fills.

If nothing worked, check the Windows Application Event Log for more clues — sometimes the error message is misleading. I've seen a disk driver bug cause this on older servers. Update your storage drivers if you're on a VM.