CS 2.3 error "Unable to load DLL 'xxxxxx'"

CS 2.3 w/ Hotfix #1 installed on Windows Server 2008 R2.  VC 2.3 for VS 2013 w/ Hotfix #1 installed on Windows 7 PC.

We are trying to call a native COBOL DLL from an ASPX/C# program using:

[DllImport("WYP46P", EntryPoint = "WYP46P", SetLastError = true, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]

It worked on the PC from the VS IDE.  But from the server we get:

Unable to load DLL 'WYP46P': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

We've tried compiling the DLL as Console and 32-bit/64-bit/Any-PC, Dynamic Link with and without Binding, with and without System Programs.

"Frand" started a forum post "C# calling NE cobol" on 30 Oct 2015 for this exact same error but in Net Express.  That thread never was concluded/answered.

In our case the web application is executing under a "service account" that has admin rights to the hosting server, and the application and CS are installed on the same server.

What did we miss?

  • Verified Answer

    Hi Don,

    When calling a native .dll from an ASP.NET application running under IIS you normally need to set the location of the .dll within your PATH in order for the .dll to be picked up correctly even if it is in the current folder with the application.

    That is because when the web pages are loaded they are compiled and run from a temporary directory which means the .dll is no longer in the "current" folder.

    Try setting the PATH in web.config or in your System environment variables and then rebooting to ensure that IIS picks it up.


  • Thank you, the DLL is now being found.  Since this is all "exploratory" we took the cheap route and used:

    [DllImport(@"D:\inetpub\wwwroot\neasos\NEAS\WYP46P.dll", EntryPoint = "WYP46P", SetLastError = true, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]

    But we've spent the last two days trying to fix/get around this error:

    An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

    We are guessing this is a "bitness" error?  My co-worker is the one actually doing the coding and testing so I only know what he tells me.  He's tried pure Release and Debug, Any PC and x86 builds for all components.  He has "enable 32-bit" in the application config.  Anyone have an idea of what we've missed this time?

  • This most likely is a mismatch of targets between the C# ASP.NET program and the COBOL .DLL. What is the target of the ASP.NET app? If it is x64 or anyCPU and run on a 64-bit computer then the COBOL .dll must also be compiled as x64.

    If the ASP.NET app is targeting x86 or anyCPU and run on a 32-bit computer then the COBOL .dll must be x86.

    Any .dlls that this COBOL .dll calls including the run-time cblrtsm.dll must also be the correct bitism.

  • We have:

    1. Solution Configuration and Platform in the VS Tool bar are Release/x64.

    2.ASPX Properties Build tab Platform target: x64.

    3. COBOL Link Library's Properties: COBOL tab Platform target: x64, COBOL Link tab Run-time Model Dynamic w/ Bind and "Include system programs" checked.

    4. Build Configuration Manager Active Solution configuration & platform set Release-x64 with both projects set Release-x64-Build.

    5. Build/Rebuild Solution.

    6. Publish ASPX as Release-x64.

    7. Copy everything to the Windows Server 2008 R2 server and execute:

    An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)

    Where/what else is there to set?

  • It sounds like everything is now 64-bit in your application and it should find the correct run-time because you are linking dynamically.

    Does your COBOL application make calls to any other .DLLs that may be compiled as x86? Is it perhaps using EXEC SQL statements and you are trying to use a 32-bit DSN?

    I would recommend that you try running with Process Monitor from SysInternals to see what exactly it is trying to load when you call this program.

  • The COBOL program (DLL) doesn't make any calls to anything else.  No SQL, just native/standard COBOL IO statements.

    I found the Process Monitor download on TechNet and passed the info to my co-worker.  Nobody here seems to have heard of it and we'll have to find out if the Navy will even allow it to be installed.  And then he will have to learn how to use it.

    If anyone has any other ideas or wants to see what we are doing then speak up.  I'll be listening.