43

Вопрос по 32-bit, 64bit, dll, c# – Проверьте, является ли неуправляемая DLL 32-битной или 64-битной?

Как я могу программно сказать в C #, еслиunmanaged DLL файл x86 или x64?

5 ответов
  • 46

    Ссылаться на

    технические характеристики, Вот основная реализация:

    public static MachineType GetDllMachineType(string dllPath)
    {
        // See http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx
        // Offset to PE header is always at 0x3C.
        // The PE header starts with "PE\0\0" =  0x50 0x45 0x00 0x00,
        // followed by a 2-byte machine type field (see the document above for the enum).
        //
        FileStream fs = new FileStream(dllPath, FileMode.Open, FileAccess.Read);
        BinaryReader br = new BinaryReader(fs);
        fs.Seek(0x3c, SeekOrigin.Begin);
        Int32 peOffset = br.ReadInt32();
        fs.Seek(peOffset, SeekOrigin.Begin);
        UInt32 peHead = br.ReadUInt32();
    
        if (peHead!=0x00004550) // "PE\0\0", little-endian
            throw new Exception("Can't find PE header");
    
        MachineType machineType = (MachineType) br.ReadUInt16();
        br.Close();
        fs.Close();
        return machineType;
    }
    

    MachineType enum определяется как:

    public enum MachineType : ushort
    {
        IMAGE_FILE_MACHINE_UNKNOWN = 0x0,
        IMAGE_FILE_MACHINE_AM33 = 0x1d3,
        IMAGE_FILE_MACHINE_AMD64 = 0x8664,
        IMAGE_FILE_MACHINE_ARM = 0x1c0,
        IMAGE_FILE_MACHINE_EBC = 0xebc,
        IMAGE_FILE_MACHINE_I386 = 0x14c,
        IMAGE_FILE_MACHINE_IA64 = 0x200,
        IMAGE_FILE_MACHINE_M32R = 0x9041,
        IMAGE_FILE_MACHINE_MIPS16 = 0x266,
        IMAGE_FILE_MACHINE_MIPSFPU = 0x366,
        IMAGE_FILE_MACHINE_MIPSFPU16 = 0x466,
        IMAGE_FILE_MACHINE_POWERPC = 0x1f0,
        IMAGE_FILE_MACHINE_POWERPCFP = 0x1f1,
        IMAGE_FILE_MACHINE_R4000 = 0x166,
        IMAGE_FILE_MACHINE_SH3 = 0x1a2,
        IMAGE_FILE_MACHINE_SH3DSP = 0x1a3,
        IMAGE_FILE_MACHINE_SH4 = 0x1a6,
        IMAGE_FILE_MACHINE_SH5 = 0x1a8,
        IMAGE_FILE_MACHINE_THUMB = 0x1c2,
        IMAGE_FILE_MACHINE_WCEMIPSV2 = 0x169,
    }
    

    Мне нужно было только три из них, но я включил их все для полноты. Финальная 64-битная проверка:

    // Returns true if the dll is 64-bit, false if 32-bit, and null if unknown
    public static bool? UnmanagedDllIs64Bit(string dllPath)
    {
        switch (GetDllMachineType(dllPath))
        {
            case MachineType.IMAGE_FILE_MACHINE_AMD64:
            case MachineType.IMAGE_FILE_MACHINE_IA64:
                return true;
            case MachineType.IMAGE_FILE_MACHINE_I386:
                return false;
            default:
                return null;
        }
    }
    

  • 1

    Вместо

    Assembly.LoadFileиспользоватьAssembly.ReflectionOnlyLoadFrom, Это позволит вам работать с «Плохим форматом изображения». исключения.

  • 0

    Я знаю

    что прошло много времени с тех пор, как это было обновлено. Мне удалось избежать "плохого формата изображения" исключения, загружая файл в собственный домен приложений.

            private static (string pkName, string imName) FindPEKind(string filename)
        {
            // some files, especially if loaded into memory
            // can cause errors. Thus, load into their own appdomain
            AppDomain tempDomain = AppDomain.CreateDomain(Guid.NewGuid().ToString());
            PEWorkerClass remoteWorker =
                (PEWorkerClass)tempDomain.CreateInstanceAndUnwrap(
                    typeof(PEWorkerClass).Assembly.FullName,
                    typeof(PEWorkerClass).FullName);
    
            (string pkName, string imName) = remoteWorker.TryReflectionOnlyLoadFrom_GetManagedType(filename);
    
            AppDomain.Unload(tempDomain);
            return (pkName, imName);
        }
    

    На данный момент я делаю следующее:

            public (string pkName, string imName) TryReflectionOnlyLoadFrom_GetManagedType(string fileName)
        {
            string pkName;
            string imName;
            try
            {
                Assembly assembly = Assembly.ReflectionOnlyLoadFrom(assemblyFile: fileName);
                assembly.ManifestModule.GetPEKind(
                    peKind: out PortableExecutableKinds peKind,
                    machine: out ImageFileMachine imageFileMachine);
    
                // Any CPU builds are reported as 32bit.
                // 32bit builds will have more value for PortableExecutableKinds
                if (peKind == PortableExecutableKinds.ILOnly && imageFileMachine == ImageFileMachine.I386)
                {
                    pkName = "AnyCPU";
                    imName = "";
                }
                else
                {
                    PortableExecutableKindsNames.TryGetValue(
                        key: peKind,
                        value: out pkName);
                    if (string.IsNullOrEmpty(value: pkName))
                    {
                        pkName = "*** ERROR ***";
                    }
    
                    ImageFileMachineNames.TryGetValue(
                        key: imageFileMachine,
                        value: out imName);
                    if (string.IsNullOrEmpty(value: pkName))
                    {
                        imName = "*** ERROR ***";
                    }
                }
    
                return (pkName, imName);
            }
            catch (Exception ex)
            {
                return (ExceptionHelper(ex), "");
            }
        }
    

    Выполнение этого в моем каталоге Widows \ Assembly дает мне ноль ошибок при обработке более 3600 файлов. примечание: я использую словарь для загрузки возвращаемых значений.

    Я надеюсь, что это помогает. YMMV

  • 21

    Используя командную строку Visual Studio

    также работает dumpbin / headers dllname.dll. На моей машине начало вывода указано:

    FILE HEADER VALUES
    8664 machine (x64)
    5 number of sections
    47591774 time date stamp Fri Dec 07 03:50:44 2007
    

  • 5

    Еще проще

    проверьте класс System.Reflection.Module. Он включает метод GetPEKind, который возвращает 2 перечисления, которые описывают тип кода и цель процессора. Нет больше гекса!

    (Остальная часть этого очень информативного поста была беззастенчиво скопирована сhttp://www.developersdex.com/vb/message.asp?p=2924&r=6413567)

    Образец кода:

    Assembly assembly = Assembly.ReflectionOnlyLoadFrom(@"<assembly Path>");
    PortableExecutableKinds kinds;
    ImageFileMachine imgFileMachine;
    assembly.ManifestModule.GetPEKind(out kinds, out imgFileMachine);
    

    PortableExecutableKinds можно использовать для проверки того, какая сборка. Это имеет 5 значений:

    ILOnly: исполняемый файл содержит только промежуточный язык Microsoft (MSIL), и поэтому является нейтральным по отношению к 32-разрядному или 64-разрядному платформ.

    NotAPortableExecutableImage: файл не находится в переносимом исполняемом файле (PE) формат файла.

    PE32Plus: исполняемый файл требует 64-битной платформы.

    Required32Bit: исполняемый файл может быть запущен на 32-битной платформе или в 32-битная среда Windows на Windows (WOW) на 64-битной платформе.

    Unmanaged32Bit: исполняемый файл содержит чистый неуправляемый код.

    Ниже приведены ссылки:

    Метод Module.GetPEKind: http://msdn.microsoft.com/en-us/library/system.reflection.module.getpekind.aspx

    Перечисление PortableExecutableKinds: http://msdn.microsoft.com/en-us/library/system.reflection.portableexecutablekinds(VS.80).aspx

    Перечисление ImageFileMachine: http://msdn.microsoft.com/en-us/library/system.reflection.imagefilemachine.aspx