ERROR_DLL_INIT_FAILED - HELP please
in [Visual C]
|
Prev: CppCodeProvider.dll CompileAssemblyFromSource() throws a "not implemented" exception
Next: LPCTSTR vs const char* in Visual C++ 2005
From: Sergey Kashyrin on 24 Mar 2006 21:43 It might be something simple but I'm stuck with this error. VS2005 32-bit mode, C/C++ A lot of DLLs (about 2500) compiled just from the command line like this: cl /LDd progname.c The main program compiled under VS2005 and options for all C++ compile: /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc /RTC1 /MTd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt link /OUT:"Debug/app.exe" /INCREMENTAL /NOLOGO /MANIFEST /MANIFESTFILE:"Debug\app.exe.intermediate.manifest" /DEBUG /PDB:"Debug/app.pdb" /SUBSYSTEM:CONSOLE /MACHINE:X86 /ERRORREPORT:PROMPT wsock32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib So it's a console application After loading of 121 DLL the LoadLibrary starting to give error 1114. The total size of the app in memory at this moment is close to 64M and it's a lot of resources on computer (WinXP x64 2G RAM etc) The same result is on 2003 32-bit server. Any limits ? Any limitaions of virtual mapping ??? Any ideas where to look ? Regards, Sergey
From: Oleg Starodumov on 25 Mar 2006 03:45 > After loading of 121 DLL the LoadLibrary starting to give error 1114. > > The total size of the app in memory at this moment is close to 64M and it's a lot of resources on computer (WinXP x64 > 2G RAM etc) > The same result is on 2003 32-bit server. > > Any limits ? > Any limitaions of virtual mapping ??? > Any ideas where to look ? > Try to enable loader snaps, run the application under debugger and after the error has been reproduced, check the recent loader messages in debug output window: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\app.exe GlobalFlag = REG_DWORD 0x2 Also try to explore virtual memory layout of the process, e.g. as shown here: http://www.debuginfo.com/articles/easywindbg2.html#virtmemanalysis ("!address -summary" can be useful) Regards, Oleg [VC++ MVP http://www.debuginfo.com/]
From: Sergey Kashyrin on 25 Mar 2006 12:08 Oleg, Thanks for your answer. Here is situation: nothing valuable has been printed in debug window. I've tried GlobalFlag as DWORD as well as String (as it is in sample under "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Your Image File Name Here without a path" key) dcs620 was not loaded and it's nothing wrong with this specific dll. If I change the order of the load, this one can be loaded and the other will not, but the number of the loaded libraries will remain the same - 122 mine, 151 total, even in 64-bit mode !!! 'app.exe': Loaded 'G:\b32ms\sys\dcs618.dll', Binary was not built with debug information. .... 'app.exe': Loaded 'G:\b32ms\sys\dcs620.dll', Binary was not built with debug information. 'app.exe': Unloaded 'G:\b32ms\sys\dcs620.dll' It gave an error 1114 loading dcs620.dll I see that cl /LDd probably link with some VC static library so the size of each DLL is much bigger than I expect, but The dump shows enough memory to load at least more (I see at least 170M free spot before some other statically linked dll is loaded): 0000000005551000 - 0000000000005000 Type 01000000 MEM_IMAGE Protect 00000002 PAGE_READONLY State 00001000 MEM_COMMIT Usage RegionUsageImage FullPath g:\b32ms\sys\DCS618.dll 0000000005556000 : 0000000005556000 - 000000000000a000 Type 00000000 Protect 00000001 PAGE_NOACCESS State 00010000 MEM_FREE Usage RegionUsageFree 0000000005560000 : 0000000005560000 - 0000000000005000 Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageIsVAD 0000000005565000 - 000000000000b000 Type 00020000 MEM_PRIVATE Protect 00000000 State 00002000 MEM_RESERVE Usage RegionUsageIsVAD 0000000005570000 : 0000000005570000 - 000000000aa90000 Type 00000000 Protect 00000001 PAGE_NOACCESS State 00010000 MEM_FREE Usage RegionUsageFree 0000000010000000 : 0000000010000000 - 0000000000001000 Type 01000000 MEM_IMAGE Protect 00000002 PAGE_READONLY State 00001000 MEM_COMMIT Usage RegionUsageImage FullPath G:\app_ms\Debug\libcob.dll And here is summary: -------------------- Usage SUMMARY -------------------------- TotSize ( KB) Pct(Tots) Pct(Busy) Usage 36d7000 ( 56156) : 02.68% 45.37% : RegionUsageIsVAD 78714000 ( 1973328) : 94.10% 00.00% : RegionUsageFree 412e000 ( 66744) : 03.18% 53.93% : RegionUsageImage 40000 ( 256) : 00.01% 00.21% : RegionUsageStack 3000 ( 12) : 00.00% 00.01% : RegionUsageTeb 90000 ( 576) : 00.03% 00.47% : RegionUsageHeap 0 ( 0) : 00.00% 00.00% : RegionUsagePageHeap 1000 ( 4) : 00.00% 00.00% : RegionUsagePeb 1000 ( 4) : 00.00% 00.00% : RegionUsageProcessParametrs 2000 ( 8) : 00.00% 00.01% : RegionUsageEnvironmentBlock Tot: 7fff0000 (2097088 KB) Busy: 00000000078dc000 (123760 KB) -------------------- Type SUMMARY -------------------------- TotSize ( KB) Pct(Tots) Usage 78714000 ( 1973328) : 94.10% : <free> 412e000 ( 66744) : 03.18% : MEM_IMAGE 18e5000 ( 25492) : 01.22% : MEM_MAPPED 1ec9000 ( 31524) : 01.50% : MEM_PRIVATE -------------------- State SUMMARY -------------------------- TotSize ( KB) Pct(Tots) Usage 49ac000 ( 75440) : 03.60% : MEM_COMMIT 78714000 ( 1973328) : 94.10% : MEM_FREE 2f30000 ( 48320) : 02.30% : MEM_RESERVE Largest free region: Base 000000001316a000 - Size 0000000038e06000 (931864 KB) So I think that is possibly something wrong with the MS libraries which are linked statically using /LDd option of cl. Any other ideas ? Regards, Sergey "Oleg Starodumov" <com-dot-debuginfo-at-oleg> wrote in message news:%23Jnrzh%23TGHA.4276(a)TK2MSFTNGP10.phx.gbl... >> After loading of 121 DLL the LoadLibrary starting to give error 1114. >> >> The total size of the app in memory at this moment is close to 64M and >> it's a lot of resources on computer (WinXP x64 >> 2G RAM etc) >> The same result is on 2003 32-bit server. >> >> Any limits ? >> Any limitaions of virtual mapping ??? >> Any ideas where to look ? >> > > Try to enable loader snaps, run the application under debugger > and after the error has been reproduced, check the recent loader messages > in debug output window: > > HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution > Options\app.exe > GlobalFlag = REG_DWORD 0x2 > > Also try to explore virtual memory layout of the process, > e.g. as shown here: > http://www.debuginfo.com/articles/easywindbg2.html#virtmemanalysis > ("!address -summary" can be useful) > > Regards, > Oleg > [VC++ MVP http://www.debuginfo.com/] > > > >
From: Sergey Kashyrin on 25 Mar 2006 13:23 Here is a short testcase: mod.c ---------------------------- #include <windows.h> #include <stdio.h> BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { fprintf(stderr, "dllmain %s: %d\n", NM, ul_reason_for_call); return TRUE; } __declspec(dllexport) void MOD(void); void MOD(void) { fprintf(stderr, "Module %s CALL\n", NM); } --------------------------- main.c ---------------------------- #include <windows.h> #include <stdio.h> int main(int ac, char ** av) { int i; char pgm[16]; void * x; for(i = 100; i < 300; ++i ) { sprintf(pgm, "M%d.dll", i); x = LoadLibrary(pgm); if(x == NULL) { fprintf(stderr, "error load %s %d\n", pgm, GetLastError()); break; } } return 0; } -------------------------- compile DLLs: - CMD file -------------------------- for /L %%i IN (100,1,301) do ( cl /LDd -DMOD=M%%i -DNM=\"%%i\" -o M%%i.dll mod.c del *.exp *.lib ) -------------------------- compile main: cl main.c -------------------------- execute - only 126 modules will be loaded, 127-th (M226) will give error 1114 Regards, Sergey "Oleg Starodumov" <com-dot-debuginfo-at-oleg> wrote in message news:%23Jnrzh%23TGHA.4276(a)TK2MSFTNGP10.phx.gbl... >> After loading of 121 DLL the LoadLibrary starting to give error 1114. >> >> The total size of the app in memory at this moment is close to 64M and >> it's a lot of resources on computer (WinXP x64 >> 2G RAM etc) >> The same result is on 2003 32-bit server. >> >> Any limits ? >> Any limitaions of virtual mapping ??? >> Any ideas where to look ? >> > > Try to enable loader snaps, run the application under debugger > and after the error has been reproduced, check the recent loader messages > in debug output window: > > HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution > Options\app.exe > GlobalFlag = REG_DWORD 0x2 > > Also try to explore virtual memory layout of the process, > e.g. as shown here: > http://www.debuginfo.com/articles/easywindbg2.html#virtmemanalysis > ("!address -summary" can be useful) > > Regards, > Oleg > [VC++ MVP http://www.debuginfo.com/] > > > >
From: Carl Daniel [VC++ MVP] on 25 Mar 2006 15:51
"Sergey Kashyrin" <ska(a)resqnet.com> wrote in message news:OcH99kDUGHA.4384(a)tk2msftngp13.phx.gbl... > Here is a short testcase: I had no problem with your test case loading all 200 DLLs on XP SP2 w/2Gb of RAM. That said, I wonder if you're exhausting the TLS indices. IIRC, every copy of the CRT will consume a single TLS entry, and you're loading a new copy of the CRT with each DLL. I changed your sample as follows: ------------------------- pch.h ------------------------- #include <windows.h> #include <stdio.h> ------------------------- pch.c ------------------------- #include "pch..h" ------------------------- mod.c ------------------------- #include "pch.h" BOOL APIENTRY DllMain( HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) { fprintf(stderr, "dllmain %s: %d\n", NM, ul_reason_for_call); return TRUE; } __declspec(dllexport) void MOD(void); void MOD(void) { fprintf(stderr, "Module %s CALL\n", NM); } ------------------------- main.c ------------------------- #include "pch.h" int main(int ac, char ** av) { int i; char pgm[16]; void * x; for(i = 100; i < 1000; ++i ) { sprintf(pgm, "M%d.dll", i); x = LoadLibrary(pgm); if(x == NULL) { fprintf(stderr, "error load %s %d\n", pgm, GetLastError()); break; } } return 0; } ------------------------- build.cmd ------------------------- del *.pch *.dll *.exe cl -c -Yc -Fppch.pch pch.c for /L %%i IN (100,1,1001) do ( cl -Yupch.h -Fppch.pch /LD /MD /DMOD=M%%i /DNM=\"%%i\" mod.c /link /out:M%%i.dll mt /manifest M%%i.dll.manifest /outputresource:M%%i.dll;#2 del *.exp *.lib *.manifest ) cl -Yupch.h -Fppch.pch main.c ------------------------- Note the use of /MD to use the DLL version of the CRT. Note the use of the MT tool to embed the manifest for the CRT in each DLL. With those changes I had no problem running your sample with 1000 DLLs I didn't try higher than that, but memory usage was only 22Mb at that point, so I suspect I could have gone to 10,000 or higher with no problem. -cd |