You can easily see the root of the problem with Regedit.exe. In order for an interface to bridge the Grand Canyon between process boundaries, it needs code that implements a proxy and a stub for an interface. Code that knows how to serialize the interface method arguments into an RPC packet that can be transmitted from one process to another.
COM discovers that code by looking through the registry. You can too with Regedit.exe, navigate to HKCR\Interfaces and scroll down to match the guid. You will see a lot of {guids} there that look like {305xxxx-98B5-11CF-BB82-00AA00BDCE0B}. Yes, Microsoft cheats on their guids, easier for debugging, IE has rather a lot of them. They point to the standard marshaller and include the type library guid that describes the interface.
But you will not find {3050F669-98B5-11CF-BB82-00AA00BDCE0B}. Which is basically what the exception message is telling you, it can't find a way to marshal the interface pointer. The mysterious E_NOINTERFACE error code is the result of the fallback approach not working either, failing to query for IMarshal.
This is a bit of a toss-up between "they forgot" and "they couldn't make it work". This one heavily leans towards "too hard to make it work". Serializing a render interface is way too difficult, too many dependencies on the video hardware which of course never matches between one machine and another. Or even on one machine, the need to have the graphics pipeline initialized properly before any method calls can be made is far too tricky.
That's where the buck stops, you cannot make this work. You'll need to render that image yourself, not easy to do. Sorry, please don't shoot the messenger.