View Full Version : MFC DLL CA: CWinApp subclass variables causes access violation

06-28-2005, 09:50 AM
Good morning,

If someone could help me with this mind-boggler I would really appreciate it...

I have created a MFC DLL (static linked) with a custom action (CA) in my CWinApp subclass; here's the declaration:

class Cx8App : public CWinApp
CString* getDLLCustomActionProperty(MSIHANDLE);
MSILogInfo* m_MSILogInfoInst;

_declspec(dllexport) UINT DLLCustomAction(MSIHANDLE);

// Overrides
virtual BOOL InitInstance();


My CA is DLLCustomAction() and is exported. That works fine, and code inside that exported function executes as expected. But what happens is that when I try to assign a class variable to something - i.e. m_MSILogInfoInst = 0; in DLLCustomAction(), it gives me an access violation. Using the VC++ debugger we can see that this (should be a pointer to the Cx8App object) is a <bad ptr> and so when we try to assign 0 to the<bad ptr>, it trys to write that value to some random place in memory which explains the access violation.

This begs the question, why is this (i.e. a pointer to the Cx8App object) bad? Earlier in the code I see it is being created:

// The one and only Cx8App object

Cx8App theApp;

but then I started thinking oh yeah! It's not being instantiated because the entry point is DLLCustomAction() and so that code isn't being executed. Then, when I put AfxMessageBox() in Cx8App::InitInstance() and Cx8App::Cx8App(); it actually displays so in fact it seems those functions are actually executed!

Soo... if Cx8App is actually being instantiated, why then when I try to assign a value to the class member variable it gives me an access violation? :(

Please... if anyione has any clue I would really appreciate it.

06-29-2005, 11:57 AM
Why are you using and MFC DLL for your custom action?

06-29-2005, 12:06 PM
Hi Martin,

Thanks for your reply. Basically I want to get access to the MFC functionality for easier development, ex. CString, etc.

From discussion on the MS MFC newsgroup, apparently I'm passed a 'ghost' this pointer, which is invalid and that my exported CA has to be static. I have yet to follow up on that, but hopefully that will solve my problems...

From your question, is using MFC for a CA unusual? Is there a reason that MFC can't be used as a CA? I know other people have been doing that...

06-29-2005, 12:19 PM
It is unusual in my experience. If for no other reason, the overhead that you incur by statically including MFC. If you don't care about that, then I guess it should work. In general, people try to keep CAs as lean and lightweight as possible. Any added complexity is just another chance for something to go wrong. Of all places, custom action code needs to run flawlessly because it will cause problems for your setup and can be difficult to track down problems when they do occur.

If it's just for string classes, then I would definitely not use MFC. There are plenty of string classes\wrappers that you can use from a CA. I guess it all depends on what you are trying to accomplish in your CA. Personally speaking, I wouldn't use it. For what it's worth, that my $.02.