locked
Program crashes while DLLs loading RRS feed

  • Question

  • I have a program that works fine here, but at a client site it blows up while the DLLs are loading.  After researching I found that at the client shimeng.dll and acgenral.dll are being loaded during execution, while at my office they are not.  I was finally able to get the DLLs loaded and therefore crash by adding a key/value to AppCompatFlags\Layers in the registry.  After some trial and error I was able to find the problem DLL.  It is a DLL that uses RogueWave's StingRay controls.  If I removed references to the StingRay controls - no crashing, put them back in it crashes.  I saw an earlier post regarding StingRay and "afxdllx.h", but that did not correct my problem.  Here is the stack dump at the crash:
    ntdll.dll!_RtlRaiseStatus@4()  + 0x26 bytes 
      ntdll.dll!__LdrpInitialize@12()  + 0x241d8 bytes 
      ntdll.dll!_KiUserApcDispatcher@20()  + 0x7 bytes 
      kernel32.dll!_BaseThreadStartThunk@8()  + 0xb bytes 

    Any suggestions? I can't have the client remove the registry setting because it could impact other apps ("C:\WINDOWS\explorer.exe"-->"DisableNXShowUI").

    I am using:  VS 2005 (8.0.50727.762); Windows XP Pro SP 3; StingRay Studio 10.0

     


    John Miller
    Monday, February 23, 2009 6:59 PM

Answers

  • I don't understand what you are saying; mainly because you say "the DLL" but I don't know which that is. It does sound as if there is more you are doing in your DllMain but if not then it is likely something that you must get support from Stingray to solve. If it is a problem with your software then it is likely something we don't have a clue about from the description so far.

    I suggest looking at the DllMain documentation to ensure you are not doing something that a DllMain is not supposed to do. There are many restrictions there.
    Sam Hobbs; see my SimpleSamples.Info
    • Marked as answer by Wesley Yao Monday, March 2, 2009 1:54 AM
    Wednesday, February 25, 2009 9:25 PM

All replies

  • Not sure why you posted here.  This seems clearly a Stingray problem.  Contact them for support.
    Hans Passant.
    Monday, February 23, 2009 7:21 PM
  • Does the program use any DLL that you wrote? If so then there is possibility that your DLL has a Dllmain that is causing the problem.

    Also that stack dump does not show any code in your program or even in Stingray code so it does not help.

    Hans is likely correct, though; it is likely a Stingray problem.


    Sam Hobbs; see my SimpleSamples.Info
    Monday, February 23, 2009 8:32 PM
  • I posted it here because I am not absolutely sure where the problem is.  The app runs fine until the Microsoft DLLs, shimeng and acgenral.dll, are involved.  I'm sure there is a conflict between Stingray and these DLLs.  Since the app only crashes when those Microsoft DLLs are introduced, some people could say it is a Microsoft issue.  I am not familiar with those DLLs, so I really don't know who is causing it.  I am just trying to find a solution.
    John Miller
    Monday, February 23, 2009 8:50 PM
  • Yes, the app uses DLLs I wrote.  I even created a basic MFC app and started to add a DLL at a time until it crashed.  That DLL used the StingRay DLLs.  As a test I removed all references to the StingRay DLLs from my DLL, and it ran fine.  Again, the crash only occurs when shimeng.dll and acgenral.dll are also loaded.  If I remove the registry entry (and reboot), everything runs fine.

    The stack wasn't helpful, the Stingray DLL's DllMain is not even called at this point.  I don't know how to debug this.  I placed a breakpoint in crtdll.c and can see other DLL's DllMain being called fine.

    John Miller
    Monday, February 23, 2009 8:55 PM
  • Don't try to debug the Stingray DLL; if it is their problem then leave it for them to debug.

    What do you do in the DllMain of your DLL(s)?



    Sam Hobbs; see my SimpleSamples.Info
    Monday, February 23, 2009 10:45 PM
  • Do you know what shimeng.dll and acgenral.dll are? I don't, but you should search for whatever information you can find about them. There seem to be a few problems that include acgenral.dll, but it might be only coincidental that acgenral.dll was present. The shimeng.dll seems to be related to a fix but I am not sure. Perhaps it is being used in a manner that it should not be.
    Sam Hobbs; see my SimpleSamples.Info
    Tuesday, February 24, 2009 12:41 AM
  • The only thing done in my dll is the normal AfxInitExtensionModule() and CDynLinkLibrary() calls.  But remember DllMain never gets called when that shimeng.dll is involved - without it DllMain is called as normal.


    John Miller
    Tuesday, February 24, 2009 12:31 PM
  • From what I was able to find out, those DLLs get installed by Windows XP SP 2 - maybe even SP 1.  shimeng stands for Shim Engine and it has something to do with application compatibility.  I don't know if the OS is verifying the app is compatible and if not stops the app from running.  The stingray DLLs are MFC based controls and they implement a theme mechanism.  That is my best guess where the conflict occurs.  I am also working with the StingRay vendor to resolve this issue.  Right now I would be happy if there was some way to temporarily disable the Shim Engine check specifically on my app without disabling it in the OS through that registry setting.  It would buy some time until a full solution is found.

    John Miller
    Tuesday, February 24, 2009 12:37 PM
  • I found that if the DLL is not implicitly loaded, the DLL seems to load fine.  If I use LoadLibrary() to load the DLL, the DLL's DllMain is properly called and the app does not crash.  Of course it renders the DLL effectively because I can't use the classes defined in the DLL using LoadLibrary - at least easily.

    Is there something different the OS is doing with an implicitly loaded DLL and one loaded with LoadLibrary()?
    John Miller
    Wednesday, February 25, 2009 1:18 PM
  • I don't understand what you are saying; mainly because you say "the DLL" but I don't know which that is. It does sound as if there is more you are doing in your DllMain but if not then it is likely something that you must get support from Stingray to solve. If it is a problem with your software then it is likely something we don't have a clue about from the description so far.

    I suggest looking at the DllMain documentation to ensure you are not doing something that a DllMain is not supposed to do. There are many restrictions there.
    Sam Hobbs; see my SimpleSamples.Info
    • Marked as answer by Wesley Yao Monday, March 2, 2009 1:54 AM
    Wednesday, February 25, 2009 9:25 PM
  • Ok.  I will try to make more sense of it.  I was able to create a simple MFC application.  Whenever I try to include a control from a stingray DLL in my app the app crashes.  The DllMain of the stingray DLL never gets called, so something is causing it to fail before it gets there.  If, in my app, I use LoadLibrary() to load the stingray DLL, there is no crash and the stringray DllMain gets called as expected.  There is no code, at least none that I am aware of, that I can use breakpoints because the stingray DLL never really gets initialized.  So it seems whatever process is responsible for loading an exe and its associated DLLs is having a conflict that is related to that registry setting.
    John Miller
    Thursday, February 26, 2009 12:12 AM
  • It looks like the issue has been resolved.  Apparently the stingray DLL has a static class/structure that loaded uxtheme.dll.  This happens before DllMain gets called.  Apparently doing this conflicts with something shimeng.dll does.  For future reference, is there any way I could have debugged through the initialization of static data?  I do have the stingray source code.  I am looking for a general way to debug and not have to rely on finding the static data in the stingray source code.  Thanks everyone for your help.
    John Miller
    Friday, February 27, 2009 7:44 PM