Dll ошибка 193

Edit: Though what follows makes sense it is actually incorrect. I’m keeping it here just for reference, but I may delete the answer later.

Note however that (at least on Windows 10, which I used to check) even if relocation information is available in the file, if the module is not a DLL it is not applied, so even if you didn’t get that error, unless your INTERFAC.DLL applies relocations to PCLDRN.exe after loading it, trying to use it is likely to break somewhere along the way.

With the loader snaps output the situation seems pretty obvious to me.

The loader snaps output once the file is found are (I numbered the lines):

(1)  18a0:2a40 @ 06859098 - LdrpMapViewOfSection - ENTER: DLL name: C:QAPcdlrnWin32ReleasePCDLRN.exe
(2)  'CNCServer.exe': Loaded 'C:QAPcdlrnWin32ReleasePCDLRN.exe', Symbols loaded.
(3)  18a0:2a40 @ 06859597 - LdrpMapViewOfSection - RETURN: Status: 0x40000003
(4)  'CNCServer.exe': Unloaded 'C:QAPcdlrnWin32ReleasePCDLRN.exe'
(5)  18a0:2a40 @ 06859597 - LdrpFindOrMapDll - RETURN: Status: 0xc000007b
(6)  18a0:2a40 @ 06859597 - LdrpLoadImportModule - ERROR: Loading DLL PCDLRN.exe from path C:QAPcdlrnCNCSERVERWin32Release;C:Windowssystem32;C:Windowssystem;C:Windows;.;C:Program Files (x86)Microsoft Visual Studio 14.0Common7IDECommonExtensionsMicrosoftTeamFoundationTeam ExplorerNativeBinariesx86;C:windowssystem32;C:windows;C:Program Files (x86)NVIDIA CorporationPhysXCommon;C:Program Files (x86)InteliCLS Client;C:Program FilesInteliCLS Client;C:Windowssystem32;C:Windows;C:
(7)  18a0:2a40 @ 06859597 - LdrpLoadImportModule - RETURN: Status: 0xc000007b
(8)  18a0:2a40 @ 06859597 - LdrpHandleOneOldFormatImportDescriptor - ERROR: Loading "?????" from the import table of DLL "C:QAPcdlrnWin32ReleaseINTERFAC.DLL" failed with status 0xc000007b
(9)  18a0:2a40 @ 06859613 - LdrpUnloadDll - INFO: Unmapping DLL "C:QAPcdlrnWin32ReleaseINTERFAC.DLL"
(10) 'CNCServer.exe': Unloaded 'C:QAPcdlrnWin32ReleaseINTERFAC.dll'
(11) 18a0:2a40 @ 06859613 - LdrpLoadDll - RETURN: Status: 0xc000007b
(12) 18a0:2a40 @ 06859613 - LdrLoadDll - RETURN: Status: 0xc000007b

LdrpMapViewOfSection returns an error code (0x40000003) on line 3 which causes the module to unload (line 4) and then LdrpMapViewOfSection‘s caller — LdrpFindOrMapDll — translates the error code to 0xc000007b (STATUS_INVALID_IMAGE_FORMAT).

But the error that caused the load to fail was 0x40000003 — STATUS_IMAGE_NOT_AT_BASE. The description of this NTSTATUS is:

{Image Relocated} An image file could not be mapped at the address that is specified in the image file. Local fixes must be performed on this image.

(Source: NTSTATUS Values)

By default, EXEs don’t contain relocation information (as was mentioned in the comments). Usually that’s not a problem as the address space is rather free when the EXE is loaded into it. But your address space isn’t free. To make matters worse, all EXEs compiled by Visual C++ share the same base address by default:

The /BASE option sets a base address for the program, overriding the default location for an .exe or DLL file. The default base address for an .exe file is 0x400000 for 32-bit images or 0x140000000 for 64-bit images. For a DLL, the default base address is 0x10000000 for 32-bit images or 0x180000000 for 64-bit images.

(Source: Linker Options: /BASE (Base Address))

That’s probably the situation you have. CNCServer.exe already occupies 0x400000 and that’s the only place PCDLRN.exe can go. LdrpMapViewOfSection can’t map PCDLRN.exe to 0x400000 because it isn’t free and fails to map in anywhere else because there’s no relocation information.

And from there it goes up the call stack and changes the error, but not the underlying problem. Which is lack of relocation information.

You can see what happened when this error is encountered for a DLL with relocation information in your output too. When INTERFAC.dll is initially loaded:

