The first issue seems to have been fixed with some timed retry mods to CfgMgrBldr::Close().
Eeeeeeeeh... please do not ever tamper with that function. This is absolutely no go.
First of all, it is not recommended to use
CfgMgrBldr for anything at all. The actual reason why
CfgMgrBldr has such a stupid name is to give you a hint that this is not thought to be used in normal operation. Treat it as if it was a private internal class of
Manager (although it is not, for simplicity).
Also, calling
Close() will result in undefined behaviour, and will leak memory - use
Free() instead. However, it is best if you don't use Free() either, since that, too,
may result in undefined behaviour.
The configuration manager and all pointer references to it are, by definition, valid from its first invokation to the destruction of the
Manager singleton (which happens immediately before the application is terminated). Parts of the SDK rely on this fact and may crash if you destroy ConfigManager.
The same or similar is true for other managers. The shutdown procedure follows a well-defined order of destruction which ensures that certain things are reliably availabler at given times.
For example, a plugin developer can rely blindly on the availability and validity of
ScriptingManager,
ProjectManager,
EditorManager,
PersonalityManager,
MacrosManager,
UserVariableManager,
MessageManager, and
ConfigManager (no null-pointer checks required!) for the entire lifetime of a plugin.
Also, this ensures that for example
EditorManager is valid for the entire lifetime of
ProjectManager, because the former is used by the latter.
If you free managers in an uncontrolled manner, these contraints are no longer effective and very, very nasty things (which are impossible to debug) may happen.
What
can be done is, you can simply do all your IPC before
ConfigManager is instantiated for the first time. In that case, nothing is saved to the config.