Troubleshooting Issues with Unregistered Machines and Zombie Sessions in a Single Delivery Group

A user asked for help with a problem in one delivery group where some machines become unregistered and create zombie sessions. This only occurs in one group, and the cuagent is stuck in stopping state on these zombie machines. The ControlUp team suggested looking at dependencies for the cuAgent and checking the event log to see if the OnStop function has finished. They also mentioned troubleshooting the SCM’s responsiveness.

Read the entire ‘Troubleshooting Issues with Unregistered Machines and Zombie Sessions in a Single Delivery Group’ thread below:

So I am tasked with finding out why, in one delivery group only, some of our machines become unregistered and create zombie sessions. Those machines come from a machine catalog that several delivery groups use. Only one of the delivery groups is giving me problems. Which is in of itself weird.

I’ve noticed on the machines that are zombies that the cuagent is stuck in stopping state, so I can’t gather much information from ControlUp. Are there any depencies for the cuAgent that might cause it to get stuck in a stopping state?

(I’ve also noticed the Virtual Disk Service get stuck in a stopping state when I try to restart it, as well as the Citrix Desktop Service. But I find it odd that the ControlUp Agent would also get stuck in this state).

Thanks!

Stopping does seem weird. As far as I’m aware, stopping just means the service control manager sending a signal to our service.

In our case, that ends up with the dot net framework calling the ServiceBase.OnStop function.

We do perform some actions during this OnStop call. But they are very minor.

Once that is done, dot net should signal the service control manager that the service is stopped

Do you see this in the event log? If so, that means that the OnStop function has finished and the internal dot net code has done all its needs to do and has signaled back to the SCM that it is stopped.

You can see the dot net process here for stop.

First it signals to SCM that it is starting the stop process (stop pending).

Then it calls OnStop so we can do what we need to do to gracefully shut the service down.

Then it writes to the event log that the service has stopped and signals the new stopped state

If other services are in a pending stop state, I’d maybe look at whether the SCM is responsive. Perhaps those services have also signaled they have stopped but maybe SCM hasn’t acknowledged that?

Continue reading and comment on the thread ‘Troubleshooting Issues with Unregistered Machines and Zombie Sessions in a Single Delivery Group’.  Not a member? Join Here!