jkannen
2007-09-27 05:58:01 UTC
I am developing a very simple, statically linked MFC application. In this
application, I want to display the CFileDialog, but this causes an Access
Violation whenever I do so more than once.
There is a knowledge base article on a similar issue here:
FIX: Opening a CFileDialog from Handler of a Custom CFileDialog Causes
Access Violation
http://support.microsoft.com/default.aspx?scid=kb;EN-US;256329
This article seems to be completely describing the phenomenom I'm
experiencing (although it may be on the 3rd time I open a CFileDialog, rather
than the second, but I think that this varies). The only problem is, this
problem was supposedly fixed by a service pack to Visual Studio 6 for C++. I
am developing in Visual Studio 2005 (I've also installed SP1 to Visual Studio
- I am running the latest version available). So, whats up?
I've tried working around this problem by 1) not supplying an initial file
name, 2) changing my memory allocation to be completely sure I'm not doing
anything funky with the strings I'm passing in, 3) switching to the
GetOpenFileName method that utilizes the OPENFILENAME structure. In all
cases, I still get the same problem.
In all cases, the debugger gives me the following error:
Unhandled exception at 0x7ca5159e in FileSearcher.exe: 0xC0000005: Access
violation reading location 0x01393000.
The disassembly, surrounding the violation, in all cases looks like so:
7CA51563 repe cmps dword ptr [esi],dword ptr es:[edi]
7CA51565 jne 7CA515C9
7CA51567 mov ecx,dword ptr [ebp-228h]
7CA5156D lea eax,[ebp-21Ch]
7CA51573 push eax
7CA51574 push dword ptr [ebp-22Ch]
7CA5157A add ecx,0FFFFFFF0h
7CA5157D call 7CA37353
7CA51582 mov ebx,eax
7CA51584 test ebx,ebx
7CA51586 jl 7C9F6DA1
7CA5158C push dword ptr [ebp-230h]
7CA51592 mov eax,dword ptr [ebp-234h]
7CA51598 mov eax,dword ptr [eax+1C4h]
7CA5159E mov ecx,dword ptr [eax]
7CA515A0 lea edx,[ebp-21Ch]
7CA515A6 push edx
7CA515A7 push dword ptr [ebp-224h]
In a similar application I wrote just two weeks ago (and from which I stole
the code to create and DoModal on the CFileDialog) does not seem to have this
same problem (without rebuilding, I've been unable to get it to recreate this
problem, while I can always recreate it in my current app). I'm wondering if
some automatic update that has been pushed in the last few weeks may have
caused this...
Here is my current code:
TCHAR szFilter[] = _T("Text Files (*.txt)|*.txt|Log Files (*.log)|*.log|All
Files (*.*)|*.*||");
TCHAR szExt[] = _T("txt");
// Display the dialog
CFileDialog fileDlg(TRUE, szExt, NULL, OFN_FILEMUSTEXIST, szFilter, this);
if (fileDlg.DoModal() == IDOK)
{
CString strInputFilename = fileDlg.GetPathName();
m_InputFilenameEditCtrl.SetWindowTextW(strInputFilename);
}
application, I want to display the CFileDialog, but this causes an Access
Violation whenever I do so more than once.
There is a knowledge base article on a similar issue here:
FIX: Opening a CFileDialog from Handler of a Custom CFileDialog Causes
Access Violation
http://support.microsoft.com/default.aspx?scid=kb;EN-US;256329
This article seems to be completely describing the phenomenom I'm
experiencing (although it may be on the 3rd time I open a CFileDialog, rather
than the second, but I think that this varies). The only problem is, this
problem was supposedly fixed by a service pack to Visual Studio 6 for C++. I
am developing in Visual Studio 2005 (I've also installed SP1 to Visual Studio
- I am running the latest version available). So, whats up?
I've tried working around this problem by 1) not supplying an initial file
name, 2) changing my memory allocation to be completely sure I'm not doing
anything funky with the strings I'm passing in, 3) switching to the
GetOpenFileName method that utilizes the OPENFILENAME structure. In all
cases, I still get the same problem.
In all cases, the debugger gives me the following error:
Unhandled exception at 0x7ca5159e in FileSearcher.exe: 0xC0000005: Access
violation reading location 0x01393000.
The disassembly, surrounding the violation, in all cases looks like so:
7CA51563 repe cmps dword ptr [esi],dword ptr es:[edi]
7CA51565 jne 7CA515C9
7CA51567 mov ecx,dword ptr [ebp-228h]
7CA5156D lea eax,[ebp-21Ch]
7CA51573 push eax
7CA51574 push dword ptr [ebp-22Ch]
7CA5157A add ecx,0FFFFFFF0h
7CA5157D call 7CA37353
7CA51582 mov ebx,eax
7CA51584 test ebx,ebx
7CA51586 jl 7C9F6DA1
7CA5158C push dword ptr [ebp-230h]
7CA51592 mov eax,dword ptr [ebp-234h]
7CA51598 mov eax,dword ptr [eax+1C4h]
7CA5159E mov ecx,dword ptr [eax]
7CA515A0 lea edx,[ebp-21Ch]
7CA515A6 push edx
7CA515A7 push dword ptr [ebp-224h]
In a similar application I wrote just two weeks ago (and from which I stole
the code to create and DoModal on the CFileDialog) does not seem to have this
same problem (without rebuilding, I've been unable to get it to recreate this
problem, while I can always recreate it in my current app). I'm wondering if
some automatic update that has been pushed in the last few weeks may have
caused this...
Here is my current code:
TCHAR szFilter[] = _T("Text Files (*.txt)|*.txt|Log Files (*.log)|*.log|All
Files (*.*)|*.*||");
TCHAR szExt[] = _T("txt");
// Display the dialog
CFileDialog fileDlg(TRUE, szExt, NULL, OFN_FILEMUSTEXIST, szFilter, this);
if (fileDlg.DoModal() == IDOK)
{
CString strInputFilename = fileDlg.GetPathName();
m_InputFilenameEditCtrl.SetWindowTextW(strInputFilename);
}