Quelles sont les raisons non évidentes pour lesquelles une application 32 bits échouerait sur une machine 64 bits?

Question

Nous avons une bibliothèque 32 bits écrite et compilée dans Borland Delphi. Cette bibliothèque est référencée par divers autres projets, y compris un service Web WCF hébergé dans IIS. Le service Web est compilé à l'aide de l'option x86 et tout fonctionne correctement sur une machine 32 bits. Cependant, sur notre serveur 64 bits, le service échoue lors de l'appel dans la bibliothèque Delphi 32 bits. Certains de nos clients ont même des problèmes avec les formulaires .NET 32 bits appelant dans la bibliothèque sur une machine 64 bits; bien que nous n'avons pas été en mesure de reproduire ce problème particulier. Donc, quelqu'un sait-il pourquoi le code .NET compilé avec l'option 32 bits échouerait tout en appelant une bibliothèque 32 bits non .NET sur une machine 64 bits?

Answer 1

Eh bien, juste une conjecture sauvage :)

Avez-vous plus d'un processus d'interaction ?. Ces processus essaient-ils d'écrire/lire dans des dossiers protégés (par exemple% PROGRAMFILES%,% WINDIR%)? (par exemple, est-ce que ces processus utilisent des fichiers dans des dossiers tels que IPC?)

Depuis Windows 64 bits redirige les écritures vers ces dossiers pour les applications 32 bits (sur une base par utilisateur) si les processus fonctionnent avec des informations d'identification d'utilisateur différentes. les processus peuvent ne pas trouver un fichier créé par l'autre processus.

Answer 2

Je suppose que vous définissez le point d'entrée de la méthode sur le côté .NET quelque chose comme ça?

internal static class Delphi 
{ 
    [DllImport("delphi32bitlibrary.dll")] 
    [return: MarshalAs(UnmanagedType.Bool)] 
    internal static extern bool Encrypt(
     IntPtr parameter1, 
     string parameter2, 
     out string parameter3); 
} 

puis vous l'appelez quelque part d'une manière similaire?

string encryptedString; 
Delphi.Encrypt(IntPtr.Zero, "test", out encryptedString); 

Si tel est le cas (votre kilométrage peut varier dans la mise en œuvre effective), pouvez-vous réécrire comme tel:

string encryptedString; 
try 
{ 
    Delphi.Encrypt(IntPtr.Zero, "test", out encryptedString); 
} 
catch (Exception ex) 
{ 
    EventLog log = new EventLog(); 

    log.WriteEntry(ex.Message + "\n" + ex.StackTrace, EventLogEntryType.Error); 
} 

Cela devrait mettre à l'épreuve de l'ordinateur se connecter une explication détaillée de ce arrivé lorsque la pièce de 32 bits a été appelée. De là, vous (et peut-être nous) pouvez obtenir de bonnes preuves de ce qui peut échouer.

Answer 3

Heap corruption! Apparemment, il existe un indicateur appelé HeapEnableTerminationOnCorruption qui n'était pas précédemment activé par défaut. En tant que nouvelle fonctionnalité de Windows Vista, le processus de travail IIS se termine lorsque la corruption du tas est détectée. Ainsi, il ne s'est avéré que fonctionner dans nos applications autonomes et sur nos machines Windows XP 32 bits, alors qu'en réalité, il ignorait tout simplement l'erreur.

Pour résoudre ce problème, nous avons modifié notre code d'appel dans les bibliothèques Delphi pour utiliser IntPtrs et retransmettre les données en utilisant les paramètres out. Par exemple:

public string CallDLL(string sTest) 
    { 
     string s = ""; 

     IntPtr p1 = Marshal.StringToHGlobalAnsi(sTest); 
     s = Marshal.PtrToStringAnsi(p1); 
     if (p1 != IntPtr.Zero) 
     { 
      Class1.TestDLL(out p1); 
      s = Marshal.PtrToStringAnsi(p1); 
     } 

     Marshal.FreeCoTaskMem(p1); 
     return s; 
    } 

Espérons que cela aide n'importe qui avec le même problème.