Ross,

I have seen this happen in the past, for many different reasons.

I assume from your comment that you know that it is sqlservr.exe that is
using the 25%.  Can you run sp_who2 to identify some process that continues
to eat up CPU time?  If so, use dbcc inputbuffer, fn_get_sql, or look at
sys.dm_exec_sql_text to see what is running.  Also use DBCC OPENTRAN to find
the oldest transaction in each database.  (However, I assume that there is
not a blocking transaction or you would be having other problems.)

If you identify a problem spid, try to get the hostname for that spid.
Sometimes a client computer loses connectivity, but the SQL Server does not
know that, so it keeps trying (forever) to send the result set to the
client.   If that is the case, logging the hostname computer off of the
domain, then logging back into the domain, often alerts SQL Server to the
problem so that it will abandon that result set.

If appropriate, you can try to KILL the spid. (But the spid may not always
be killable.)

Other software can also get into a confused state and eat up CPU.  For
example, a DTS package, backup software, etc. can also get into an confused
state and never stop running.  Use Windows Task Manager to check whether
another task is actually the guilty party. If it is one of those, then try
killing that Windows process.

If you cannot do anything else, you should schedule a restart of your SQL
Sever.  That should (naturally) clear the problem out.  But you will need to
remain alert to its returning.

But, FWIW, I have not seen much of this on SQL Server 2005 SP2.

RLF