locked
Unmanaged exe with IJW (/clr) dll wrapper crashes under Win7 RRS feed

  • Question

  • I have an unmanaged C++ application in VS2008 that uses Crystal Reports.  The CR modules are C# assemblies so we have created a wrapper using the IJW ("it just works") method of interop, wanting to avoid using COM.  We've run into a couple of issues:

    - under WinXP, the wrapper works when built either as a static lib or as a dll; however as a static lib, it disables edit-and-continue (incremental linking) so we'd prefer to use it as a dll.  I've seen many examples of using a dll-based wrapper, so it should work.

    - under Win7 x64, the wrapper works when built and linked in as a static lib.  However, when we build it as a dll, it causes unexpected behavior: any File:Open dialog crashes with an "Unhandled exception at 0x77b38eb9 in if.exe: 0xC0000005: Access violation writing location 0x00000014."  When built as a static lib, the File:Open dialog behaves properly.  We also have another dll library that fails when the wrapper is built as a dll but works when the wrapper is built as a static lib.  It's like the wrapper (when a dll) is corrupting other dlls loaded.

     

    When the wrapper is built as a dll, we use "_AFXEXT" as a compiler directive, and generate an import library.  Other project settings are:

    - Use MFC in a Shared DLL

    - Not Using ATL

    - Use Multi-Byte Character Set

    - Common Language Runtime Support (/clr)

    and there is an interface defined with AFX_EXT_CLASS

     

    Any idea how the wrapper as a dll can be causing failures in *unrelated* sections of the unmanaged exe?  Is there some compiler/linker flag that I must enable in the main application that is being implicitly set when binding to the wrapper when it's a static lib?  (ie. if binding to a /clr static lib, does the linker automatically make adjustments that I'm not aware of?)

     

    Any insight on how to tackle this problem would be appreciated.

    Thanks.

    Friday, April 29, 2011 4:10 PM

Answers

  • Problem solved.  It had nothing to do with the C++/CLI project, but was an unrelated DLL which was triggering a buried LoadLibrary() call within its DllMain.  Somehow it worked fine under a Release build and in Debug under WinXP, but caused Win7 problems under Debug.  It was merely coincidental that linking in the C++/CLI DLL pushed the app loader over the edge.
    • Marked as answer by T-RHex Tuesday, May 17, 2011 4:16 PM
    Tuesday, May 17, 2011 4:16 PM

All replies

  • Can you check MSDN forum  http://social.msdn.microsoft.com/Forums/en-IN/vsdebug/thread/f5f38335-7f8a-451e-ae2a-4f8f2f71c921 related with this.
    Thanks and Regards Selvam http://www15.brinkster.om/selvamselvam/
    Friday, April 29, 2011 4:50 PM
  • Thanks for the reply.  That doesn't look related, though; I'm not setting any breakpoints, and I don't have "Enable RPC debugging" checked in Options > Debugging > Native.

     

    Friday, April 29, 2011 6:49 PM
  • As per MSDN,

    When you have multiple layers, one symbol such as AFX_EXT_CLASS is not sufficient, because an extension DLL might be exporting new classes as well as importing other classes from another extension DLL. To solve this problem, use a special preprocessor symbol that indicates that you are building the DLL itself versus using the DLL

    So, I assume you don't use multiple layer. If your DLL is working fine with windows XP and Windows 7 with static layer, you can check with /DYNAMICBASE linker option.

    Every DLL has preferred base address for load the process memory. If you use dumpbin with headers option, it will tell the base address.

    dumpbin /headers advapi32.dll

    OPTIONAL HEADER VALUES
    .......
            77DD0000 image base (77DD0000 to 77E6AFFF)
    .....................

    But, /DYNAMICBASE linker option specifies whether to generate an executable image that can be randomly rebased at load time by using the address space layout randomization (ASLR) feature of Windows Vista. So, It may not support by Windows XP. Windows XP may try to load some xxxxx address space. So, It may fail to load the DLL.

    You can check http://msdn.microsoft.com/en-us/library/bb384887.aspx for more details.

    By default Randomized Base Address property /DYNAMICBASE is on for windows Vista. You can off this switch and build the DLL.


    Thanks and Regards Selvam http://www15.brinkster.om/selvamselvam/
    • Marked as answer by lucy-liu Friday, May 6, 2011 8:47 AM
    • Unmarked as answer by T-RHex Friday, May 6, 2011 12:31 PM
    • Proposed as answer by Selvam Tuesday, May 17, 2011 4:45 PM
    Saturday, April 30, 2011 4:26 PM
  • Hi Selvam,

    Sorry for the delay in replying -- the week went crazy due to a suddenly needed release. 

    I haven't had time to analyze the dll loading but I can tell you I've tried /DYNAMICBASE and /DYNAMICBASE:NO, I've also tried /FIXED:NO and /FIXED, but the results were no different. 

    Luckily I discovered something: if we build the project under WinXP in release configuration, it runs fine in Win7 and uses the "Vista style" for the File:Open dialog.  Building under debug configuration in Win7 and running it in the debugger, having "Vista style" enabled causes the showing of the dialog to crash the application.  Once our release is out, I will be back to this, and can try the other permutations, such as building the release configuration under Win7, etc.

    Friday, May 6, 2011 12:30 PM
  • Hello again.  I'm finally back on this project.

    Another find: if I build the release configuration of the project under Win7, it runs fine, with the "vista style" file:open dialog.  If I build the debug configuration, it crashes.  I'm currently going through and comparing the release and debug project settings (again) to see if anything obvious is different.

    Here are the image bases for all the DLLs.  "CommonReporting.dll" and "Reporting.dll" are C# assemblies.  "ReportingWrapper.dll" is the /clr C++ project.  CommonReporting is a dependency of Reporting which is a dependency of ReportingWrapper.

    Dump of file CommonReporting.dll
              400000 image base (00400000 to 00411FFF)
    Dump of file d1.dll
            30000000 image base (30000000 to 30023FFF)
    Dump of file d2.dll
            20000000 image base (20000000 to 2002AFFF)
    Dump of file g1.dll
            10000000 image base (10000000 to 1000CFFF)
    Dump of file g2.dll
            10000000 image base (10000000 to 1000DFFF)
    Dump of file Reporting.dll
              400000 image base (00400000 to 008CBFFF)
    Dump of file ReportingWrapper.dll
            10000000 image base (10000000 to 10010FFF)
    Dump of file w.dll
            10000000 image base (10000000 to 10008FFF)
    Dump of file z.dll
            10000000 image base (10000000 to 10006FFF)

    [quote](ASLR) feature of Windows Vista. So, It may not support by Windows XP. Windows XP may try to load some xxxxx address space. So, It may fail to load the DLL.[/quote]

    Not sure I follow you there ... this is working under WinXP but not under Win7.  That comment made it sound like WinXP is the one failing.

    Tuesday, May 10, 2011 12:28 AM
  • Problem solved.  It had nothing to do with the C++/CLI project, but was an unrelated DLL which was triggering a buried LoadLibrary() call within its DllMain.  Somehow it worked fine under a Release build and in Debug under WinXP, but caused Win7 problems under Debug.  It was merely coincidental that linking in the C++/CLI DLL pushed the app loader over the edge.
    • Marked as answer by T-RHex Tuesday, May 17, 2011 4:16 PM
    Tuesday, May 17, 2011 4:16 PM