Probably, you have some services with the option "Keep data in memory" checked (or a file or transaction open). You can find them using "Profile..." button in Global Updates form.

I have one service in the system with Keep Data in Memory set. It is defined in the asn as being run local to the client rather than on the server, and is used to hold the login details for the client session.  It's possible it's being run by one of the other services from the server, but all these services should be started stateless, and therefore close themselves and their children down.  Is there any way of querying the userver to find out what the 'has context' context actually IS rather than trying to guess how it got in that state? It'd be much easier if I had a clue what the context was so I could track it back to its inception. 

At this moment there unfortunately is no straight forward way to get this information (by either querying the UServer or the URouter). I know that this matter is currently being discussed in the lab. And we might see some improvements for the URouter Monitor API in the future that can provide more details about what is causing a UServer process to have state. But this does not really help you right now. Maybe it would be an idea to add some "debugging" messages to the INIT and CLEANUP operation of a component. With that info you could check which instance(s) is(/are) still "active" (i.e. look for the instances where the CLEANUP operation has not been executed). I agree that this is not really ideal, but it might help you to identify the component that causes the UServer process to have context. Hope this helps. Regards, Daniel UPDATE: In case "Keep data in memory" is the culprit then it probably is necessary to do a clear before the specific instance is quit (e.g. in the CLEANUP trigger).