GCHandle gelang AppDomains Code und 3rd-Party-DLL

Question

Ich habe schon in vielen Threads über die Ausnahme suchen „kann nicht eine GCHandle über AppDomains passieren“, aber ich es noch nicht bekommen ....

Ich arbeite mit ein RFID-Reader, der von einer DLL angesteuert wird. Ich habe keinen Quellcode für diese DLL, aber nur ein Beispiel, um zu zeigen, wie man es benutzt.

Das Beispiel funktioniert gut, aber ich muss Code in einem anderen Projekt kopieren, um den Reader der Middleware Microsoft Biztalk hinzuzufügen.

Das Problem ist, dass der Prozess von Microsoft BizTalk in einer anderen AppDomain funktioniert. Der Leser behandelt Ereignisse, wenn ein Tag gelesen wird. Aber wenn ich es unter Microsoft Biztalk starte, habe ich diese lästige Ausnahme.

Ich kann keine Lösung sehen, wie es ...

Hier arbeiten lassen ist ein Code, die interessant sein können:

// Let's connecting the result handlers. 
// The reader calls a command-specific result handler if a command is done and the answer is ready to send. 
// So let's tell the reader which functions should be called if a result is ready to send. 

// result handler for reading EPCs synchronous 
Reader.KSRWSetResultHandlerSyncGetEPCs(ResultHandlerSyncGetEPCs); 

[...] 

var readerErrorCode = Reader.KSRWSyncGetEPCs(); 
if (readerErrorCode == tKSRWReaderErrorCode.KSRW_REC_NoError) 
{ 
    // No error occurs while sending the command to the reader. Let's wait until the result handler was called. 
    if (ResultHandlerEvent.WaitOne(TimeSpan.FromSeconds(10))) 
    { 
     // The reader's work is done and the result handler was called. Let's check the result flag to make sure everything is ok. 
     if (_readerResultFlag == tKSRWResultFlag.KSRW_RF_NoError) 
     { 
      // The command was successfully processed by the reader. 
      // We'll display the result in the result handler. 
     } 
     else 
     { 
      // The command can't be proccessed by the reader. To know why check the result flag. 
      logger.error("Command \"KSRWSyncGetEPCs\" returns with error {0}", _readerResultFlag); 
     } 
    } 
    else 
    { 
     // We're getting no answer from the reader within 10 seconds. 
     logger.error("Command \"KSRWSyncGetEPCs\" timed out"); 
    } 
} 

[...] 

private static void ResultHandlerSyncGetEPCs(object sender, tKSRWResultFlag resultFlag, tKSRWExtendedResultFlag extendedResultFlag, tKSRWEPCListEntry[] epcList) 
{ 
    if (Reader == sender) 
    { 
     // Let's store the result flag in a global variable to get access from everywhere. 
     _readerResultFlag = resultFlag; 

     // Display all available epcs in the antenna field. 
     Console.ForegroundColor = ConsoleColor.White; 
     foreach (var resultListEntry in epcList) 
     { 
      handleTagEvent(resultListEntry); 
     } 

     // Let's set the event so that the calling process knows the command was processed by reader and the result is ready to get processed. 
     ResultHandlerEvent.Set(); 
    } 
} 

Answer 1

Du ein Problem mit dem gcroot<> helper class haben. Es wird in dem Code verwendet, den niemand in dieser DLL sehen kann. Es wird häufig von C++ - Code verwendet, der mit verwaltetem Code interoperieren soll. Gcroot <> speichert einen Verweis auf ein verwaltetes Objekt. Die Klasse verwendet den GCHandle-Typ zum Hinzufügen der Referenz. Die GCHandle.ToIntPtr() -Methode gibt einen Zeiger zurück, den der C++ - Code speichern kann. Die Operation, die fehlschlägt, ist GCHandle.FromIntPtr(), die von dem C++ - Code verwandt wird, um den Verweis auf dem Objekt wiederherzustellen.

Es gibt zwei grundlegende Erklärungen für immer diese Ausnahme:

1. Es kann genau sein. Was passiert, wenn Sie den Code in der DLL von einer AppDomain aus initialisieren und in einer anderen verwenden. Aus dem Ausschnitt, in dem das Reader-Klassenobjekt initialisiert wird, ist nicht klar, dass es nicht Null-Chancen gibt, dass dies die Erklärung ist. Stellen Sie sicher, dass Sie ihn in der Nähe des Codes halten, der die Reader-Klasse verwendet.

2. Es kann durch anderen Fehler verursacht werden, der im C++ Code in der DLL vorhanden ist. Nicht verwalteter Code leidet häufig unter Zeigerfehlern, einem Fehler, der den Speicher versehentlich überschreiben kann. Wenn das mit dem Feld passiert, in dem das gcroot <> Objekt gespeichert ist, dann passiert für eine Weile nichts. Bis der Code versucht, den Objektverweis erneut wiederherzustellen. An diesem Punkt stellt die CLR fest, dass der beschädigte Zeigerwert nicht mehr mit einem tatsächlichen Objekt-Handle übereinstimmt und diese Ausnahme generiert. Dies ist sicherlich die schwere Art von Fehler zu lösen, da dies passiert in Code, den Sie nicht reparieren können und zeigt den Programmierer, der daran arbeitete eine Repro für den Fehler ist sehr schwierig, solche Speicherbeschädigung Probleme nie gut repro.

Chase Kugel # 1 zuerst. Es gibt gute Chancen, dass BizTalk Ihren C# -Code in einer separaten AppDomain ausführt. Und dass die DLL zu früh geladen wird, bevor oder während die AppDomain erstellt wird. Etwas, das Sie mit SysInternals 'ProcMon sehen können. Erstellen Sie eine Wiederholung davon, indem Sie ein kleines Testprogramm schreiben, das eine Anwendungsdomäne erstellt und den Testcode ausführt. Wenn das den Absturz reproduziert, dann haben Sie eine sehr gute Möglichkeit, dem RFID-Anbieter das Problem zu demonstrieren und hoffen, dass sie es verwenden und an einer Lösung arbeiten werden.

Eine gute Arbeitsbeziehung mit dem RFID-Reader-Anbieter, um zu einer Lösung zu kommen, wird sehr wichtig sein. Das ist nie ein Problem, immer ein guter Grund, woanders einkaufen zu gehen.