Seems I really do have a knack of finding these bizarre things. Unhappy with conclusions to date (albeit good) I really wanted to nail it down. Further testing yielded the following (an excerpt from my notes):

Further testing shows that the problem is created exactly by making a global class in the DLL, copying its address to a pointer, and then calling one of the class's COM Interface's methods. Running alongside working code (which uses the dynamic allocation method and only one pointer), one can create a global class of the renderer type, then create a pointer and copy the global class's address to that pointer and the program will still run and shutdown acceptably.

Only when you call one of the methods in the COM interfaces of that class does the program fail to shutdown correctly.

So the exact way to create the fault is:

Make a global class in the DLL. Copy its address into a pointer. Call one of the COM interface's methods (especially CreateFactory) probably through either the pointer or through the global class itself. And do not use AddRef() anywhere. This seems to create two legitimate roads into the class but without the smart COM pointers being aware of it.

Thus when the time comes, the COM interfaces will cause the COM objects they point to, to delete themselves but with one remaining legitimate route into the class staying active. This is what then attempts a release call on a COM object which is already gone, and causes the error on shutdown.