Check if unmanaged DLL is 32-bit or 64-bit?
Asked Answered
L

5

50

How can I programmatically tell in C# if an unmanaged DLL file is x86 or x64?

Lookout answered 16/6, 2009 at 13:13 Comment(2)
Check out Stack Overflow question How to find if a native DLL file is compiled as x64 or x86?.Manpower
Does this answer your question? How to find if a native DLL file is compiled as x64 or x86?Cataphyll
L
57

Refer to the specifications. Here's a basic implementation:

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).
    //
    using (var fs = new FileStream (dllPath, FileMode.Open, FileAccess.Read))
    using (var 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");

        return (MachineType)br.ReadUInt16();
    }
}

The MachineType enum is defined as:

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,
    IMAGE_FILE_MACHINE_ARM64 = 0xaa64 
}

I only needed three of these, but I included them all for completeness. Final 64-bit check:

// 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;
    }
}
Lookout answered 16/6, 2009 at 16:46 Comment(2)
I added FileAccess.Read to your FileStream instantiation - otherwise it blows us when trying to determine bitness of DLLs in either C:\Windows or C:\Program FilesPox
GetPEKind (msdn.microsoft.com/en-us/library/…) fails in a 64 bit process when checking 32 bit assemblies. Does your code works about it?Hellenhellene
M
22

Using a Visual Studio command prompt, dumpbin /headers dllname.dll works too. On my machine the beginning of the output stated:

FILE HEADER VALUES
8664 machine (x64)
5 number of sections
47591774 time date stamp Fri Dec 07 03:50:44 2007
Mourner answered 7/5, 2010 at 17:31 Comment(0)
S
5

Even easier: check out the System.Reflection.Module class. It includes the GetPEKind method, which returns 2 enums that describe the type of code and the CPU target. No more hex!

(the rest of this very informative post was copied shamelessly from http://www.developersdex.com/vb/message.asp?p=2924&r=6413567)

Sample code:

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

PortableExecutableKinds can be used to check what kind of the assembly. It has 5 values:

ILOnly: The executable contains only Microsoft intermediate language (MSIL), and is therefore neutral with respect to 32-bit or 64-bit platforms.

NotAPortableExecutableImage: The file is not in portable executable (PE) file format.

PE32Plus: The executable requires a 64-bit platform.

Required32Bit: The executable can be run on a 32-bit platform, or in the 32-bit Windows on Windows (WOW) environment on a 64-bit platform.

Unmanaged32Bit: The executable contains pure unmanaged code.

Following are the links:

Module.GetPEKind Method: http://msdn.microsoft.com/en-us/library/system.reflection.module.getpekind.aspx

PortableExecutableKinds Enumeration: http://msdn.microsoft.com/en-us/library/system.reflection.portableexecutablekinds(VS.80).aspx

ImageFileMachine Enumeration: http://msdn.microsoft.com/en-us/library/system.reflection.imagefilemachine.aspx

Stillwell answered 1/7, 2009 at 17:52 Comment(1)
This only works if you can actually load the assembly in your process. If the machine type and bitness don't match, you'll get a "Bad Image Format" exception at Assembly.LoadFile() and you'll never get to GetPEKind()Lookout
J
1

Instead of Assembly.LoadFile, use Assembly.ReflectionOnlyLoadFrom. This will let you work around the "Bad Image Format" exceptions.

Justiciable answered 8/5, 2012 at 20:55 Comment(1)
I'm still getting a System.BadImageFormatException when using Assembly.ReflectionOnlyLoadFrom, unfortunately.Kancler
R
0

I know it has been a while since this was updated. I was able to get away with the "Bad Image Format" exceptions by loading the file into it's own AppDomain.

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

At this point, I do the following:

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

Running this against my Widows\Assembly directory gives me zero errors with over 3600 files processed. note: I use a dictionary to load the values being returned.

I hope it helps. YMMV

Rheometer answered 8/2, 2019 at 22:20 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.