Data Sharing Service crashes on Windows Server 2016 - Event ID 7023

While troubleshooting an issue recently on a Windows Server 2016 system, I noticed errors on the System event log about the Data Sharing Service crashing.

The Data Sharing Service service terminated with the following error: %%3239247874
The Data Sharing Service service terminated with the following error: %%3239247874

Searching online for more information about this service and why it might be failing, I came across a lot of people describing similar problems, but the only explanation and solution I found came from this December blog post by Microsoft Japan.    Google translate did a great job making the post understandable to me, but since the information doesn't seem to have been widely publicized I thought I'd share it here to help get the word out.

The Data Sharing Service fails due to a resource conflict with another service included in Server 2016, the User Access Logging Service.  Either one of these services alone will run without issue, but if one is already running and you try to start the other, it will fail.

According to an update to the blog post, Microsoft plans to resolve the issue in a future update to Server 2016, but in the mean time there is a simple workaround that will allow the Data Sharing Service and User Access Logging Service to live in harmony.  The internal resource conflict occurs because the two services are running in a shared process.  By configuring the services to each run in their own process, the conflict is avoided and both services can be running at the same time.  Run these two commands to change the configuration:
Sc config ualsvc type=own
Sc config dssvc type=own


Successful result of SC Commands

After changing the service configuration, you should now be able to start the Data Sharing Service successfully.  

Comments

  1. DedicatedHosting4uApril 30, 2019 at 2:26 AM

    Thanks for sharing that such good information.

    ReplyDelete
  2. Fernando Souza MoreiraApril 30, 2019 at 2:42 PM

    I was getting error 2114 when starting the service LanManServer. (File Sharing)

    Then I run Procmon64 for debugging.

    I found an error "NOT FOUND" in registry key.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

    This key was empty. I get full key from a running server. After import to registry. I could start service successfully.

    ReplyDelete

Post a Comment

Popular posts from this blog

Mystery Solved: Bitlocker is enabled, but Intune shows the computer as non-compliant for Require Bitlocker

For some time, I have struggled to understand why Intune reports some computers as non-compliant with the "Require Bitlocker" setting, even though Bitlocker is enabled and working on the computer.  In my searches for an explanation, I found the same question asked by many others, but never an answer.  Until today. I accidentally stumbled across this article from Microsoft's Rob Lane , which explains how the Require Bitlocker setting is evaluated and why it might seem to incorrectly report a non-compliant state.  I encourage you to check out that article for full details.  I'll just summarize here the part that suddenly made this bitlocker compliance issue make sense to me. The "Require Bitlocker" setting in Intune relies on the Device Health Attestation (DHA) service in Windows 10 to report the state of Bitlocker encryption on the computer.  If Bitlocker protection is disabled or suspended, DHA will report that the computer is non-compliant with this
Read more

Windows 10 Credential Guard breaks WiFi

Recently, I ran into an issue with computers running windows 10 that would not connect to our WPA2-Enterprise encrypted wifi network.  When it failed to connect, there was no indication of why, only the message "Can't connect to this network."  The computers were able to connect to unencrypted networks and networks using a Pre-shared key for WPA encryption without issue. Checking the event logs on the RADIUS server to see why the comptuer failed to connect, there was no log entry for a connection attempt from the affected system.  The WLAN-Auto-Config log on the client listed a couple of errors, including Event ID 11006 and 12013, but other than showing that the failure reason was "Explicit EAP failure received", they didn't give much to go on: Log Name:      Microsoft-Windows-WLAN-AutoConfig/Operational Source:        Microsoft-Windows-WLAN-AutoConfig Date:          8/15/2016 1:11:20 PM Event ID:      11006 Task Category: MsmSecurity Level:         Err
Read more