Каковы неочевидные причины сбоя 32-битного приложения на 64-битной машине?

Question

У нас есть 32-битная библиотека, написанная и скомпилированная в Borland Delphi.На эту библиотеку ссылаются различные другие проекты, в том числе веб-служба WCF, размещенная в IIS.Веб-сервис скомпилирован с использованием опции x86, и все отлично работает на 32-битной машине.Однако на нашем 64-битном сервере служба перестает работать при вызове 32-битной библиотеки Delphi.У некоторых наших клиентов даже возникают проблемы с вызовом 32-битных .NET форм в библиотеку на 64-битной машине;хотя мы не смогли дублировать эту конкретную проблему.

Итак, кто-нибудь знает, почему .NET-код, скомпилированный с 32-битной опцией, все равно не будет работать при вызове не-.NET 32-битной библиотеки на 64-битной машине?

Answer 1

Я предполагаю, что вы определяете точку входа метода на стороне .NET как-то так?

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

и затем вы вызываете его где-то аналогичным образом?

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

Если это так (ваш пробег может отличаться в реальной реализации), вы можете переписать его следующим образом:

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);
}

Это должно внести в журнал событий компьютера подробное объяснениепроизошло, когда был назван 32-битный кусок.Оттуда вы (и, возможно, мы) можете получить некоторые убедительные доказательства того, что может быть неудачным.

Answer 2

куча коррупции!По-видимому, есть флаг HeapEnableTerminationOnCorruption, который ранее не был включен по умолчанию.Как новая функция в Windows Vista, рабочий процесс IIS завершается при обнаружении повреждения кучи.Таким образом, оказалось, что он работает только в наших автономных приложениях и на наших 32-битных компьютерах с Windows XP, когда на самом деле он просто игнорировал ошибку.в библиотеки Delphi, чтобы использовать IntPtrs и передавать данные обратно, используя параметры.Например:

    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;
    }

Надеюсь, что это поможет любому с той же проблемой.

Answer 3

Ну, просто дикая догадка:)

Есть ли у вас более одного процесса, взаимодействующего? Эти процессы пытаются записывать / читать в защищенные папки (например,% PROGRAMFILES%,% WINDIR%)? (то есть эти процессы используют файлы в таких папках, как IPC?)

Поскольку 64-разрядная система Windows будет перенаправлять записи в такие папки для 32-разрядных приложений (для каждого пользователя), если процессы выполняются с разными учетными данными, эти процессы могут просто не найти файл, созданный другим процессом.