[.Net]Gebruik van COM ActiveX controls in .Net

[urk_forever]

Hallo allemaal, voor mijn werk maak ik soms applicaties die gebruik maken van COM ActiveX controls. Over het algemeen werkt dit wel, alleen bij een bepaald control krijgen we bij het afsluiten van de .Net applicatie de volgende foutmelding:

Application error

The instruction at "0x050dd5ac" referenced memory at "0x00000030". The memory could not be "read".

Het instructie adres wisselt nog wel, maar het geheugen adres is altijd 0x00000030. Nu heb ik op Google al gezocht tot ik een ons woog maar ik heb de oplossing nog niet kunnen vinden. Ik heb bijvoorbeeld deze pagina gevonden:

http://www.codeproject.com/csharp/LingeringCOMObjects.asp

Die wat uitleg geeft over Com events in een .Net applicatie. Helaas zijn de oplossingen die hier aangedragen worden niet de oplossingen voor dit probleem.

Weet iemand misschien waar deze fouten vandaan komen en hoe ik ze op kan lossen?

[MrBucket]

Om welk ActiveX control gaat het? Is het een standaard microsoft control, of is het van een third party? In het laatste geval, weet je waarin het ActiveX-control is geschreven (VB, Delphi of iets anders?)

Er schieten me nl. drie mogelijkheden te binnen die deze fout kunnen veroorzaken (maar het kan ook aan iets anders liggen):

1. Het ActiveX-control is zelf niet netjes geprogrammeerd, en ergens gaat het vragen om een interface of methode verkeerd. Dit is niet waarschijnlijk als het een MS control betreft, of een die in VB is geschreven (ik geloof, maar weet niet zeker, dat je in VB zelf niet hoeft te zorgen voor 'the plumbing' maar dat dit voor je gedaan wordt - dus minder kans op fouten).
2. Je probeert een object te gebruiken wat al opgeruimd is - dit lijkt me niet waarschijnlijk, want bij mijn weten regelen de .NET wrapper classes de reference counting erg goed, en zullen ze een object niet releasen totdat alle references ernaar toe out of scope zijn.
3. Je ruimt je COM-objecten in de verkeerde volgorde op, (of helemaal niet, waardoor ze mogelijk door de garbage collector in de verkeerde volgorde worden opgeruimd). Dit lijkt me het meest waarschijnlijk.

[urk_forever]

Het is een 3rd party control en het control is denk ik in C++ geschreven. Als ik een standaard C# applicatie maak en ik sleep er alleen zo'n control op en start de applicatie en sluit hem weer dan krijg ik al die fout melding. Dan heb ik nog geen letter code geschreven.

Het gebruik van dit control in VB6 gaat wel goed zonder fouten.

[SKiLLa]

Inclusief [STAThread] of niet ?

Heb ongeveer hetzelfde gehad met een COM object in C#, was toen altijd adres 0x0000090. Code was onveranderd, maar werkte "spontaan" <x> dagen later niet meer; ook een foutmelding bij het afsluiten van de .Net app. Bleek uiteindelijk een (indirecte) "binary version compatibility" issue te zijn ...

Maar je ruimt dus wel braaf alle references correct op met (iets als) in "Disposing" ... ?

C#:

int refCount = 1;
while (myObject != null && refCount > 0) 
{
     refCount = Marshal.ReleaseComObject(myObject);
}
myObject = null;

[urk_forever]

De applicatie gebruikt [STAThread] ja. Ik doe nog helemaal niks. Ik start een nieuw Windows Application project in VS2005, dan voeg ik het component toe aan mijn toolbox en sleep hem op het form. Dan start ik de applicatie en sluit hem weer af, dan krijg ik de foutmelding.

[sopsop]

Heb je de 'third party' al gecontacteerd?

[urk_forever]

Ja, die geven ook aan dat ik alle references op moet ruimen, maar ik maak zelf dus nog geen 1 reference en ik krijg de fout al.

[MrBucket]

urk_forever schreef op donderdag 18 oktober 2007 @ 09:39:
Ja, die geven ook aan dat ik alle references op moet ruimen, maar ik maak zelf dus nog geen 1 reference en ik krijg de fout al.

Dat kan dus liggen aan het feit dat je ActiveX control events aanbiedt (zoals omschreven in de link die je zelf postte).

[urk_forever]

Dat was mijn idee ook, alleen met de dingen die hij aangeeft kom ik er nog niet echt uit. Ik heb dus met aximp.exe de source van de Interop aangemaakt. En daarin zit maar 1 event wat een comobject geeft en als ik die release net als hij doet dan krijg ik nog steeds deze fout.

[SKiLLa]

Laat dat [STAThread] eens weg; werkt het dan wel goed ?
Uiteraard zal dat icm. Windows.Forms problemen opleveren, maar met een beetje geluk krijg je die error dan niet. Dat kun je dan ook eventueel aan de "producent" melden ...

[urk_forever]

Als ik STAThread weg laat dan wil het programma niet eens meer starten, hij geeft dan een melding dat hij een bepaald object niet kan maken omdat dat niet in dezelfde thread zit.

Iemand anders misschien nog een idee?

[SKiLLa]

Dan moet dat object met .Invoke aangeroepen worden. In veel gevallen kan het weghalen van de [STAThread] voldoende zijn (als workaround totdat het component gefixed wordt) om het werkend te krijgen ...

Je zou inderdaad zelf de Interop proxy class kunnen schrijven als test, maar daar wordt je ook niet vrolijk van ...

[urk_forever]

Ik heb contact gehad met de leverancier. En na het herinstalleren van het pakket en de laatste hotfixes hiervan heb ik het voor elkaar gekregen om dit project zonder fouten te starten. Hiervoor moest ik de bin & obj directories verwijderen en het project opnieuw builden. Dan werkt het opeens wel