How to troubleshoot orm queries interfering with other applications

I would strongly suggest metadata in the connection in order to trace back to the application. In the connection string, there is an Application Name. There is also session data which can be used in the form of CONTEXT_INFO

https://stackoverflow.com/questions/323494/sql-server-modifying-the-application-name-property-for-auditing-purposes

Of course all this requires application changes, but it is good for tracing and auditing in general, so baking it in from the beginning is really useful.

Typically, when a query is "interfering" with another query it is either blocking or deadlocking. Either of these would not be visible via a default SQL Profiler trace.

If you are experiencing deadlocks, you will want trace flags 1204 and 1222 turned on in SQL Server so the deadlock output gets sent to the errorlogs. You could also re-run the trace and add the deadlock events.

Blocking issues can be polled for. Either you can roll your own blocking log code or you can use a tool like SQL Spotlight to detect these occurrences. Blocking can be checked by looking at the master.sys.sysprocesses blocked column for a value <> 0. If you decide to roll your own, a script such as this one could be used as a starting point to get the executing session information which can be logged to a table or you can setup a job to pull information from sp_whoisactive.

I would also check your Profiler trace (or take a new one) and correlate it with basic server performance counters (CPU, disk queue, network throughput) to see if any one particular resource is being bottlenecked during a particular query execution. Often it is obvious via the Profiler trace if a query is a problem because the amount of reads or cpu will be very high on the statement or batch completed event. A counter log that is created during the same time that a Profiler trace is taken can be opened up in SQL Profiler and correlated directly to the Profiler trace output that is saved.

It's also a good idea to setup the SQL Server Management Data Warehouse to collect server and query performance stats over time. It has some nice drill down reports that will help you identify problems within a certain window of time. It's not always as precise as a profiler trace but it could give you helpful information such as the types of waits you are experiencing and other resource bottleneck patterns which can easily be correlated to other queries via the Query Stats reports.