Discussion:
CFileDialog causes Access Violation... again...
(too old to reply)
jkannen
2007-09-27 05:58:01 UTC
Permalink
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);
}
Sarath
2007-09-27 11:03:01 UTC
Permalink
Which is your development environment?

The KB article you specified only dealing with

• Microsoft Visual Studio 6.0 Service Pack 1, when used with:
Microsoft Windows 2000 Standard Edition
• Microsoft Visual C++ 6.0 Professional Edition
• Microsoft Visual Basic 6.0 Enterprise Edition
--
-Sarath
Post by jkannen
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.
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.
Unhandled exception at 0x7ca5159e in FileSearcher.exe: 0xC0000005: Access
violation reading location 0x01393000.
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...
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);
}
jkannen
2007-09-27 13:28:09 UTC
Permalink
Visual Studio 2005 Team Edition for Software Developers.

I know that the article deals with older versions of Visual Studio, rather
than mine. But, I was thinking that the problems must somehow be related,
because the problem I'm experiencing is almost identical. I'm wondering if
some recent change by MS has broken their original fix.

Another suggestion I've seen (on other forums) is that the problem is
related to hovering over tooltips in the file list (in the CFileDialog). As
I've been playing with it, I'm actually noticing the same problem - more and
more this is seeming like the culprit. In other forums, someone who was
having this same problem mentioned that if they changed something in their
registry, this problem went away. This is not a viable solution, since I
really don't want to make changes to my users registries as a hack for a
problem that is not caused by my code.

I've been able to replicate this same problem in Notepad. In Notepad, I open
the File Open dialog and select and open a file. I then go back into the File
Open dialog and slowly move my mouse over the files. This usually causes
Notepad to crash. If it doesn't work right away, I can select a file and
repeat the process and it will happen. Just a matter of time.

I'm running Windows XP Professional, Service Pack 2.
Post by Sarath
Which is your development environment?
The KB article you specified only dealing with
Microsoft Windows 2000 Standard Edition
• Microsoft Visual C++ 6.0 Professional Edition
• Microsoft Visual Basic 6.0 Enterprise Edition
--
-Sarath
Post by jkannen
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.
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.
Unhandled exception at 0x7ca5159e in FileSearcher.exe: 0xC0000005: Access
violation reading location 0x01393000.
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...
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);
}
David Lowndes
2007-09-27 15:38:46 UTC
Permalink
Post by jkannen
I've been able to replicate this same problem in Notepad. In Notepad, I open
the File Open dialog and select and open a file. I then go back into the File
Open dialog and slowly move my mouse over the files. This usually causes
Notepad to crash. If it doesn't work right away, I can select a file and
repeat the process and it will happen. Just a matter of time.
I've tried it several times with Notepad now and it's not happened for
me. Do you have an Anti-Virus product installed? Try without it. If
that makes no difference, try dropping the video acceleration setting
for your PC and see if that makes any difference.

Dave
jkannen
2007-09-27 22:02:03 UTC
Permalink
No dice. Thanks anyways. I appreciate the effort.
Post by David Lowndes
Post by jkannen
I've been able to replicate this same problem in Notepad. In Notepad, I open
the File Open dialog and select and open a file. I then go back into the File
Open dialog and slowly move my mouse over the files. This usually causes
Notepad to crash. If it doesn't work right away, I can select a file and
repeat the process and it will happen. Just a matter of time.
I've tried it several times with Notepad now and it's not happened for
me. Do you have an Anti-Virus product installed? Try without it. If
that makes no difference, try dropping the video acceleration setting
for your PC and see if that makes any difference.
Dave
Sarath
2007-09-28 00:07:01 UTC
Permalink
I doubt in the following cases.

1. You have installed SP1 of Visual Studio 2005
2. Make sure that are there any conflict with the other libraries you are
linking with. Make sure you have specified correct version of lib
(Release/Debug version mismatch will also cause for the same).
--
-Sarath
Post by jkannen
Visual Studio 2005 Team Edition for Software Developers.
I know that the article deals with older versions of Visual Studio, rather
than mine. But, I was thinking that the problems must somehow be related,
because the problem I'm experiencing is almost identical. I'm wondering if
some recent change by MS has broken their original fix.
Another suggestion I've seen (on other forums) is that the problem is
related to hovering over tooltips in the file list (in the CFileDialog). As
I've been playing with it, I'm actually noticing the same problem - more and
more this is seeming like the culprit. In other forums, someone who was
having this same problem mentioned that if they changed something in their
registry, this problem went away. This is not a viable solution, since I
really don't want to make changes to my users registries as a hack for a
problem that is not caused by my code.
I've been able to replicate this same problem in Notepad. In Notepad, I open
the File Open dialog and select and open a file. I then go back into the File
Open dialog and slowly move my mouse over the files. This usually causes
Notepad to crash. If it doesn't work right away, I can select a file and
repeat the process and it will happen. Just a matter of time.
I'm running Windows XP Professional, Service Pack 2.
Post by Sarath
Which is your development environment?
The KB article you specified only dealing with
Microsoft Windows 2000 Standard Edition
• Microsoft Visual C++ 6.0 Professional Edition
• Microsoft Visual Basic 6.0 Enterprise Edition
--
-Sarath
Post by jkannen
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.
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.
Unhandled exception at 0x7ca5159e in FileSearcher.exe: 0xC0000005: Access
violation reading location 0x01393000.
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...
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);
}
jkannen
2007-09-27 13:33:01 UTC
Permalink
I'm no longer suspecting a recent Automatic Update. I was finally able to get
my original app to duplicate the same problem. See my reply to Sarath for my
best current understanding of the issue. (In short: I can get Notepad to
duplicate my problem - which indicates to me it's not my code, but something
within the SDK, that is causing this problem.)
Post by jkannen
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.
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.
Unhandled exception at 0x7ca5159e in FileSearcher.exe: 0xC0000005: Access
violation reading location 0x01393000.
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...
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);
}
Alexander Grigoriev
2007-09-28 04:53:03 UTC
Permalink
Upgrade your Acrobat Reader and install a hotfix
http://support.microsoft.com/kb/909486/en-us
Post by jkannen
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.
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.
Unhandled exception at 0x7ca5159e in FileSearcher.exe: 0xC0000005: Access
violation reading location 0x01393000.
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...
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);
}
Loading...