3

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

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

2 Answers 2

3
+50

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.

6
  • Should the Initialize-SPResourceSecurity command be used before or after setting the Service back to the 'Local Service' Log On account?
    – user58700
    May 14, 2019 at 14:44
  • 1
    Run it after setting the account back.
    – user6024
    May 14, 2019 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, 2019 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, 2019 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.
    – user6024
    May 16, 2019 at 16:26
1

With Windows Server 2019 and SharePoint 2019 the errors below stopped flooding in UlsViewer after I added Read permission for Local Service in folder C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS. The service had already write permission but no read permission.

Process: wsstracing.exe
Product: SharePoint Foundation
Level:   Unexpexted
Message: Trace Service encountered an unexpected exception when processing usage event. Detail exception message: Create store file error.. Win32 error code=5.

I also checked that SharePoint Tracing Service has Log On As Local Service.

FYI the log folder can be checked from SharePoint Central Administration -> Monitoring -> Configure diagnostic logging

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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