Exception during module load?

I've got a bit of a showstopper problem that sounds vaguely similar to some of the other posts on here.  I am porting a large MFC-based application from Visual Studio 2002.  I've built and run in 2003, 2005 Beta 2, and now 2005 RC1 (all using the IDE.)  I'm seeing a new problem with the RC1 build:  we're crashing during startup before our CWinApp constructor, before DllMain in any of our app DLLs, and maybe even before static initialization (breakpoints set in very early static init are not hit.)

Here's the WinDbg output:

CommandLine: C:\depot_two\dev\Slow_Debug\MyApp.exe
Symbol search path is: <redacted>
Executable search path is:
ModLoad: 68ca0000 6b3c4000   MyApp.exe
ModLoad: 7c900000 7c9b0000   ntdll.dll
ModLoad: 7c800000 7c8f4000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 71dc0000 71dca000   C:\depot_two\dev\Slow_Debug\PSAPI.DLL
ModLoad: 76c90000 76cb8000   C:\WINDOWS\system32\IMAGEHLP.dll
ModLoad: 77c10000 77c68000   C:\WINDOWS\system32\msvcrt.dll
ModLoad: 75a70000 75a91000   C:\WINDOWS\system32\MSVFW32.dll
ModLoad: 77d40000 77dd0000   C:\WINDOWS\system32\USER32.dll
ModLoad: 77f10000 77f56000   C:\WINDOWS\system32\GDI32.dll
ModLoad: 76b40000 76b6d000   C:\WINDOWS\system32\WINMM.dll
ModLoad: 77dd0000 77e6b000   C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77e70000 77f01000   C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 7c9c0000 7d1d4000   C:\WINDOWS\system32\SHELL32.dll
ModLoad: 77f60000 77fd6000   C:\WINDOWS\system32\SHLWAPI.dll
ModLoad: 5d090000 5d127000   C:\WINDOWS\system32\COMCTL32.dll
ModLoad: 73b50000 73b67000   C:\WINDOWS\system32\AVIFIL32.dll
ModLoad: 774e0000 7761d000   C:\WINDOWS\system32\ole32.dll
ModLoad: 77be0000 77bf5000   C:\WINDOWS\system32\MSACM32.dll
ModLoad: 771b0000 77256000   C:\WINDOWS\system32\WININET.dll
ModLoad: 77a80000 77b14000   C:\WINDOWS\system32\CRYPT32.dll
ModLoad: 77b20000 77b32000   C:\WINDOWS\system32\MSASN1.dll
ModLoad: 77120000 771ac000   C:\WINDOWS\system32\OLEAUT32.dll
ModLoad: 10000000 10049000   C:\depot_two\dev\Slow_Debug\ar3objects.dll
ModLoad: 00330000 00450000   C:\depot_two\dev\Slow_Debug\ar3core.dll
ModLoad: 763b0000 763f9000   C:\WINDOWS\system32\comdlg32.dll
ModLoad: 00450000 00461000   C:\depot_two\dev\Slow_Debug\POCE2KD.DLL
ModLoad: 77c00000 77c08000   C:\WINDOWS\system32\VERSION.dll
ModLoad: 00470000 004ab000   C:\depot_two\dev\Slow_Debug\CSCT.dll
ModLoad: 745e0000 748a6000   C:\WINDOWS\system32\msi.dll
ModLoad: 004b0000 00a31000   C:\depot_two\dev\Slow_Debug\Graphics.dll
ModLoad: 5ed00000 5edcc000   C:\WINDOWS\system32\OPENGL32.dll
ModLoad: 68b20000 68b40000   C:\WINDOWS\system32\GLU32.dll
ModLoad: 73760000 737a9000   C:\WINDOWS\system32\DDRAW.dll
ModLoad: 73bc0000 73bc6000   C:\WINDOWS\system32\DCIMAN32.dll
ModLoad: 00a50000 00a58000   C:\depot_two\dev\Slow_Debug\Ar3ObjectsOpenGl.dll
ModLoad: 00a60000 01370000   C:\depot_two\dev\Slow_Debug\Utility.dll
ModLoad: 77920000 77a13000   C:\WINDOWS\system32\SETUPAPI.dll
ModLoad: 71b20000 71b32000   C:\WINDOWS\system32\MPR.dll
ModLoad: 782e0000 7852b000   C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugMFC_1fc8b3b9a1e18e3b_8.0.50727.26_x-ww_c84323f7\MFC80UD.DLL
ModLoad: 10200000 10320000   C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.26_x-ww_f75cb0f2\MSVCR80D.dll
ModLoad: 10480000 1057c000   C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.26_x-ww_f75cb0f2\MSVCP80D.dll
ModLoad: 4e000000 4e0cc000   C:\depot_two\dev\Slow_Debug\SFL204ASUD.dll
ModLoad: 73000000 73026000   C:\WINDOWS\system32\WINSPOOL.DRV
ModLoad: 01380000 013b2000   C:\depot_two\dev\Slow_Debug\RWUXThemeSUD.dll
ModLoad: 4c000000 4c2da000   C:\depot_two\dev\Slow_Debug\OT804ASUD.dll
ModLoad: 013c0000 01433000   C:\depot_two\dev\Slow_Debug\vc6-re200dl.dll
ModLoad: 6d510000 6d58d000   C:\depot_two\dev\Slow_Debug\dbghelp.dll
ModLoad: 01440000 01551000   C:\depot_two\dev\Slow_Debug\Interface.dll
ModLoad: 4ec50000 4edf3000   C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.2600.2180_x-ww_522f9f82\gdiplus.dll
ModLoad: 68740000 68792000   C:\depot_two\dev\Slow_Debug\Picker.dll
ModLoad: 01580000 021c5000   C:\depot_two\dev\Slow_Debug\GeomUtil.dll
ModLoad: 021e0000 024c7000   C:\depot_two\dev\Slow_Debug\OG904ASUD.dll
ModLoad: 74320000 7435d000   C:\WINDOWS\system32\ODBC32.dll
ModLoad: 74d30000 74d50000   C:\WINDOWS\system32\oledlg.dll
(129c.ec4): Break instruction exception - code 80000003 (first chance)
eax=00251ea4 ebx=7ffd4000 ecx=00000005 edx=00000020 esi=00251f18 edi=00251ea4
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc               int     3
0:000> kp
ChildEBP RetAddr 
0012fb1c 7c93edc0 ntdll!DbgBreakPoint
0012fc94 7c921639 ntdll!LdrpInitializeProcess+0xffa
0012fd1c 7c90eac7 ntdll!_LdrpInitialize+0x183
00000000 00000000 ntdll!KiUserApcDispatcher+0x7

