noncontinuable exception during process load

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Matt Smith (msmith_at_brodart.com)
Date: 03/31/04 

Date: Wed, 31 Mar 2004 13:01:13 -0800

Hello.

I came across an issue reported in Microsoft.public.dotnet.languages.vc almost a year ago that is very similar to one that I am experiencing. The thread is included at the end of this message. I was just wondering if Microsoft ever released a patch to address this problem of all of these dll’s getting unloaded prior to attempting to load the process, causing an “unhandled noncontinuable exception during process load”. I was unable to find a hotfix and it does not appear that XP Service Pack 2 beta addresses it as I still get it after loading the Service Pack. I was able to resolve the issue by delay loading the dll’s, but isn’t that more a workaround than a permanent solution? If the cause is winmm.dll’s failure to load a driver and calling FreeLibrary to unload the dll’s as mentioned below, is that considered a Microsoft bug? Finally, is there any way to determine what driver couldn’t be loaded? There is nothing in the Event log. Any help or insight would be greatly appreciated as we
 have several customers who are experiencing this problem with our software. Thanks.

 

Matthew Smith

 

 

 

The thread:

 

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" <ferdo@home.nl> wrote in message
news:#$8gW7vJDHA.1372@TK2MSFTNGP12.phx.gbl...
> 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" <todd@ims.com> wrote in message
> news:0c5d01c326f7$25ffbb00$a001280a@phx.gbl...
>> 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 )
>>>>>-----Original Message-----
>>>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_ idll_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 )
>>>>>>>>>.
>>>