Error loading C++.Net dll on networkdrv

[michaelschmitt]

Hi everybody, i'll try to explain my problem as short as possible: ->My C++ Dll (Native) should be able to call a C# DLL. Therefore i implemented a managed C++ dll as a bridge( to avoid COM). So, the C++(nat) calls the c++(.net) dll, which calls the c# dll. When the program is started on a local drive, everything works perfectly, but once it is copied to a network drive and run form there, loading the "bridge" - dll fails. In detail : The C++ 6.0 dll uses LoadLibrary to load the managed C++ dll and immedeately exits with Error 1114 " Dll initialization failed" - but ONLY started from a network drive. ( calling other dll's works ). I already tried to make a static link, same error... only on a network drive... I don't even have to call a function for getting the error.. I'm trying to find the mistake for a long time... but i think i'm at the end of my wisdom... Has anybody some kind of an idea, why calling my C++.Net dll only works on a local drive??? Problem with the dll- entry-point? Looking forward to some help! Thanks in advance! Michael

[J Dunlap]

It's because of security restrictions, no doubt.

"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi

[Lost User]

Hi! But which restrictions? I do have w/r rights for that drv. In addition, my .exe has already successfully called 1 other dll (which is native c++ (fortunately :-) ) before calling the c++ managed dll. Meanwhile, I used the MS Dependeny walker. The profile results seem to show that there is a problem even when the program is started from a local drive ( by the way: which u don't notice without any tool, because it runs correctly ) Profile: ( static link this time ) caloader.exe = my exe cabridge = my c++ managed.dll Started "CALOADER.EXE" (process 0x6E8) at address 0x00400000. Loaded "NTDLL.DLL" at address 0x77F40000. . . . Loaded "CABRIDGE.DLL" at address 0x10000000. Loaded "MSCOREE.DLL" at address 0x79170000. DllMain(0x78000000, DLL_PROCESS_ATTACH, 0x00000000) in "RPCRT4.DLL" called. DllMain(0x78000000, DLL_PROCESS_ATTACH, 0x00000000) . . . Entrypoint reached. All implicit modules have been loaded. DllMain(0x10000000, DLL_PROCESS_ATTACH, 0x0012FD30) in "CABRIDGE.DLL" called. Loaded "MSCORWKS.DLL" at address 0x791B0000. Loaded "MSVCR70.DLL" at address 0x7C000000. Loaded "FUSION.DLL" at address 0x79040000. . . . Loaded "MSCORLIB.DLL" at address 0x79780000. Loaded "MSCORLIB.DLL" at address 0x79960000. DllMain(0x10000000, DLL_PROCESS_ATTACH, 0x0012FD30) in "CABRIDGE.DLL" returned 1 (0x1). DllMain(0x77E40000, DLL_THREAD_ATTACH, 0x00000000) in "KERNEL32.DLL" called. DllMain(0x77E40000, DLL_THREAD_ATTACH, 0x00000000) in "KERNEL32.DLL" returned 1 (0x1). DllMain(0x77DA0000, DLL_THREAD_ATTACH, 0x00000000) in "ADVAPI32.DLL" called. DllMain(0x77DA0000, DLL_THREAD_ATTACH, 0x00000000) in "ADVAPI32.DLL" returned 14679041 (0xDFFC01). DllMain(0x78000000, DLL_THREAD_ATTACH, 0x00000000) in "RPCRT4.DLL" called. . . First chance exception 0x80000003 (Breakpoint) occurred in "MSCOREE.DLL" at address 0x79172064. First chance exception 0xC0000005 (Access Violation) occurred in "CABRIDGE.DLL" at address 0x10000005. Second chance exception 0xC0000005 (Access Violation) occurred in "CABRIDGE.DLL" at address 0x10000005. Exited "CALOADER.EXE" (process 0x6E8) with code 128 (0x80). If you did read until here, thanks :-) here's my dll: #include "stdafx.h" #include "cabridge.h" #include "windows.h" extern "C" { #include } #using "mycsharp.dll" using namespace System; using namespace mycsharp; BOOL WINAPI DllMain (HMODULE hModule, DWORD x, LPVOID <) { return TRUE; } extern "C" { __declspec (dllex

[Lost User]

sorry, please ignore extern "C" { #include } was a copy / paste err thanks for your help!

[Lost User]

Hi, consider this thread as "solved" . Meanwhile, someone has given me a hint : The problems i seem to have are described in the MSDN tecnical articles, topic "Mixed DLL Loading Problem". It further seems to be some kind of runtime-problem and can be avoided somehow.. perhaps.. I'll try it out