Very strange DllImport / LoadLibrary Issue RRS feed

  • Question

  • Hi all,

    Please bear with me, as the description of the problem is fairly involved :)

    I've got a strange issue when I am calling a function in an MFC C DLL declared with a DllImport from a .Net user control.

    When I display the user control in a standalone application it works fine. I have migrated the component to our main product, which launches a new process, dynamically loads the assembly containing my user control (loading using the Assembly.Load passing in the bytes), hosts the component on a windows forms and displays it.

    When run in this context, the first time one of the DLLs methods is called I get a message box saying "<PATH>\<COMPONENT_FULL_TYPE_NAME> was not found" where <PATH> is the root path of the application that initially lauched the process (in our cases this is two processes down Launcher -> Application -> Hosting Process). <COMPONENT_FULL_TYPE_NAME> is the name of the .Net user control that is calling the method in the DLL).  The same behavior occurs if I try to load the DLL using LoadLibrary. It doesn't occur with other DLLs I call or load in a similar way.

    This had me scratching my head for a while until I started ProcessExplorer (ex-sysinternal thing) and it showed that when the LoadLibrary is called then a read is attempted for this file it is complaining is not found (the stack trace for the attempted file read is given at the end). I also know that the DLL starts loading as it spits out debug indicating this (so its not an issue of not being able to find the DLL.) Experimenting, I created a 0 byte file with the name it was complaining about not being able to find e.g. C:\Program Files (x86)\MyCompany\AppLauncher\MyCompany.MyNameSpace.MyControl...and lo and behold LoadLibrary, or the DllImport started working.

    The developer of the third party DLL assures me, that he doesn't do any explicit searching for files, so my guess its a LoadLibrary or MFC thing going on here. The thing is a hack to create a 0 byte file is not really an acceptable solution. Particularly as many of our customers have employee machines locked down quite a bit and writing files to Program Files during runtime is not something I can rely on being able to do. I do not have access to the third party source code so I can't debug into the DLL.

    Does anyone know what on earth is going on here??


    Here is the promised stack trace given by Process Explorer leading up to the attempted file read:

    0              fltmgr.sys            FltReleasePushLock + 0x3e7       0xfffff880012c3027          C:\Windows\system32\drivers\fltmgr.sys

    1              fltmgr.sys            FltGetStreamHandleContext + 0x3da     0xfffff880012c58ca                C:\Windows\system32\drivers\fltmgr.sys

    2              fltmgr.sys            FltReadFile + 0x103d3    0xfffff880012e32a3         C:\Windows\system32\drivers\fltmgr.sys

    3              ntoskrnl.exe      SeUnlockSubjectContext + 0x647             0xfffff80002f82807                C:\Windows\system32\ntoskrnl.exe

    4              ntoskrnl.exe      SeQueryInformationToken + 0x20b4      0xfffff80002f78e84                C:\Windows\system32\ntoskrnl.exe

    5              ntoskrnl.exe      ObOpenObjectByName + 0x1cd               0xfffff80002f7de4d                C:\Windows\system32\ntoskrnl.exe

    6              ntoskrnl.exe      SeUnlockSubjectContext + 0x2757           0xfffff80002f84917                C:\Windows\system32\ntoskrnl.exe

    7              ntoskrnl.exe      NtCreateFile + 0x78        0xfffff80002f8e520          C:\Windows\system32\ntoskrnl.exe

    8              ntoskrnl.exe      KeSynchronizeExecution + 0x3a43           0xfffff80002c7e993                C:\Windows\system32\ntoskrnl.exe

    9              ntdll.dll ZwCreateFile + 0xa          0x776c02aa         C:\Windows\SYSTEM32\ntdll.dll

    10           wow64.dll           Wow64EmulateAtlThunk + 0xe683           0x73a1bfe3         C:\Windows\SYSTEM32\wow64.dll

    11           wow64.dll           Wow64SystemServiceEx + 0xd7                0x73a0cf87          C:\Windows\SYSTEM32\wow64.dll

    12           wow64cpu.dll    TurboDispatchJumpAddressEnd + 0x24 0x7399276d        C:\Windows\SYSTEM32\wow64cpu.dll

    13           wow64.dll           Wow64SystemServiceEx + 0x1ce              0x73a0d07e        C:\Windows\SYSTEM32\wow64.dll

    14           wow64.dll           Wow64LdrpInitialize + 0x429       0x73a0c549         C:\Windows\SYSTEM32\wow64.dll

    15           ntdll.dll RtlResetRtlTranslations + 0x1b08              0x776b82c8         C:\Windows\SYSTEM32\ntdll.dll

    16           ntdll.dll RtlResetRtlTranslations + 0xc63 0x776b7423        C:\Windows\SYSTEM32\ntdll.dll

    17           ntdll.dll LdrInitializeThunk + 0xe                0x776a2e2e        C:\Windows\SYSTEM32\ntdll.dll

    18           ntdll.dll NtCreateFile + 0x12        0x77870056         C:\Windows\SysWOW64\ntdll.dll

    19           KERNELBASE.dll                CreateFileW + 0x35e      0x76c0b616         C:\Windows\syswow64\KERNELBASE.dll

    20           KERNEL32.dll      CreateFileW + 0x4a         0x76df2345         C:\Windows\syswow64\KERNEL32.dll

    21           KERNEL32.dll     CreateFileA + 0x36          0x76dfcaa4         C:\Windows\syswow64\KERNEL32.dll

    22           thirdparty.dll     thirdparty.dll + 0x2c786d              0x127d786d             <BIN\DEBUG PATH OF MAIN APPLICATION>

    Friday, October 22, 2010 2:20 PM


  • Hi,

    Thanks for your post. I am trying to understand your scenario. My current understanding is this. The whole working paradigm is like this: Your Launcher program starts a new process. This process tries to load an .NET assembly which holds your control. This control invokes a method from a MFC DLL. And the problem you got is: the Launcher program cannot find the .NET assembly in Launcher's directory. Since you found that a dummy 0-sized dll can be a work around, I am doubting that there's unnecessary file looking in the Launcher program which looks for the .NET assembly. So please try debug through the Launcher program and find where the failed assembly loading happens.

    BTW, it seems that the MFC DLL is not relevant to your problem.

    Please mark the right answer at the right time.
    • Edited by SamAgain Tuesday, October 26, 2010 6:50 AM refine
    • Marked as answer by SamAgain Sunday, October 31, 2010 2:42 PM
    Tuesday, October 26, 2010 6:47 AM