Server service won't start, dependency service does not exist or has been marked for deletion

HCHTech

Well-Known Member
Reaction score
3,823
Location
Pittsburgh, PA - USA
Had a client who had a power outage last night in the middle of their backup routine. Single HyperV host, DC and AppServer VMs, Server 2016. Both VMs offline, Stuck checkpoints, VMs wouldn't restart, what a mess.

For The DC, I ended up deleting the stuck checkpoint, deleting the VM, recreating it and attaching the vhdx file - that worked (mostly) without a hitch.

For the AppServer, for some reason, the c: drive had mounted on the Host as the H: drive (I have never seen that happen before!), so after dismounting that, the server restarted, but it was not happy. It's up again, but none of its shared drives are available on the network. Turns out the Server service isn't started. Attempting to start that gets this message:

"Windows could not start the Server service on the local computer. Error 1075: The dependency service does not exist or has been marked for deletion."

Checking the system event log, I see a 7003 error: The Service depends on the following service: Srv. This service might not be installed.

Running "SC Query svc" in a command box produces "The Specified service does not exist as an installed service".

Running sc query lanmanserver shows it stopped, with the 1075 exit code:
1618938564953.png

Checking the dependency services (Security Accounts Manager, which depends on Remote Procedure Call(RPC), which depends on DCOM Server process Launcher and RPC Endpoint Mapper), I find that all of those services are running.

Googling around, I see some entries for this error with Windows Vista and 7, along with suggestions to remove the dependencies by editing the registry key for the service. I am hesitant to do this on a server.

The key for LanmanServer is:
1618938814445.png

and the key for "srv" is:
1618938890794.png

I've run an srfc /scannow, and got a couple of dozen files in the WinSxS with error like this:

2021-04-20 12:58:03, Info CSI 0000be3f [SR] Cannot repair member file [l:22]'MSFT_MpSignature.cdxml' of Windows-Defender-Management-Powershell, version 10.0.14393.0, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch
2021-04-20 12:58:03, Info CSI 0000be40 Hashes for file member \SystemRoot\WinSxS\amd64_windows-defender-management-powershell_31bf3856ad364e35_10.0.14393.0_none_1137c685b804c9a3\MSFT_MpThreat.cdxml do not match actual file [l:19]'MSFT_MpThreat.cdxml' :
Found: {l:32 3S3s28bsA1fdvZUq08KcCgX8c2i62zd2SLuPCWTu3uw=} Expected: {l:32 rllSNoMqOITSqj+RNFSsb/THNfVegZx/ORyUtlMoH5I=}


I could restore from the most recent backup that worked (last Friday), but I'd like to avoid that as work will be lost. Before I do that, any recommendations for things I could do?

Edit: I checked the srvsvc.dll file in c:\windows\system32 between my problem machine and another Server2016 client I have on the same update level, and they are exactly the same. Same size and size on disk. One day apart on creation date, but that's probably due to the update schedule.

TIA
 
Last edited:
Server 2016? It's Windows 10!

Get your installation media and do an "upgrade" install over the top! Refresh the thing!

Also shame on your for using VHD instead of VHDX, all this is prevented with the latter tech...
 
BTW, I am using VHDX - just a typo on my part. I still don't know exactly what caused the problem - there should have been a graceful shutdown before the batteries went flat and backup or not, that shouldn't have corrupted the VMs - I honestly haven't had time for forensic analysis - spent all my time today getting them back up and running.

Everything was working except for the darned server service, and ultimately this was fixed stupidly fast by resetting the dependencies via an administrative command line and then starting the service:

sc config lanmanserver depend=SamSs/RpcSs

followed by

net start lanmanserver

Those dependencies were reported correctly via the services app, but the service refused to start there. That has to be a permissions issue , but tracking that down will have to wait until later. I just wish I had thought of forcing/resetting via the command prompt a few hours earlier than I did. It would have saved me the tension headache I'm currently nursing and the client a few hours of downtime.
 
Digging deeper into other sections of event viewer...any DNS related issues? Wondering if SYSVOL had some corruption, zone wasn't loading properly for DNS to get up and running.....and on a DC, when DNS isn't up and running properly....well....it cascades downhill from there. Or possible leftover stuff from a prior migration contributed to the above DNS and/or SYSVOL issues.
 
Doing this, you removed "Srv" from the dependencies. Does the "Srv" registry key have been recreated?

Checking today, I get:

C:\Users\Administrator>sc qc lanmanserver
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: lanmanserver
TYPE : 20 WIN32_SHARE_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:\Windows\System32\svchost.exe -k smbsvcs
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Server
DEPENDENCIES : SamSS
: Srv2
SERVICE_START_NAME : LocalSystem

Which appears to be correct - it matches another Server 2016 DC I have in the field which is unmolested. I did load an outstanding update, too, which certainly could have changed the settings.
 
Looking over this with rested eyes, it occurs to me that srv.sys is SMB1 while srv2.sys is SMB2. SMB1 would have clearly been disabled/removed, so that "doesn't exist as an installed service" message makes sense.

Also, the IP address of this DC VM was changed on the day this server was installed in 2019, the original IP that was moved away from is not in the DHCP range, and is currently not in use by anything else (which I confirmed yesterday). However, I found that IP in the arp table of the spare workstation I was working with to test connectivity during/after the crisis. Something was clearly "up" with DNS.

I went through the DNS & DHCP settings with a fine-toothed comb last evening, but didn't find any reference at all to the original IP. I took this opportunity to change external DNS to quad9, and cycled both the DNS and DHCP services a couple of times. So far, everything seems to be working ok. Logs look ok and a fresh BPA scan didn't turn up anything interesting. Never did find a culprit for the initial meltdown. Frustrating.
 
DEPENDENCIES : SamSS
: Srv2
Looking much better than "DEPENDENCIES : SamSs RpcSs" ;)

So now "HKLM\SYSTEM\CurrentControlSet\Services\Srv" is almost empty
and "HKLM\SYSTEM\CurrentControlSet\Services\Srv2" is complete.

As you said, it makes sense. Something went wrong when SMB v1 was disabled.
 
Back
Top