.Net Application Using Inefficient Query Plan - caused by ARITHABORT setting?
You are probably running into parameter sniffing issues. The fact that you execute the query with a different ARITHABORT setting makes SQL Server create a new plan and not reuse the existing plan as that setting is part of the cache key.

Have a look at Slow in the application, fast in SSMS, it has a lot of information such as this:


  We have seen that there is a large number of different cache keys, so
  potentially there can be very many plans for a single stored procedure. But we have also learnt that many of the SET options that
  are cache keys are legacy options that you should never change.
  
  In practice, the most important SET option is ARITHABORT, because the
  default for this option is different in an application and in SQL
  Server Management Studio. This explains why you can spot a slow query
  in your application, and then run it at good speed in SSMS. The
  application uses a plan which was compiled for a different set of
  sniffed parameter values than the actual values, whereas when you run
  the query in SSMS, it is likely that there is no plan for ARITHABORT
  ON in the cache, so SQL Server will build a plan that fits with your
  current parameter values.


If you can change the stored procedure I would try to fix it there rather than with plan guides. The possible solutions are also explained in the linked article but basically you have these options:


OPTION (RECOMPILE) / WITH RECOMPILE
Add the "optimal" index
Drop the index you don't want the plan to use
Use an index hint to force use of any of the other indexes.
The query hint OPTIMIZE FOR.
Copy the parameters to a local variable.
Change the application behaviour.