The last DLL mentioned in ModLoad is not consistent.  Usually it's OLEDLG.dll, but other times it's UXTHEME.dll or WS2HELP.dll.  We are linking with the multithreaded DLL version of the runtime (/MDd in this case.)  Build and test machine is running XP SP2.

We did have a somewhat similar problem in our experiments with VS2003 and 2005 beta 2 where we'd crash when loading Gdiplus.dll in some RtlInitializeCriticalSection code.  Since Gdiplus is loaded on demand, though, that happened after startup, and only when certain features were invoked.

I suppose we have some conflict among the libraries we're loading:  some DLL that won't play nice with the VC8 runtime, or something like that.  Trouble is we load a LOT of third party libraries.  Any suggestions on how to narrow down which component may be causing the problem would be greatly appreciated.


Answer this question

Exception during module load?

  • Albert_Khor

    After rebuilding some VC8 Beta 2-built third party DLLs with VC8 RC1, I still see the above exception when running in the debugger, but it can be continued from with no ill effects.  Still having downstream problems so I'm not sure if these exceptions are benign or not.

    I've done a lot of web-searching but I've been unable to discover any resources with advice on debugging exceptions during this part of the load process.  Does anyone know of a book or website that may be useful


  • Keith Swem

    We had the same problem (dlls linked to objective grid 6.1 crashing during registration). Got around that and now there is a crash during unloading. Any pointers will be appreciated.


  • Gerardicus

    Hi,

    When I did this I get the following link warnings and errors:

    Warning 1 warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored c:\Program Files\Rogue Wave\Stingray Studio 2006\Src\sfl300ws.def 2
    Warning 2 warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored c:\Program Files\Rogue Wave\Stingray Studio 2006\Src\sfl300wsd.def 2
    Warning 3 warning LNK4221: no public symbols found; archive member will be inaccessible FactoryP.obj
    Warning 4 warning LNK4221: no public symbols found; archive member will be inaccessible FactoryP.obj
    Warning 5 warning LNK4017: DESCRIPTION statement not supported for the target platform; ignored c:\Program Files\Rogue Wave\Stingray Studio 2006\Src\sfl300as.def 2
    Error 6 error LNK2001: unresolved external symbol _afxForceEXTDLL c:\Program Files\Rogue Wave\Stingray Studio 2006\Src\sfl300as.def 1
    Error 7 fatal error LNK1120: 1 unresolved externals .\objs\sfl300as/sfl300as.lib
    Error 8 fatal error U1077: '..\src\foundation\dllxport.bat' : return code '0x460' NMAKE
    Error 9 fatal error U1077: 'copy' : return code '0x1' NMAKE
    Error 10 error PRJ0019: A tool returned an error code from "Performing Makefile project actions" Stingray Foundation Library



  • Tara Nerurkar

    As I see from your output, you also have stingray dlls. well we have them too and
    had similar problems:

    FDBK37736 from MSDN Product Feedback Will give you a hint I guess:
    Search for '_pRawDllMain contains nonsense at __DllMainCRTStartup'

    The solution also posted on this bug is:

    We applied your workaround slightly different to your
    proposal, because we have the source of the stingray
    libs, so I was able to modify the stingray buildprocess,
    so that _pRawDllMain was removed from the generated .def
    file.

          Ciao Hermann


  • GlenW

    You also might try the following:

    Search for *dll.bwi in your <stingray install dir>\Utils folder

    Replace this line

    #include "afxdllx.h" // standard MFC Extension DLL routines

    with these lines

    #if _MFC_VER < 0x0800
    #include "afxdllx.h" // standard MFC Extension DLL routines
    #endif;


    in each product's *dll.bwi file.

    This will propagate the changes above when you run each of your Stingray product's build wizards.

    To affect your current *.dll.cpp files:

    Also, search for *dll.cpp in your <stingray install dir>\Src folder

    repeat the steps above.

    Rebuild your Stingray libraries.

    Rebuild and relink your application with your rebuilt Stingray libraries.

    HTH,

    Himantura


  • Chaitanya Tyagi

    Thanks a lot, Hermann, that's very helpful!

    I'm curious, what exactly did you do to the stingray buildprocess to remove the _pRawDllMain export   Remove #include <afxdllx.h> from gxdll.cpp

  • Exception during module load?