> By inserting print statements into win32com/client/__init__.py, I've > established that the crash is occuring in the call to > self._oldobj_.InvokeTypes(...) in DispatchBaseClass._ApplyTypes_.
Unfortunately, _InvokeTypes_ is the main "entry point" for *all* COM calls with type information. As part of this call, Python packs all Python args into VARIANTs, then makes the actual call to the COM object. Thus, I see 2 possibilities: * pythoncom has a bug in InvokeTypes, probably in arg packing or unpacking. * The COM object has a bug once control has been passed to that. If pythoncom does have such a bug, it is subtle - all other COM objects generally work fine. Also, the symptoms don't really match what Python would do - the only thing I can see that would cause Python to "abort" like that is a call to Py_FatalError - that does indeed call the C 'abort' function, but will always cause some short error text to be printed before termination. I'm afraid that my guess is that it is the remote object. If it happens only after a CastTo, I suspect that something is going wrong there. Even though we "CastTo" an interface (IFMANWiffFile2 in this example), we are *still* using IDispatch on the object. If the remote object expected a "real" interface rather than an IDispatch based one, or the CastTo source object is incorrect, I could see how this could happen. > If this is a bug in pywin, is this enough information to fix > it? If not, how can I generate more helpful information? I'm afraid it is tricky without a debug build of pywin32. Mark _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32