18a0:2a40 @ 06858989 - LdrpFindOrMapDll - ENTER: DLL name: C:QAPcdlrnWin32ReleaseINTERFAC.DLL DLL path: C:QAPcdlrnCNCSERVERWin32Release;C:Windowssystem32;C:Windowssystem;C:Windows;.;C:Program Files (x86)Microsoft Visual Studio 14.0Common7IDECommonExtensionsMicrosoftTeamFoundationTeam ExplorerNativeBinariesx86;C:windowssystem32;C:windows;C:Program Files (x86)NVIDIA CorporationPhysXCommon;C:Program Files (x86)InteliCLS Client;C:Program FilesInteliCLS Client;C:Windows
    18a0:2a40 @ 06858989 - LdrpSearchPath - ENTER: DLL name: C:QAPcdlrnWin32ReleaseINTERFAC.DLL DLL path: C:QAPcdlrnCNCSERVERWin32Release;C:Windowssystem32;C:Windowssystem;C:Windows;.;C:Program Files (x86)Microsoft Visual Studio 14.0Common7IDECommonExtensionsMicrosoftTeamFoundationTeam ExplorerNativeBinariesx86;C:windowssystem32;C:windows;C:Program Files (x86)NVIDIA CorporationPhysXCommon;C:Program Files (x86)InteliCLS Client;C:Program FilesInteliCLS Client;C:Windowss
        18a0:2a40 @ 06858989 - LdrpResolveFileName - ENTER: DLL name: C:QAPcdlrnWin32ReleaseINTERFAC.DLL
        18a0:2a40 @ 06858989 - LdrpResolveFileName - RETURN: Status: 0x00000000
        18a0:2a40 @ 06858989 - LdrpResolveDllName - ENTER: DLL name: C:QAPcdlrnWin32ReleaseINTERFAC.DLL
        18a0:2a40 @ 06858989 - LdrpResolveDllName - RETURN: Status: 0x00000000
    18a0:2a40 @ 06858989 - LdrpSearchPath - RETURN: Status: 0x00000000
    18a0:2a40 @ 06859036 - LdrpMapViewOfSection - ENTER: DLL name: C:QAPcdlrnWin32ReleaseINTERFAC.DLL
'CNCServer.exe': Loaded 'C:QAPcdlrnWin32ReleaseINTERFAC.dll', Symbols loaded.
    18a0:2a40 @ 06859098 - LdrpMapViewOfSection - RETURN: Status: 0x40000003
    18a0:2a40 @ 06859098 - LdrpRelocateImage - ENTER: DLL name: C:QAPcdlrnWin32ReleaseINTERFAC.DLL
        18a0:2a40 @ 06859098 - LdrpProtectAndRelocateImage - RETURN: Status: 0x00000000
    18a0:2a40 @ 06859098 - LdrpRelocateImage - RETURN: Status: 0x00000000
18a0:2a40 @ 06859098 - LdrpFindOrMapDll - RETURN: Status: 0x00000000

When LdrpMapViewOfSection returns STATUS_IMAGE_NOT_AT_BASE, it’s caller (LdrpFindOrMapDll) goes ahead and calls LdrpRelocateImage, something it apparently can’t to for PCDLRN.exe.

I am creating a C++/CLI dll that will be loaded into a legacy c++ application. The legacy application does this with a traditional call to LoadLibrary. Both the application and the C++/CLI dll are compiled in 64 bit mode.

When the LoadLibrary call happens, it fails with error 193. This usually means that some non-64bit component is trying to load. When I look at the dll load output in visual studio 2010, I see the the failure is occurring when mscoree.dll is being loaded (to be exact, I see my dll loaded, then mscoree loaded, then mscoree unloaded, then my dll unloaded, then the error returned). Specifically C:WindowsSystem32mscoree.dll is being loaded, when I examine this mscoree.dll, I find that it is targeting I386.

How can I ensure that my application will link against the correct mscoree.dll? I understand this could be done with a manifest, but I can’t find any good information about setting one up. The ideal solution would allow compilation in 32bit or 64bit mode and target the correct mscoree.dll.

As a side note, I found an mscoree.dll in a side-by-side folder that I verified is 64bit mode and copied it into my application directory with the hopes that it would pick up that one first. This didnt work and the C:WindowsSystem32 version was still loaded.

Thanks,

Max

Output of CorFlags.exe on the C++/CLI dll

Microsoft (R) .NET Framework CorFlags Conversion Tool.  Version  4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32+
CorFlags  : 16
ILONLY    : 0
32BIT     : 0
Signed    : 0

Output of pedump.exe on C:System32mscoree.dll

PS C:WindowsSystem32> pedump.exe .mscoree.dll
Dump of file .MSCOREE.DLL

File Header
  Machine:                      014C (I386)
  Number of Sections:           0004
  TimeDateStamp:                4B90752B -> Thu Mar 04 22:06:19 2010
  PointerToSymbolTable:         00000000
  NumberOfSymbols:              00000000
  SizeOfOptionalHeader:         00E0
  Characteristics:              2102
    EXECUTABLE_IMAGE
    32BIT_MACHINE
    DLL
...

(pedump goes on from here to describe imports and exports but thats not important here)

Extended loading information

This is the full output from failed load.

Note: The C++/CLI dll is called DsfClr.dll
the output was obtained by running gflags.exe -i [exename] +sls and examining the results in a debugger

http://pastebin.com/FyumUiMN

UPDATE:

Using a tip posted in a below comment by Reuben, I was able to determine that mscoree.dll is indeed targeting AMD64, but pedump is providing invalid information because it is being run in WOW64. That being said I still cannot load this library, if anyone has any suggestions they would be greatly appreciated.
One more thing I have tried: I made a new C# application and referenced the C++/CLI dll, then, in the main() function, I instantiated a class in the C++/CLI dll. This caused an access violation exception before the main() function is called. When I remove the instantiation, the main function runs fine. My guess is that the instantiation is causing a delay load of my C++/CLI assembly, which causes the same load error I was seeing from the native assembly.