A few days ago from the Internet under an image analysis of the MFC applet, is VC6
It is no problem to compile the build locally with VC6. Execution pops up with an unhandled error and the program crashes exiting.
Think of the original encountered in the Open File dialog box, the project time was tense not to delve into.
This time we should take a good look at this problem.
Detailed approach is to carefully track, track, follow.
。。
Application code, follow up
MFC code, follow up
Alt+8 recall disassembly, follow-up.
。
。
Repeat the trace multiple times to reduce the target. The problem is determined: in the CFileDialog destructor, the destructor of the CString is called,
It is precisely the destruction of the csring error.
The definition of CFileDialog, such as the following, is the destructor of this m_strfilter error.
Class Cfiledialog:public Ccommondialog
{
Declare_dynamic (CFileDialog)
Public
Attributes
OpenFileName m_ofn; Open File parameter block
Constructors
CFileDialog (BOOL bopenfiledialog,//TRUE for FileOpen, FALSE for FileSaveAs
LPCTSTR lpszDefExt = NULL,
LPCTSTR lpszFileName = NULL,
DWORD dwFlags = ofn_hidereadonly | Ofn_overwriteprompt,
LPCTSTR Lpszfilter = NULL,
cwnd* pParentWnd = NULL);
...... Omit n Multiple lines
Protected
BOOL M_bopenfiledialog; TRUE for File Open, FALSE for file Save
CString m_strfilter; Filter string
Separate fields with ' | ', terminate with ' | | "
TCHAR m_szfiletitle[64]; Contains file title after return
TCHAR M_szfilename[_max_path]; Contains full path name after return
Openfilename* m_pofntemp;
Virtual BOOL onnotify (WPARAM WPARAM, LPARAM LPARAM, lresult* pResult);
};
I found the address of the m_strfilter here is not correct.
0012F7EC is the address of the CFileDialog instance
The destructor m_strfilter is looking for the 0012f8a8, and then the operation will be wrong. Take a glance at the address. It doesn't feel right.
So when the constructor is tracked. Found M_strfilter's address was 0012f89c.
Compare two times the m_strfilter of this pointer in the ECX is synthesized. Very clearly different
add ecx 0b0h; construction time
add ecx 0bch; destructor
Whoa, that's an offset. How can it be different, this, and then take the time to study it.
Now listen, someone might have studied it. Brainwave, Bing under "Add ecx 0b0h", sure enough. The first one is hit.
Http://blog.titilima.com/show-590-1.html. There is an answer here.
Thank the author Mr. Li Ma:-)
The reason is very clear.
But how to change it, to move vs source code.
Of course, the source code of VS can also be changed. It's just that, by defining a retrospective file, we find
C:\Program Files\Microsoft Sdks\windows\v7.1\include Below
The original MFC4.2 era should not have v7.1 version number Ah, to see the folder set it
V7.1 's include is at the top.
Move decisively to the bottom. All in one generation, no problem, Theo.
It's unclear whether the setting has ever been moved. Or was it later loaded with VS2010 or DDK?
In short, we can feel. VC6 itself is not a problem, because the installation of multiple development environment caused by the conflict is the cause of this problem.
??
MFC Program Open File dialog box error problem resolution