SQL Server is essentially a puppet of the client application. The client application has almost total control over (and responsibility for) the locks acquired on the server. While the SQL Server lock manager automatically uses locks to protect transactions, this is directly instigated by the query type sent from the client application and how the results are processed. Therefore, resolution of most blocking problems necessitates inspecting the client application.
Often, turnkey client applications and higher-level application development tools are used against SQL Server. These may encapsulate the DB-Library or ODBC API calls to the database in a higher abstraction level; however, from the perspective of SQL Server, there's essentially no difference between one of these higher level applications, a call-level DB-Library application, or a call-level ODBC application. SQL Server only perceives a stream of Transact-SQL statements and certain control tokens sent by each client API call. The same basic issues cause blocking problems whether the client application is a call-level application written in C or a higher-level application that encapsulates database calls. Likewise, the solution to these problems is generally the same.
This means that no matter what level of visibility the application exposes regarding the database calls being made, a blocking problem will nonetheless frequently require inspection of the exact SQL statements submitted by the application and what the application's exact behavior is regarding query cancellation, connection management, fetching all result rows, and so on. If the development tool does not allow explicit control over connection management, query cancellation, query time-out, result fetching, and so on, blocking problems may not be resolvable. This potential should be closely examined before selecting an application development tool for SQL Server, especially for business-critical OLTP environments.
There may be a tendency to focus on server-side tuning and platform issues when facing a blocking problem. This will usually not lead to resolution and can absorb time and energy better directed at examining the client application and the queries it submits.
Several tracing facilities may be used to examine what the client application is sending to the server. Each client application may have it's own tracing feature, so examine the documentation for the application. In addition, server-side tracing can be done using the -T4032 trace flag and the SQL Trace facility. Usually you can resolve a blocking problem without using these, but they are available if needed.