As far as I've been able to determine, the lifetime of the ORB_Core entry in the ORB table is handled by ACE_Object_Manager, which executes its own fini() call at exit time. So if a call to ORB::destroy is made in the body of an overridden ACE_Service_Object::fini, it seems that the ACE_Object_Manager::fini is executed first, so when the destroy() call tries to enter a critical section, it finds that its lock has been already destroyed and a crash occurs.

However, if, in the code block where ACE_Service_Config::open is called, there is a matching call to ACE_Service_Config::close, the order of destruction is then correct and all is well. We certainly want to document this behavior, and make it more user friendly if possible. Attachment with code snips will follow shortly.