DLL initialization failure

DLL initialization failure

• Big1

  Sorry, I misunderstood this. I thought that it works on your machine.
  
  What about debugging the DLL itself when it is launched by REGSVR32
  
  Maybe in one of you static/global variables an exception is thrown in the initialization phase. In this case the "DllMain" in the CRT (the main DLL entry point) is reached, executed and fails. In this case your DllMain is never executed.
  
  

• Claudio Livio

  I think some more information might be helpful in solving your problem.
  
  - Are you using the Beta 2 or the Release candidate build
  - Did you build your VC8 project with the IDE or the command-line compiler
  - Is your project linked to a static CRT (/MT or /MTd) or a DLL CRT (/MD or /MDd)
  - If you are building from the command-line, did the linker generate a .manifest file
  - If the linker generated the .manifest file, are you embedding it using mt.exe
  - If the linker generated the .manifest file and you are not embedding it, are you copying/moving the DLL (but not the .manifest) and then trying to register it from the new location
  
  Thanks,
  Andrew Cox
  
  

• John Chef

  Sorry I didn't provide all this, but knowing what questions to ask is one of my problems!
  
  - Beta 2 (how do I get hold of the release candidate )
  - IDE
  - /MDd
  - (not building from command line)
  - It seems that the project _is_ embedding the manifest (the build log contains the line "Embedding manifest...", but I've no idea whether it's using mt.exe to do so.  (I'm not very familiar with manifests; I'm playing catch-up by moving directly from VC6 to VC8).
  - I'm not moving the dll from where it's generated.  A file called <COMServerName>.intermediate.manifest is alongside it in any case.
  
  TIA
  
  Phil Atkin
  

• N Camp

  Further questions about manifests:
  
  The manifest generated specifies the CRT library, but none of the other dlls that my server references.  Should I add these dependencies to the manifest   Will the load fail if I don't
  
  Phil

  
  

• Alexander Gnauck

  If you think this is a bug, please log it at http://lab.msdn.microsoft.com/productfeedback/default.aspx with all details needed to reproduce the issue.
  
  Thanks,
    Ayman Shoukry
    VC++ Team
  
  

• Markus Hoesli

  Thanks Martin.  I've been trying to debug the DLL when it's launched by RegSvr32, but only now have I managed to actually get it to hit a breakpoint.
  
  It turns out that my DLL is failing inside _CRT_INIT where it calls _initterm_e (I guess that the table contains pointers to initialization routines in each library referenced by my server).  One of the routines is __FFInit, which is an initialization routine in the FORTRAN (yes, I know) runtime library, msfrt40.dll.  It's quite a complex call and so far I haven't managed to figure out why it might be returning a non-zero (i.e. failure) value.
  
  I suspect I might have to look outside this forum for an answer, but the question remains: why does this fail now when it didn't under VC7
  
  Phil
  

• tomsji

  Further information: this problem occurs in VS 2005 RC1 as well as beta 2.  It did not occur with VC 2003.
  
  The return value from __FFInit is 0x10012750, if that means anything to anyone.  Is this worth reporting as a bug
  
  Phil
  

• Mr.ink

  Er, remote debugging   Perhaps there's a misunderstanding: I'm trying to register the DLL on my development machine in the directory in which it's built.  I haven't even got to the point of trying to install on another machine!
  
  Phil Atkin
  

• kariage

  Hi Phil,

  Did you ever resolve this issue We have encountered exactly the same problem. Thanks.

  -Matt Gates

  
  

• arvol3

  More information:
  
  Profiling the Regsvr32 run using the dependency viewer, my COM dll gets loaded and hooked OK, but I see:
  
  

  DllMain(0x62000000, DLL_PROCESS_ATTACH, 0x00000000) in "IO.OCX" returned 0 (0x0).

  - and later
  
  

  LoadLibraryExW("c:\development\ioatl\debug\io.ocx", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned NULL. Error: A dynamic link library (DLL) initialization routine failed (1114).

  However, as stated earlier, a breakpoint on DllMain is never hit.
  
  
  

• paisanperu

  If it helps, I have ths following vague recollections:

  1) I think there was something in our (large, complex) COM server that tried to subvert the normal initialization of the Fortran run-time library, by calling something to force it to initialize early. Removing this made things better.

  2) I decided to dump the Fortran once and for all. I used the (freely available) f2c converter to convert it to c++. What it produced worked pretty much right away. It's not very readable (but then neither was the Fortran); the advantage is the considerable simplification of the libraries required and avoidance of issues like this, the fact that everything is now compiled with the same compiler, and the consequent ability to debug right through the code in a unified fashion.

  Phil

  
  

• teuneboon

  We did solve the issue in an ugly sort of way by patching the MSFRT.lib so that it always returns zero( ) to VS2005 after calling its init routines. I am more than happy to do some digging if you want to know exacty what is required. In the long run, Phil's solution is the best!

  
  

• Madhavi

  Usually this is not neccessary. The manifest is only needed if you use DLL's in side by side installation.
  
  When you launch the program via remote debugging, what happens
  
  

• Vishwa Mohan Saxena

  Matt,
  
  Did YOU ever resolve this issue I'm encountering exactly the same problem .
  
  Thanks,
  
  Jeroen Bouwens
  
  
  
• DLL initialization failure