The mysterious case of a crashing server (LanmanServer) service

A few days ago, we had mysterious issues with one of our Windows Server 2008 R2 SP1 machines. The problem was noticed, because an information popped up in the system tray, of other terminal servers, that the Remote Desktop Licensing Service is not available on the network.

The source server of the problem was found pretty easy. After a troubeshooting for a while, i found out, that the problem-machine is not available via UNC-Path’s and Named Pipes.

If i tried: net use \\<troublemachine> from a remote system i received the error message, that the system is not available. So i searched for the service, that is responsible for providing this services, and this is the server service also known as LanmanServer.

On the service console (services.msc) i detectet that the service was stopped. So i thouhgt “pretty easy – i just start the service again, and that’s it!” But it wasn’t. The service crahed again and again, after round about 1 minute.

The next steps what i tried to find out was, why the service is doing this. With Service Control (aka. SC.exe)  i looked up for the WIN32_EXIT_CODE.

SC query LanmanServer, revealed’s the the error code what causes the service to crash. And it  was always the same error code: 53.

With NET HELPMSG 53, i found out that the service had a problem, to locate a network path. But this message sound’s pretty common and all important services are up and running on our network.

Because this looks pretty weird to me, i decided to use Processmonitor, a tool of Mark Russinovic, that supports me a lot of times in the past. I started the tool, put a filter on the concerning service and started the service again, so see whats happens in the background.

During the start sequence everything looks fine, but then the service crashed again and i stopped logging of Processmonitor and reviewed the result. I found a record what is typically not usual: BAD_NETWROK_PATH. This is a look of the troubleshooting result:

Procmon analysis
Procmon analysis in action

 

 

Anyway… what are the next steps now? – “Registry clean up” I copied the orphaned network path into my clipboard and searched the windows registry for this entries. I found a few locations where this network path was listed. Also in the PATH-Variable of the system. I removed all old path’s from the registry and started the server service (LanmanServer) again. – And like a wonder… the server service keeps up and running, without crashing again.

So what’s the moral of the story…. Keep in mind where you have entered a custom network path in system environment variables and remove them properly if they are not available anymore. Theny you can avoid lot of mysterious problems in your network.

Roland

Leave a Reply

Your email address will not be published. Required fields are marked *

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: