Crash report by NIER using LV 2011 built dll

[codeman]

I have an application that utilizes a LabVIEW built dll.  The LV dll is called by an ActiveX component dll that is built in VS 2010.  The LV dll was origninally built using LV 2010 and worked fine.  When we build the same application using LV 2011, everything works until the top level application closes.  We are then prompted with a dialog telling us that a crash was detected (log text below).  The error occurs whether we use static or dynamic linking to the dll.  If I disable NIER for the application, there are no problems; though since we're using an ActiveX component, I either have to create an ini file for the calling application or disable the NIER service for the whole system.  Neither of these options is desirable since we can't know every application that might use our ActiveX module and can't control every system we'll be deployed on.  If we cannot find a work around for this, we'll have to go back to LV 2010.

####
#Date: Thu, Oct 27, 2011 1:28:20 PM
#OSName: Windows 7 Professional
#OSVers: 6.1
#OSBuild: 7600
#AppName: HomePage
#Version: 11.0 32-bit
#AppKind: AppLib
#LabVIEW Base Address: 0x30000000

10/27/2011 1:32:41.891 PM
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash: Crash caught by NIER
minidump id: 6972c89d-ba7b-437a-9d41-d3df28550f98
ExceptionCode: 0xC0020001ý
N

[codeman · Accepted solution]

I seem to have solved my own problem, which I'll describe in case the same is happening to others.  The root of the problem, near as I can deduce, had something to do with calling the LV dll from within another dll. For some reason, when I statically linked to the dll, the DllUnload process was causing this crash report.  I found some evidence on the web to suggest that this might happen when you unload a dll from within the unload process of another dll; as would be the case with static linking.  When I attempted to dynamic link, I initially attempted to use a global instance of the dll HINSTANCE that got loaded and unloaded with the WinApp object, so the result would have been basically the same.  If I dynamically link to the dll and explicitely unload the dll prior to the calling dll being unloaded, the problem goes away.  Since my calling dll was an ActiveX implementation, I just tied the dll instance to the COM object rather than to the WinApp object.

Still not sure why this was a probelm for LV 2011 and not for LV 2010.  Perhaps the "crash" always happended and just wasn't being reported in any meaningful way since the app was closing anyway.  Not sure.  Either way, hope that helps people out there.