Uncommitable T-SQL transaction after trigger applied to table
I definitely would not say that only 1 row is ever passed into the trigger.  Triggers handle every row updated in a single statement.  (I see Jon Seigel has made the same point.)

The problem is that inside a trigger an error can occur that results in a state where the transaction cannot be committed.  Your main issue will be determining why the transaction became uncommittable.

See http://msdn.microsoft.com/en-us/library/ms179296(v=sql.105).aspx 

In part it says:


  Inside a TRY…CATCH construct, transactions can enter a state in which the transaction remains open but cannot be committed. The transaction cannot perform any action that would generate a write to the transaction log, such as modifying data or trying to roll back to a savepoint. However, in this state, the locks acquired by the transaction are maintained, and the connection is also kept open. The effects of the transaction are not reversed until a ROLLBACK statement is issued, or until the batch ends and the transaction is automatically rolled back by the Database Engine. If no error message was sent when the transaction entered an uncommittable state, when the batch finishes, an error message will be sent to the client application that indicates an uncommittable transaction was detected and rolled back.


So, your TRY/CATCH and testing against XACT_STATE is correct.  It is just too late to overcome whatever already happened to produce a "doomed" transaction.

Balmukund has a blog post on this topic below.  He points out that he cannot define every condition that might cause a doomed transaction, but he offers some hints: 

http://blogs.msdn.com/b/sqlserverfaq/archive/2011/05/11/errors-raised-with-severity-level-16-may-cause-transactions-into-doomed-state.aspx 


  As per our intensive research we asserted that XACT_STATE changes is not governed by a single rule and depends on the transaction state (user or system initiated and if an active transaction or not) and the type of error being raised. For example, transactions having CONVERT\CAST errors and DDL operations (ALTER TABLE\DATABASE\INDEX etc.) on failure will make the state of the transaction as -1 and will terminate the transaction.
  
  One more example which could get your transaction into doomed state is when you attempt to convert a value that is incompatible with target data type.