Forum

Hey guys,

We are having some bad crashes with our applications that we use a skin on. We check our crash dumps and we get a call stack like this:

  > ntdll.dll!0000000077f2a00c()

> [Frames below may be incorrect and/or missing, no symbols loaded for

> ntdll.dll]

> fffffffffffffffe()

> 0000000000167540()

> 0000000000000202()

> 00000000001673c0() 

If you google that you’ll find that this is an exception of type: STATUS_SXS_EARLY_DEACTIVATION (0xC015000F) Further research reveals this web page:

http://blogs.msdn.com/junfeng/archive/2006/03/19/sxs-activation-contex">http://blogs.msdn.com/junfeng/archive/2006/03/19/sxs-activation-context-activate-and-deactivate.aspx

This page says that this exception can be thrown if someone calls ActivateActCtx but forgets to call DeactivateCtx. Alot of sites report having this issue when  ui "skin" managers are used. See sites below

http://forum.codejock.com/forum_posts.asp?TID=7530

http://skincrafter.com/forum/viewtopic.php?p=5739

https://forum.codejock.com/printer_friendly_posts.asp?TID=6467

For fixes we found this site here:

http://www.mombu.com/microsoft/mmc/t-activation-context-error-in-mmc-s s-when-using-windows-vista-610122.htmlnap-in

We have some questions about this. Is this fix safe? Have you had crash reports like this before? If this is a bug that has been fixed what version of the library is it in?

Thanks,

CJ

which says that the fix is to add this:

CWinApp::InitInstance();

afxAmbientActCtx = FALSE; //<==== add this line

Note that we’ve just started seeing similar crashes in our app.  The only thing that changed was upgrading from Prof-UIS v2.82 to v2.87.  Nothing else changed in our app and we saw crashes on app exit.

We added the line to set afxAmbientActCtx to FALSE and this seemed to work at first, but we’re still seeing crashes on exit with a release build of our app.

When we add that line in InitInstance, the nature of the crash is a little different.  It appears to then crash on string destruction.  The string is a member variable of the CApp-derived object instance.

thanks guys, we are looking into it.

i can’t post the linke with out it messing up.  sorry.

It’s only 80% safe. The 80% is our rate of the proposed solution’s safety. The proposed solution (afxAmbientActCtx = FALSE;) just turns off the SxS context switching and MFC 8.0 or 9.0 is working like older versions of MFC (i.e. the AFX_MAINTAIN_STATE2 internal MFC class does not invoke the SxS context switching APIs). When it’s 100% safe? It’s 100% safe if the running instance of your application consists of your source code, MFC and Prof-UIS source code only, when it does not have any modules which explicitly invoke SxS context switching APIs (i.e. AfxActivateActCtx(), AfxDeactivateActCtx(), ActivateActCtx(), DeactivateActCtx()). In the most of cases, nobody needs to invoke these APIs because MFC does this work. It looks like the only people really may need them are Microsoft developers and these APIs may be needed by Microsoft’s libraries only. The SxS context switching APIs protect your application from future versions of software components (DLLs, COM objects) which may require future versions of other software components. If the SxS context is not switched by MFC, then you will need to perform more careful testing of your software on each release. It’s better not to turn off it. But if it’s turned off, then it’s safer to create COM objects specifying exact versions of prog-id strings and it’s safer to keep all the DLLs required by main EXE module of your software in the same folder with this EXE module. The SxS subsystem makes software development more complicated. We guess, Microsoft does not fully trust to SxS context switching mechanism because MFC/VC++ runtime DLLs now have version numbers in DLL names. So, it’s better and safer to leave it working intact inside MFC, let it do it work like it was designed.
What can be reason for the error occurred in your application? The reason is not hidden in UI development. You just listed URLs to forums where enough large people are gathered for discussing any problems. The SxS context switching APIs are stack like. When new context is activated by some subsystem A (DLL, library, COM object, any kind of software component), then it must be deactivated sometime later. Some other subsystem B can activate/deactivate its own SxS context between activation/deactivation of SxS context of subsystem A. Please imaging A is your software and it invoked some APIs of B. But B didn’t deactivated its SxS context. So, when A tries to deactivate context, then SEH exception is thrown from the DeactivateActCtx() function because the top context inside inner SxS stack is context of B and A tries to deactivate what cannot be deactivated before deactivation of B. The context activation/deactivation is performed inside constructor/destructor of the AFX_MAINTAIN_STATE2 MFC’s internal class. If it didn’t deactivated SxS context, then it’s constructor is not invoked during the normal C++ unwinding mechanism for in-stack objects (local function/method objects). The constructor is not invoked if some critical error is occurred: the SEH exception for instance (access violation, stack overflow, divide by zero, etc.). This is the main potential source of the problem. Of course, it’s possible some software used in your program invokes SxS APIs explicitly and due to some bug does not invoke context deactivation. But this is less possible reason for the discussed run-time error.
How to find the real source of the error? You should exclude parts of your software from run-time and find situations when error does not occur. Do not invoke particular APIs. Comment parts of your application. Set up your Visual Studio to break into debugger when any SEH exceptions occur even if they are handled. Finally find the maximally functional version of your application which does not have this problem and start the next step of searching: comment/exclude smaller parts of your application and so on.
We never come across this problem yet. Nobody reported it yet in our forums. So, that would be interesting to connect to your desktop and try to help you.

Sorry some how the link really messed up the format of the post.  Here is the fix link:

http://www.mombu.com/microsoft/mmc/t-activation-context-error-in-mmc-s s-when-using-windows-vista-610122.htmlnap-in

which says that the fix is to add this:

CWinApp::InitInstance();

afxAmbientActCtx = FALSE; //<==== add this line