As has been mentioned in the comments auto shrink is a generally bad idea for a number of reasons (see the links they've provided) and this is most likely the cause of your transaction log issues
Judging by what you've posted you may have ran something similar to this, but its a useful bit of code which will list out all of the databases in an instance along with the recovery model and what currently is preventing the transaction log from shrinking. the reasons are usually self explanatory, like
Using this you should be able to narrow down what is preventing your transaction log from shrinking and hereby having all other transactions making it grow
, recovery_model_desc [Mode]
, convert(decimal(12,3),[Data File(s) Size (KB)] * 1.0 / 1024 ) [Data File(s) Size (MB)]
, convert(decimal(12,3),[Log File(s) Size (KB)] * 1.0 / 1024 ) [Log File(s) Size (MB)]
, convert(decimal(12,3),[Log File(s) Used Size (KB)] * 1.0 / 1024 ) [Log File(s) Used Size (MB)]
, [Percent Log Used]
FROM sys.dm_os_performance_counters os
JOIN sys.databases db
ON os.instance_name = db.name
WHERE os.counter_name IN
'Data File(s) Size (KB)'
, 'Log File(s) Size (KB)'
, 'Log File(s) Used Size (KB)'
, 'Percent Log Used'
--AND os.instance_name = 'Titan'
) as SourceTable
MAX(cntr_value) FOR counter_name IN
([Data File(s) Size (KB)]
, [Log File(s) Size (KB)]
, [Log File(s) Used Size (KB)]
, [Percent Log Used]))
order by case WHEN log_reuse_wait_desc = 'NOTHING' THEN 0 ELSE 1 END desc
, [Percent Log Used] desc
Personally I have this in a proc in my adminDB that can be ran whenever we see any issues relating to the transaction log to find out the exact state of it and what is the main cause of those issues
Its worth noting additionally for the auto shrink on the tlog, but mainly on the inevitable growth that you will have that the DB will be locked out while it grows the file and re-writes over that area of disk space