Error activating IInterceptor... only through COM?

Error activating IInterceptor... only through COM?

TL;DR: Kernel.Get<T> works when called from a .net/WPF app, but blows up
with an inner ActivationException (inside a TargetInvocationException)
when called from a VB6 app. WTH?
This is a bit of a follow-up on this question where I configured an
abstract factory with Ninject conventions, in such a way that I never need
to actually implement one, the Ninject factory extension takes care of
generating one on-the-fly.
This worked beautifully... until I needed to run my library from VB6 code.
_kernel.Bind(t => t.FromAssemblyContaining(typeof(ViewModelBase))
.SelectAllInterfaces()
.EndingWith("ViewFactory")
.BindToFactory());
As soon as I call anything on the app from VB6 code, I get an exception in
the composition root /entry point and by wrapping the resolving of
dependencies inside a try/catch block, I'm trapping a
TargetInvocationException with an inner ActivationException:
Error activating IInterceptor using conditional implicit self-binding of
IInterceptor Provider returned null. Activation path:
3) Injection of dependency IInterceptor into parameter of constructor of
type IViewFactoryProxy
2) Injection of dependency IViewFactory into parameter viewFactory of
constructor of type MsgBox
1) Request for IMsgBox
Suggestions:
1) Ensure that the provider handles creation requests properly.
At first I thought my IInterceptor implementations weren't configured
properly, but then I realized I was not using them anywhere yet (they're a
recent addition). So just to make sure I removed the reference to the
Ninject.Interception extension... and I still get the exact same message.
Oddly if instead of launching VB6 I launch a sandbox WPF test app when I
debug, I don't get any ActivationException and everything works like a
charm.
To me this doesn't make any sense, it's just an empty constructor being
called, whether the caller is a WPF application or a VB6 ActiveX DLL
shouldn't make any difference. So what's going on?
The VB6 code dies with automation error -2146232828 (80131604) which
yields nothing on Google, but I'm guessing it has to do with the
TargetInvocationException being thrown.
As far as .net code is concerned it just works: if I compose the app from
a WPF client I can break in the MsgBox class constructor and see that the
IViewFactory is happy with a Castle.Proxy.IViewFactoryProxy; if I compose
the app from a VB6 ActiveX DLL (I also created a VB6 EXE to test and same
as the DLL), it blows up.