sys.dm_tran_locks , as mentioned in 694581 . To identify which rows are actually locked, you need to understand the locking hierarchy (table-> rowset-> page-> row), and you need to crack the description of the locking resource. For table locks, this is the identifier of the object from sys.objects , for rows, this is the partition_id of sys.partitions , and for pages, the actual identifier of the page. For rows, it depends on whether the heap or btree, but you can use the virtual column (undocumented) %%lockres%% to find the row. If this is too simple, you should also consider range locks , as they affect all rows in the specified range.
When you add difficulties in navigating through the physical hierarchy, especially when locking pages, a complex model of locking the compatibility matrix , complications, added hash collisions and consider the pace at which the locks you are looking for change, I would say that in the very best way you can make a very rough approximation. In addition to the fact that you are engaged in a certain investigation of problems, there is no reason for this. I would be horrified to hear about an application that actively looks at locks and makes any decision based on the information visible.