Over the course of the last week I have had a SP 2013 on-prem farm Install on a server (separate DB server) that has had high CPU for hours at a time. In services, I realized that the culprit was the "SharePoint Tracing Service." It was slowing down the server to a crawl at some points.

Here's what I did/ what I know:

  • Every time I restart the SharePoint Tracing Service in Services, the CPU usage would instantly stabilize, and become normal.

  • The "Log On" account for the SP Tracing Service was set to "Local Service".

  • The "Local Service" account had membership in the Performance Log Users and Performance Monitor Users Groups on the Local Server.

  • I checked that the Local Service Account was present in the Security Tab of WSSTRACESESSION14 in Performance Monitor.

  • It seems like a permissions issue, because when I look into the log files in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\logs, I see an Error code 5, (Win32 file store). This tells me that the tracing service (via the Local Service account) doesn't have the proper rights to write to the files possibly?

WHAT WORKED: I ended up just changing the Log On account for the SP Tracing Service to the default "Local System Account." This seemed to instantly fix the issue, and I don't see the access/write issue/error happening in the logs anymore.

That all being said, I still feel like setting the service to just use the Local System account is kind of a workaround. Is there something else I should still try in order for the Service to use the Local Service Account instead?

I don't know that a service that only writes logs to disk needs admin + network access via the Local System Account.

New Information: These screen captures are from ProcMon during the High CPU Usage. I can't upload the entire log because of included proprietary information:

1 2 3 4 5 6 7 8 9 10 11

  • @Trevor Seward, any insight into the above ProcMon info? Thanks. – user58700 May 21 '19 at 14:21

This should always be set to the Local Service account and no other account. You can run Initialize-SPResourceSecurity to re-set the NTFS/registry ACLs to attempt to fix the err(5) code.

If that cmdlet does not resolve the issue, you can run procmon to determine what exactly is failing and what rights the service is requesting.

| improve this answer | |
  • Should the Initialize-SPResourceSecurity command be used before or after setting the Service back to the 'Local Service' Log On account? – user58700 May 14 '19 at 14:44
  • 1
    Run it after setting the account back. – Trevor Seward May 14 '19 at 14:47
  • Done. I'll give it a few days, see if the CPU utilization stays stable now, while checking in on the logs looking for the 'Error 5' write code. – user58700 May 14 '19 at 14:51
  • That lasted about 5 hours before CPU spiked again. Same as above, I restarted the SharePoint Tracing Service, and CPU went down. It probably won't stay that way for long though. Checked logs too, now seeing "Trace Service encountered an unexpected exception when processing usage event. Detail exception message: Create store file error.. Win32 error code=5" again as well. It has got to be a permissions issue.... – user58700 May 14 '19 at 20:51
  • 1
    Use ProcMon to determine where the access denied is coming from, what access the process expects, etc. Add the log to your post. – Trevor Seward May 16 '19 at 16:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.