Embedded firefox/xulrunner causing AccessViolationException

Question

Hello, I have for the most part successfully embedded firefox/xulrunner into our c# application, but it is not without troubles. Once in a great while a AccessViolationException will be thrown which I believe is caused by the GC moving a managed object in memory and the unmanaged xpcom attempts to use it after it has been moved. For example I created a protocol handler for a custom protocol that implements some interfaces that firefox/xulrunner calls upon. After doing that, the AccessViolationException's became much more predominate. I looked into GCHandle.Alloc(object, GCHandleType.Pinned) as a possible solution, but couldn't find enough information on how to write a custom marshaller to make my class that implemented the interfaces "blittable". So does anyone have any ideas on how to deal with this problem or how to translate my class into a "blittable" one? Also its near impossible to track down what parts of the interop are causing the AccessViolationException. Ugh :-(

Thanks for any insight!

Answer 1

I believe I have an answer to this through the means of another question I asked "does GetComInterfaceForObject pin the object?". Basically what I believe is the AccessViolationExceptions where being generated by an object going out of scope in the .net side, if my understanding is correct the unmanaged reference will not keep a managed object alive. So any managed object that I create that needs to be around for an extended period of time so the unmanaged code can call upon it, is now stored in either a field or a list. Also on the side of a "blittable" object, I haven't found a way to pin a class, but I did manage to figure out how to pin a struct that implemented an interface. The interface was an interop interface that had MarshalAs attributes defined, which allowed the conversion to unmanaged code, therefore apparently allowing the object to be pinned. Not sure if this is possible with a class implementation as I still received errors even though it was implemented in the same exact manner as the struct.

:-)