Two tools, one quick and one detailed, then the judgment call the output feeds.

The quick one: DBCC OPENTRAN against the database names the oldest active transaction, its start time and its session id. One command, and in a blocking spike the oldest transaction is usually the story, an hour old start time on a session id gives you the suspect immediately.

The detailed view joins the transaction DMVs to the sessions: sys.dm_tran_active_transactions joined through sys.dm_tran_session_transactions to sys.dm_exec_sessions, adding sys.dm_exec_requests with a cross apply of sys.dm_exec_sql_text for whatever statement is currently running. The columns that matter: transaction_begin_time for age, session status where sleeping with an open transaction is the classic forgotten BEGIN TRAN, host_name, program_name and login_name for who, plus the sql text for what. A sleeping session from a workstation holding a two hour transaction reads very differently from an active bulk load, which is the whole point of looking before acting.

The judgment call: KILL session_id ends the holder, and its rollback can take as long as the work it undoes, sometimes much longer, during which the blocking continues. For the forgotten workstation BEGIN TRAN, kill freely, the rollback is trivial. For a long running legitimate process, waking its owner beats killing it mid flight. Check rollback progress afterwards with KILL session_id WITH STATUSONLY, and resist restarting the service to hurry a rollback, recovery replays the same undo at startup with the database unavailable throughout.