Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

mixed mode DLL causing non-continuable exception during process load

262 views
Skip to first unread message

Todd C. Gleason

unread,
May 8, 2003, 1:01:10 PM5/8/03
to
I have a large application statically linking to a DLL which was written in
VC++ 6.0, and now ported to 7.1. I went through all the steps to make it a
mixed-mode DLL, and if I then compile it (with all the
__crt_dll_initialize() and so on), and do not enable managed extensions (not
yet actually even defining a single managed object!), the program still
works. However, as soon as I enable managed extensions (compiling with
/clr), the application unloads before it even gets going. It never hits a
single line of my code, not even the __crt_dll_initialize() which is now
manually called in the entry point. Note that I have no real control over
the calling application at this time; it is written in another language and
can only deal with a pure C-style interface to my DLL. It also cannot use
delay-loading, and dynamic loading is not currently an option.

I can't find any kind of documentation on what causes a "non-continuable
exception" during process load, or any hint of how to debug this problem. I
tried loading the application in cordbg (the command-line debugger), and I
turned on a ton of verbose mode options, but when I run it, all it says is
"Process exited."

I do know that mscoree.dll is the unmanaged stub DLL that loads the CLR. I
am curious why comctl32.dll loads next, as well as what syncor11.dll is. I
had thought mscorwks.dll was supposed to be the next thing loaded...? I've
done some reading on DLL loading happening from the PE header and on entry
points, but I still don't consider myself an expert in that area.

Needless to say, this could be a complete showstopper to our deployment of
.NET. If there is any information anyone has, or any suggestions to try,
please pass them on. I have included a cut-down listing of DLLs loading and
unloading in case it helps anyone (it isn't helping me very much).


[app loading lines deleted]
'accwin.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded.
[app loading lines deleted]
'accwin.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\comctl32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\comdlg32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\shell32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\winspool.drv', No symbols loaded.
[app loading lines deleted]
'accwin.exe': Loaded 'C:\WINDOWS\system32\Wbtrv32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\mpr.dll', No symbols loaded.
[app loading lines deleted]
'accwin.exe': Loaded 'C:\WINDOWS\system32\mfc42.dll', Symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\msvcp60.dll', Symbols loaded.
[app loading lines deleted]
'accwin.exe': Loaded 'C:\WINDOWS\system32\winmm.dll', No symbols loaded.
[app loading lines deleted]
'accwin.exe': Loaded 'C:\WINDOWS\system32\mfc71d.dll', Symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\msvcr71d.dll', Symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\msvcp71d.dll', Symbols loaded.
[app loading lines deleted]
[loads the mixed-mode DLL]
'accwin.exe': Loaded 'C:\WINDOWS\system32\mscoree.dll', No symbols loaded.
'accwin.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.
0.10.0_x-ww_f7fb5805\comctl32.dll', No symbols loaded.
'accwin.exe': Loaded 'C:\WINDOWS\system32\Syncor11.dll', Symbols loaded.
[unloads app DLLs]
'accwin.exe': Unloaded 'C:\WINDOWS\system32\msvcp71d.dll'
'accwin.exe': Unloaded 'C:\WINDOWS\system32\mfc71d.dll'
'accwin.exe': Unloaded 'C:\WINDOWS\system32\msvcr71d.dll'
[unloads app DLLs]
'accwin.exe': Unloaded 'C:\WINDOWS\system32\msvcp60.dll'
'accwin.exe': Unloaded 'C:\WINDOWS\system32\mfc42.dll'
[unloads app DLLs]
'accwin.exe': Unloaded 'C:\WINDOWS\system32\Wbtrv32.dll'
[unloads app DLLs]
'accwin.exe': Unloaded 'C:\WINDOWS\system32\winspool.drv'
'accwin.exe': Unloaded 'C:\WINDOWS\system32\oleaut32.dll'
'accwin.exe': Unloaded 'C:\WINDOWS\system32\comdlg32.dll'
'accwin.exe': Unloaded 'C:\WINDOWS\system32\shell32.dll'
'accwin.exe': Unloaded 'C:\WINDOWS\system32\mpr.dll'
'accwin.exe': Unloaded 'C:\WINDOWS\system32\ole32.dll'
'accwin.exe': Unloaded 'C:\WINDOWS\system32\mscoree.dll'
[unloads app mixed mode DLL]
Debugger:: An unhandled non-continuable exception was thrown during process
load
The program '[2348] accwin.exe: Native' has exited with code 128 (0x80).

--Todd C. Gleason ( www.cool-man.org )


Todd C. Gleason

unread,
May 30, 2003, 6:02:23 PM5/30/03
to
With the help of the MSDN support folks, I discovered the
bizarre cause of this exception. In the event that it
helps anyone else, I thought I'd share it. Here is part
of the support email to me:

-------
It looks like this bad behavior is caused by the
winmm.dll which is calling FreeLibrary in its
initialization code. The call stack is very similar to a
bug reported to us about 1 month back. And a hotfix for
that bug will be available soon.

CAUSE
=====
The executable is linked to WINMM, a dependent DLL is
linked to a .NET DLL, loading the .NET DLL results in
running init routines, winmm attempts to load a driver
and fails and calls FreeLibrary, the call to FreeLibrary
results in many DLL's getting unloaded becuase the
LoadCount is not > 0 yet, since this is set later.
-------

The workaround was to force all of our DLLs that loaded
winmm.dll to delay-load using the /DELAYLOAD linker
switch.

This workaround also (for whatever reason) fixed
the "mixed-mode debugger hangs" problem I posted
separately in this group.

Hope this information helps somebody else!

--Todd C. Gleason ( www.cool-man.org )

>..NET. If there is any information anyone has, or any

>.
>

ferdinand oeinck

unread,
May 30, 2003, 6:57:29 PM5/30/03
to
Ah, the "Loader Lock" issue again! In my first communication with Arjun
Bijanski about strange errors during DLL initialisation, which turned out to
be the Loader Lock bug, I assumed that the load order of the DLL's was
somehow important, because after changing my crashes disappeared. He denied
that, but now even the MSDN support folks advice to change the loadorder....

Ferdinand.

"Todd C. Gleason" <to...@ims.com> wrote in message
news:0c5d01c326f7$25ffbb00$a001...@phx.gbl...

> >__crt_ idll_initialize() and so on), and do not enable

Ronald Laeremans [MSFT]

unread,
Jun 3, 2003, 9:11:48 PM6/3/03
to
Yes, the load order is important. It however is very hard to guarantee that
when you have a load order that happens to work on your system it will
continue working after making any trivial change on the system (could be as
minor as installing some hotfix on the system involving one of the DLL
involved in the load cycle). This is why we don't really suggest tweaking
the load order to get around the issue. Delay loading of course is a
fundamental solution.

Ronald

"ferdinand oeinck" <fe...@home.nl> wrote in message
news:#$8gW7vJD...@TK2MSFTNGP12.phx.gbl...

shailend...@gmail.com

unread,
Sep 27, 2012, 8:32:29 AM9/27/12
to
Hi..Is HotFix for the issue is available.
Could you please provide the link of same.?

Thanks
Shailendra
0 new messages