I'm having the same problem.
I noticed that the arb backend's destructor is being called twice, recursively.
The outer destruction starts while DLL_PROCESS_DETACHing, while the other 
spawns while removing the backend from the backend's list (destruction of the 
shared pointer inside the static map of backends 
ShBackend::m_instantiated_backends).
The problem could be avoided either by converting the ShPointer<ShBackend> in 
BackendMap to a standard ShBackend* (this will solve THIS problem, but more 
will arise from the others ShPointer<ShBackend> around).
Another, more complex solution could be letting ShBackend manage the memory and 
add some functions to register, instantiate and deinstantiate the backend onto 
ShBackend, and replacing the new/delete couple with.
Anyway, the instantiation/deinstantiation of a Backend is a bit confused.
I think that the thing will broke anyway if you run two applications sharing 
the same dlls.
It's not very clear to me if a backend-derived class should be a per process 
singleton, a cross process singleton or just an object as the others (I'm 
referring to the arb backend in particular, but I think this will apply to the 
other backends, too):
By the code in dllmain it looks like a per process singleton (every attached 
process create a new backend). 
On the other hand, the code in ShBackend seems to link the life of the only 
ArbBackend to the life of the libsh dll, so it looks like a cross process 
singleton, since the registration is linked to construction of a subclass and 
deregistration of linked to destruction of a subclass.
On the other hand again (third one?) the shBackend_libsharb_instantiate can be 
used to create another backend, and I can't catch this one.
Is this a design issue, or it's just me not being able to catch the 
instantiation mechanism?