CArchive exception - BadClass?

This problem relates to a previous thread, but since I've learned more about the problem it kind of seemed new and warranted a separate thread.

The main problem:
MFC DLL (being called from another executable) that used to be a COM DLL but I've removed COM and converted to an MFC DLL.

There is a class in there (CSequence) that is serialized with CArchive to create what we call sequence files. This project (all components) has been around a while and was in Visual Studio 6. It should read the sequence files in the known directory on startup, but is choking when it tries to read a sequence file.

Based on previous suggestions in first thread, I instrumented the old VS6 code and ran it to create text file versions of the sequence files. Then I wrote a quick console program to recreate binary sequence files the same way the regular software did. No data types changed sizes, the new sequence files were byte for byte exactly the same as the old ones. Wasted effort (other than knowledge gained).



When I run a trace statement shows up in Visual Studio (2005 now) that tells me the exception is a "BadClass" exception. That implies to me it is not finding my implementation of Serialize() to know what to do with it.

Doing some research (understanding problem more than I did in first post), I came across this MS Knowledgebase article.
http://support.microsoft.com/kb/322621

It almost looks like its a known problem as I fall in to the EXE calling an MFC extension DLL category, but it also appears that it was fixed in a service pack or something before my current VS config and should be working. It mentions to look for the date on the Afx.h file to be a 2002 date or later and mine is a 2006 date.

Any idea if this is some known MS problem or if there is anything else to try?

BTW, I tested that quick little program I wrote to see if it could also load the new sequence file as it does in the regular program. It does the exact same thing that chokes in the DLL just fine. No issues. Which sounds more and more like that knowledge base article I linked.

I am experiencing the exact problem you are describing. Any additional info?

Maybe it shown up again. What you are describing looks like the same problem addressed in the KB article. If you can reproduce this with a demo project (and as I understand you did), you could try submitting it as a bug to Microsoft Connect. If it isn't, they could probably tell you where to look at.

Quote:

---

Originally Posted by kma5wf

I am experiencing the exact problem you are describing. Any additional info?

---

I found a seemingly rare knowledgebase article:
http://support.microsoft.com/kb/322621

That made it appear to be a known problem inside of an MFC DLL. It looks like it should have been fixed by now, but maybe not. I tried doing the same thing inside of a standard EXE project and it worked just fine.


Ooops...I guess I said this in the original post. I guess that was where it ended. We just ran in to too many problems going the direction we were going on that project and finally canceled it last week.

It's a problem from 7 years ago. You can also get that message if you don't serialize in in the same sequence you serialize out.

I found a solution to this issue, might just be specific to my setup, but I'm sharing just in case it can help others. Here was my setup when before the fix:

Code:

---

  //do stuff including get fileName string from a file open dialog
  CFile file(fileName, CFile::modeRead|CFile::shareExclusive);
  CArchive ar(&file, CArchive::load);
  ar >> myObject;  //exception thrown here
  //do more stuff using myObject

---

The new setup is:

Code:

---

  //this line corrects the issue
  AFX_MANAGE_STATE(AfxGetStaticModuleState());
  //do stuff including get fileName string from a file open dialog
  CFile file(fileName, CFile::modeRead|CFile::shareExclusive);
  CArchive ar(&file, CArchive::load);
  ar >> myObject;
  //do more stuff using myObject

---

Search "AFX_MANAGE_STATE" for more details.

That is supposed to be present at the beginning of every function exported from a regular DLL dynamically linked to MFC. But this is not necessary for a MFC extension DLL. Well, at least it shouldn't.