On Fri, 09 Jul 2004 10:17:07 -0700, Duane Clark wrote:
> If I had some idea of what is going on in the traces, I would attempt to
> do some debugging. Do you know of any "Marshalling for dummies" or some
> such thing? Currrently the traces are complete jibberish to me.
>
> Is this likely to be a result of the unimplemented functions in the
> traces? fixme:ole:FTMarshalImpl_GetUnmarshalClass (), stub!
> fixme:ole:FTMarshalImpl_MarshalInterface (), stub!
Hmm, well, OLE marshalling isn't something you can explain in 5 minutes
... I keep meaning to do this but if you like I'll post a complete (to my
knowledge) explanation of how it all works say over the weekend or on
Monday.
But to get you started, I don't know if the FTM stubs are a problem or
not, but this bit almost certainly is:
trace:ole:CoUnmarshalInterface
(0x402b4180,{27a4f276-6452-11d2-ba1d-0008c7a01e5d},0x46cb413c)
trace:ole:WINE_StringFromCLSID 0x46cb4014->{402B4180-FA0C-40EE-EBF8-EE40F0CE5360}
trace:ole:CoGetClassObject
CLSID: {402b4180-fa0c-40ee-ebf8-ee40f0ce5360},
IID: {00000001-0000-0000-c000-000000000046}
warn:ole:CoGetClassObject class {402B4180-FA0C-40EE-EBF8-EE40F0CE5360} not registered
Basically as part of unmarshalling an interface, a "proxy/stub class
factory" is activated. This is a COM object that implements
IPSFactoryBuffer:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/htm/cmi_n2p_459u.asp
which as you can see can then be used to construct proxy and stub objects.
Therefore if this object cannot be activated for whatever reason,
unmarshalling cannot continue and we bail out, handing the app a
null vtable which it then dereferences.
So you need to figure out why {402b4180-fa0c-40ee-ebf8-ee40f0ce5360} isn't
being registered, which may involve figuring out what it actually is :)
Good luck! If a more complete marshalling explanation would be useful, let
me know and I'll see what I can do in a few days.
thanks -mike
