I have added an "Open file" dialog to my dialog-based MFC application. Now, exactly one minute(!) after an open file dialog is closed by pushing either Open or Cancel button my application crashes. While it crashes, the following things are happening in the output:
1) a bunch of Windows threads are exiting;
2) a bunch of COM exceptions (of 0x80010108 "the object invoked has disconnected from its clients" and 0x800401FD "Object is not connected to server" variety) are being thrown;
3) finally, an unhandled exception occurs: 0xC0000005: Access violation reading location 0xfeeefeee, with call stack pointing to ole32.dll.
To say that I am bewildered is quite an understatement. The code for invoking the dialog is as follows:
CFileDialog fileDlg( TRUE, _T(".txt"), NULL, OFN_ALLOWMULTISELECT | OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST,
_T("Text file (*.txt)|*.txt||"), this);
INT_PTR res = fileDlg.DoModal();
What could cause such a thing?
How do I even debug it?
I had this exact issue in Windows 7 x64, and by enabling breakpoints on all Win32 exceptions not already chosen (in the VS2015 exceptions tab), I was able to narrow it down to a known issue with fundisc.dll that was resolved with an optional Hotfix from Microsoft: https://support.microsoft.com/en-us/kb/2494427
It also resolved issues on my PC of File Explorer windows crashing at seemingly random times. All were caused by some deadlock in the networking COM objects that is fixed by that hotfix.
Related
I am upgrading from Windows 7 to Windows 10. I tried to use activex (ocx) in Windows 10, but the program did not start and ended. I got the source and checked it, but compiling is not a problem, but when I make ocx and load it in another program and use it, "Warning: Creating dialog from within a COleControlModule application is not a supported scenario." is a debug message. Even if it is compiled and used in Release version, it does not run. The activeX program structure in question is used by creating CDialog inside.
Can this situation be solved simply?
//code
m_CamDlg.Create( IDD_CAMDIALOG, this); // <= There is a problem here
TRACE("CLiveViewCtrl OnCreate 3\n");
m_CamDlg.ShowWindow(1);
In our 32-bit Windows MFC application we use IWebBrowser2 to display HTML content. We also (because MFC does it for us and we're running on Windows 10) use the new IFileDialog COM interface to the common file open dialog.
When we have a web browser window visible in the application, the file dialog will not open, or will open once but never again unless you run the application down and back up again. What usually happens is that this MFC call:-
HRESULT hr = (static_cast<IFileDialog*>(m_pIFileDialog))->Show(m_ofn.hwndOwner);
simply returns "0x800704c7 The operation was canceled by the user" without even displaying the dialog.
Closing the HTML view/window allows the IFileDialog to work as expected, so the two components seem to be interfering with each other in some way.
This is now happening with software we haven't changed for months, and it seems only to be restricted to Windows 10, but we can find nothing online that gives any clues about the cause.
David.
I have the answer to this. a) Your syntax for calling ->Show() is all wrong. b) There are nested guards in the include file 'shobjidl.h' that are blocking processing of the definitions for IFileDialog COM classes, hence many people have been getting compilation errors, unable to generate that elusive output .exe
Essentially all you need when calling the ->Show method is the following loc:
HRESULT hr = pFileDialog->Show(NULL);
See the explanation & example program at:
https://github.com/InventorDave/IFileDialog-gcc-Fix
I maintain an application written using visual studio 2010 and wxWidgets version 2.8.10. It has been reported to me that, under windows vista, the application will crash when displaying a wxFileDialog that is viewing a network drive and being resized. The dialogue is invoked with the following code:
wxFileDialog file_chooser(
this,
make_wxString(my_strings[strid_file_choose_caption]),
make_wxString(frame->get_config()->get_last_os_dir()),
wxT(""), // default file
make_wxString(loader->get_file_extension()),
wxOPEN);
int rcd = file_chooser.ShowModal();
Has anybody seen anything similar?
Crashes inside the standard file dialog are almost invariably due to the presence of some buggy shell extension on the system. To say anything more you'd need to get the minidump (or at least a stack trace) at the moment of crash and debug it.
itsAnalysisDataTable.CreateEx( WS_EX_CLIENTEDGE, AfxRegisterWndClass( CS_DBLCLKS, LoadCursor( NULL, IDC_ARROW ), (HBRUSH)::GetStockObject( NULL_BRUSH ), NULL ), "AnalysiysTable", WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_TABSTOP, dialogItemRect, this, IDC_ANALYSIS_DATA_TABLE );
This line has cost me two days of effort with no solution. itsAnalysisDataTable is a custom windows control having CWnd as its grand grand grand parent. The control has been successfully used in other paces without issues in our code. this is a CPropertyPage.
The problem I have is the line causes (and it does it every time) an
Unhandled exception at 0x76f7fd5c in MyProduct (x64).exe: 0xC015000F: The activation context being deactivated is not the most recently activated one.
The exception occurs in 32-bit as well. I'm on Windows 7 x64, VS 2008.
What I have already tried:
Enabling break on win32 exceptions in the debugger. No exception occurs (except first chance exceptions of which there are a lot in our code and have no effect)
Recompiling the whole project
Debugging the OnCreate handler for the control for exceptions.
Call Stack:
ntdll.dll!0000000076f7fd5c()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
kernel32.dll!0000000076df42d3()
mfc90d.dll!AfxDeactivateActCtx(unsigned long dwFlags=0, unsigned __int64 ulCookie=2077018657900210161) Line 260 + 0x19 bytes C++
Observations:
If I skip the WS_CHILD flag the exception does not happen, but OnCreate is also not called on the control!
If I ignore the exception and continue, the application works fine, the control also works fine.
Calling AfxSetAmbientActCtx(FALSE) during app init suppresses the exception. But I think this is a hack, unless I can justify it.
After hitting a lot of these, I've found the simple way to track down the root issue is to go to Debug -> Exceptions and enable ALL Thrown exceptions. Then you'll find there is some other exception that is firing, being silently caught, BUT messing up the activation context. Once you fix the first exception, the activation context exception won't happen.
Turns out mine was due to an uninitialized member in the offending control class. Initializing the variable in the constructor fixed the issue. So I did not have to resort to AfxSetAmbientActCtx(FALSE)
Calling AfxSetAmbientActCtx(FALSE) during app init suppresses the
exception. But I think this is a hack, unless I can justify it.
The discussion on MS Connect 'MFC default exception handling causes problems with activation context' might help you justify the hack being a workaround suggestion from Microsoft.
Had the same problem.
In my case i was reading a file from a path and I accidentally deleted that file. Putting the file back solved the issue.
Had some mysterious crashes in a program that hosted IE along with several ActiveX controls.
Turns out an earlier division by zero (by one of the AX controls) eventually caused this exception and a subsequent Access Violation as well.
I had the following lines of C++ code in my program
CFileDialog dialog(true);
CString strFileName=L"";
INT_PTR nResult = dialog.DoModal();
if(nResult == IDOK)
// Exception spotted here
// Debug information gives me --> dialog = {CFileDialog hWnd=0x00000000}
// What's the heck?
strFileName=dialog.GetFolderPath();
The problem is: When I execute the program on a PC running Windows XP, there always have an ugly exception which I don't know why it happened. But everything's fine when I copied it to another PC running Windows 7.
I'm desperate. Would you guy please tell me why?
You need to call
DWORD WINAPI CommDlgExtendedError(void);
after the instantiation of CFileDialog to check that it is instantiated OK and if not why not.
Edit:
You are not able to call GetFolderPath after the dialog is closed which it is when DoModal() returns. Look at this MSDN page under remarks on how to pass a buffer to hold the file names.
The fun of building on a Window7 machine, and deploying to XP.
If you trace through the MFC code:
::GetVersion() is called and executes all kinds of different code for Windows Visa and above. i.e. It behaves differently.
So this means that if you called GetPathName, GetFileName, or GetFolderPath after a DoModal in WIN7 it works as you'd expected (like Java). For Windows XP you would be incorrect, and the software crashes.
I could not use GetFolderPath on XP, but GetPathName was ok.