Was something definitely to do with the filtering. I just ran a trace for over 10 minutes without any filters in place. Even though the system was busy, the CPU never clocked more than 10% usage.
Just thought you'll would like to know...
Were you originally tracing events like SP:StmtCompleted in the Stored Procedures category? Have you now changed to tracing events from the TSQL section like SQL:BatchCompleted?
I ask since you didn’t provide those details, and I have recently seen this combination of high CPU (across sixteen cores) and lots of CMEMTHREAD waits on a system where heavy use is made of scalar user-defined function calls.
The problem occurs when tracing higher-level obejcts like procedures which contain many calls to these scalar functions (particularly if the function is called in a loop or per-row in a set-based operation). The scalar function call is traced by SP:StmtCompleted but not by SQL:BatchCompleted.
Second thing: you really should consider bringing your server up to at least SP3, since fixes like this one (which offers trace flag 8048 for CMEMTHREAD waits) are included.
The latest build (CU4 for SP3) has a version of 09.00.4226 – whereas you are running build 3050 (a build which is not immediately familiar to me, but seems to be very slightly post-SP2). See Builds Released After SP3 for a list of available builds.
Third: you said earlier that you were unable to use DMVs like sys.dm_exec_query_stats since the database compatibility was not set to 90. Many features of 2005 (including the DMVs and DMFs) are invariant to the database compatibility setting. DMVs are always available to you on 2005 and later, regardless of this setting.
To be clear, I would primarily encourage you to patch your server with the latest fixes before putting more work into this – the problem you have may have already been addressed.