CFileDialog::DoModal() causes Access Violation 0xC0000005   14 comments

  • There seems to be an issue with CFileDialog causing an unhandled exception/access violation after the CFileDialog::DoModal window is closed.
  • According to Microsoft this is a known issue, caused by a race condition, within NetworkItemFactory.dll.
  • I can easily reproduce the crash on demand at least 60% of the time.
  • Crash occurs exactly 60 seconds after closing the CFileDialog when dynamically linking MFC.
  • Crash occurs immediately after closing the CFileDialog when statically linking MFC.
  • Crash occurs also when using ::GetOpenFileName.
  • In my experience, this crash only occurs while debugging.
  • This seems completely unrelated to other reported issues of CFileDialog causing access violations with VC6/VS2003, which seem related to the structure size of OPENFILENAME.
  • I’m using Win7 SP1 64-bit with Visual Studio 2010 SP1, Platform SDK 7.1.
  • Some 3rd party software, such as having Adobe Acrobat Reader installed, seems to make the crash occur more often.

Unhandled exception at MEMORYLOCATION (ntdll.dll) in FILENAME.exe: 0xC0000005: Access violation reading location 0xfeeefeee

Steps to replicate:

  • There are many ways to replicate this crash, here is what I believe to be the absolute minimum necessary:
  • Create a new “MFC Application” project.
  • Add the following code snippet to theApp::InitInstance.
  • Put a breakpoint on the line Sleep( 1 ).
  • Start debugging.
  • Browse and select a file.
  • Wait (60 seconds) for the debugger to stop on your breakpoint.
  • Clicking Continue or pressing F5 should immediately trigger an Access Violation.
CFileDialog fileDialog( TRUE );
fileDialog.DoModal();
Sleep( 60000 );
Sleep( 1 ); // put a breakpoint here

Suggestion # 1: uninstall Acrobat Reader/Disable RPC Debugging:

  • I recommend trying this first, only because it is more convenient to try.
  • Uninstall Adobe Acrobat Reader.
  • -AND-
  • Disable RPC Debugging:
    • Tools-> Options-> Debugging-> Native-> Enable RPC debugging, uncheck it (disable it).
  • This is what fixed it for me. Seems to be 100% resolved. Tested about 300 times, zero crashes.
  • Afterwards I also installed the Hot-fix listed below, but the issue seems to have already been fixed by these steps.
  • If you’re still getting the error, try the hotfix.

Suggestion # 2: install experimental Hotfix from Microsoft:

  • Try installing this experimental Hot-fix from Microsoft (install at your own risk).
  • http://support.microsoft.com/kb/2718841/en-us
  • Thanks Kelly.
  • The Hot-fix is packaged in an self-extracting-exe. It prompts for an unzip path, which defaults to C:\, however it does not seem to accept this as a valid path. Change the path to something besides the root path.
  • The installer does not seem to automatically create a system restore point, so I suggest manually creating one prior to installing (thanks TD-er).
  • This step (or the first one listed above) should resolve the issue. If you’re still getting the error it maybe another unrelated scenario which requires some other fix.

One or both of either the above 2 items should resolve the issue. While I was still researching this issue, I found the following items to cause the crash to occur less often. I no longer consider the following items part of the solution. I still list them for educational use, in case you are interested in doing further research on this issue.

Disable 3rd party shell extensions:

  • This is not really a solution, but for some reason these seem to cause the crash to occur less often.
  • Disable buggy 3rd party shell extensions.
  • Any software which adds special icons in Windows Explorer, or which adds menu items to the desktop or Windows Explorer right-click context menu is suspect.
  • These applications should be uninstalled, or disabled using ShellExView, and then *REBOOT*.
  • I recommend using Nirsoft’s ShellExView, and disable *ALL* non-Microsoft shell extensions.

Use CoInitializeEx:

  • This is not really a solution, but for some reason these seem to cause the crash to occur less often.
  • Use CoInitialize Ex, instead of AfxOleInit or CoInitialize.
  • If you replace use of AfxOleInit, you must also add CoUninitialize in your YourApp::ExitInstance.

Debug Output:

  • The last 3 lines appear exactly 60 seconds after closing the CFileDialog.
First-chance exception at 0x7652b9bc (KernelBase.dll) in maint32.exe: 0x000006BA: The RPC server is unavailable.
First-chance exception at 0x7652b9bc (KernelBase.dll) in maint32.exe: 0x000006BA: The RPC server is unavailable.
First-chance exception at 0x7652b9bc (KernelBase.dll) in maint32.exe: 0x80010108: Server Disconnected from clients.
First-chance exception at 0x7652b9bc (KernelBase.dll) in maint32.exe: 0x80010108: Server Disconnected from clients.
First-chance exception at 0x7652b9bc (KernelBase.dll) in maint32.exe: 0x80010108: Server Disconnected from clients.
First-chance exception at 0x7677c99e (ole32.dll) in maint32.exe: 0xC0000005: Access violation reading location 0xfeeefeee.
First-chance exception at 0x7652b9bc (KernelBase.dll) in maint32.exe: 0x80010108: Server Disconnected from clients.
Unhandled exception at 0x77bb15de (ntdll.dll) in maint32.exe: 0xC0000005: Access violation reading location 0xfeeefeee.

Call Stack, main thread:

  • I enabled load all symbols in Tools-> Options-> Debug-> Symbols to get complete call stack.
ntdll.dll!_ZwRaiseException@12() + 0x12 bytes
 ntdll.dll!_ZwRaiseException@12() + 0x12 bytes
 ole32.dll!SilentlyReportExceptions(_EXCEPTION_POINTERS * lpep) Line 133 C++
 ole32.dll!ServerExceptionFilter(_EXCEPTION_POINTERS * lpep) Line 190 C++
 ole32.dll!AppInvokeExceptionFilterWithMethodAddress(_EXCEPTION_POINTERS * lpep, void * pvObject, const _GUID & riid, unsigned long dwMethod, void * pvVtableAddress, const char * szPossibleCause) Line 379 C++
 ole32.dll!AppInvokeExceptionFilter(_EXCEPTION_POINTERS * lpep, void * pvObject, const _GUID & riid, unsigned long dwMethod) Line 485 C++
 ole32.dll!FinishShutdown() Line 1037 + 0x19 bytes C++
 msvcrt.dll!@_EH4_CallFilterFunc@8() + 0x12 bytes
 msvcrt.dll!__except_handler4_common() + 0x87 bytes
 ole32.dll!_except_handler4(_EXCEPTION_RECORD * ExceptionRecord, _EXCEPTION_REGISTRATION_RECORD * EstablisherFrame, _CONTEXT * ContextRecord, void * DispatcherContext) Line 90 + 0x1b bytes C
 ntdll.dll!ExecuteHandler2@20() + 0x26 bytes
 ntdll.dll!ExecuteHandler@20() + 0x24 bytes
 ntdll.dll!_RtlDispatchException@8() + 0xd3 bytes
 ntdll.dll!_KiUserExceptionDispatcher@8() + 0xf bytes
 ole32.dll!CStdMarshal::Disconnect(unsigned long dwType) Line 3420 C++
 ole32.dll!DisconnectSwitch(void * pv) Line 3119 C++
 ole32.dll!CStdMarshal::DisconnectAndRelease(unsigned long dwType) Line 3167 C++
 ole32.dll!COIDTable::ThreadCleanup() Line 1760 + 0xa bytes C++
 ole32.dll!FinishShutdown() Line 1035 C++
 ole32.dll!ApartmentUninitialize(int fHostThread) Line 1291 C++
 ole32.dll!wCoUninitialize(COleTls & Tls, int fHostThread) Line 2766 + 0x8 bytes C++
 ole32.dll!CoUninitialize() Line 2620 C++
 networkitemfactory.dll!FDBackgroundThreadHandler() + 0x21 bytes
 shlwapi.dll!WrapperThreadProc() + 0xd3 bytes
 kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
 ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
 ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
About these ads

14 responses to “CFileDialog::DoModal() causes Access Violation 0xC0000005

Subscribe to comments with RSS.

  1. I have exactly this problem and it’s bugging me for months now.
    It is not a problem when running the software without the debugger, but when I use any file-open dialog from within the debugger, it will crash after about a minute after closing the file-dialog. (I’m running VS2005 on Windows 7 64bit, but a colleague of mine is experiencing it sometimes on his computer which runs the same studio but on a 32-bit Windows)

    When you set a trigger for the exception 0x6BA, you’ll see a first-chance exception being thrown almost immediately after opening the file-dialog.

    I was able to reproduce this issue with any of the Qt 4.8 demo applications using a file-dialog and also with a very simple program using only a file-dialog and doing nothing with the output of that dialog.

    I already uninstalled any program which was in my context-menu, except for our virusscanner (Kaspersky), since I’m not able to uninstall that myself.
    Also tried it without our surround plugin.

    It is not happening on all computers here in our company.

  2. Thank you so much. At the very least this article helped me to stop questioning my own sanity and instead focus on the sanity of COM/OLE internals. The crash I experienced had an almost identical message: Unhandled exception at 0x755fc99e (ole32.dll) in some_app.exe: 0xC0000005: Access violation reading location 0xfeeefeee.

    As you can see, mine says ole32.dll where the one in the article says ntdll.dll. My callstack (with full symbols) is the same, except mine stopped at ole32.dll!CStdMarshal::Disconnect.

    I installed the ShellExView that you mention, and I disabled more than half the shell extensions. I did not notice a difference until after a reboot (despite restarting Windows Explorer several times before doing a full reboot).

    Also, I found a forum thread in German that I failed to fully understand but that led me to this hotfix: http://support.microsoft.com/kb/2718841/en-us

    I installed the hotfix. My problems all seem to have abated. I will do further experimentation (time permitting) to reenable shell extensions to see if the problem returns and to see if I can narrow it down to a particular extension. Perhaps the hotfix fixed everything and all shell extensions can once again be reenabled. It might take me days to figure it out, or I might just accept my new “status quo” now that things are good and just stop questioning for now.

    • That (apparently experimental) hotfix also did fix it for me.

      That’s the best start of the day, knowing I can now safely open a file-open/-save dialog and not being afraid the program will crash.

      I had a simple test-program which could reproduce this issue in 100% of the cases on my computer. It also could reproduce the issue in some cases on one other computer of a colleague of mine and on no other computer.

      I’m really happy this misery is finally over. :)

    • if I install and use the hotfix and build my project will my user need to install that hotfix to use my app? if so then it’s to waste time being happy of no success.

      • Hosein:
        The issue seems to only occur in debug builds.
        Install the hot-fix so the issue is fixed for you while debugging.
        Send your clients the release build.
        Problem solved.

  3. It appeared a colleague of mine also experienced the same issues, only at different moments.
    He was having random crashes of explorer.exe and the same exception 0xC0000005 appeared frequently in his event viewer when explorer had crashed.

    So he was seeing these bugs during normal Windows use and I mainly saw these when running applications with the debugger connected.
    But now I know what to look for, I also see a number of entries in the event viewer with this Exception code: 0xc0000005
    - AcroRd32.dll
    - thunderbird.exe
    - cl.exe and VCbuild.exe (Visual studio)
    - Explorer.EXE

    And numerous other programs.

  4. Pingback: Hotfix voor crashes Unhandled exception 0xC0000005 | TD-er

  5. Just disable the visual theme of your exe file and it will work fine.

    I disabled it and now its working fine.
    Steps to disable the visual theme:

    1>Right click the .exe file.
    2>Go to properties and then Compatibility tab.
    3>Check the “Disable visual theme” checkbox.

    Thanks and Regards,
    Anup Kumar

  6. I have ‘wasted’ several days trying to work around this issue. It often failed in debug mode, and never in release mode.

    My current fix is to set the CFileDialog top run in Non Vista mode. ie the final parameter is BOOL bVistaStyle and set this to FALSE

    I now do a conditional compile so that I can select files, and still debug.

    I found the problem on Win7-64 and Win8-64, VS2010 and VS2012

  7. I had written my program in Borland c++ 5.02 1997 the structure worked well now I have converted it to vs 2010 and the problem happens as I close the dialog box actually the file name never seem to be generated by the dialog, and when I break the process to watch the value of my filename variable it says “bad ptr” and as I use this variable the error comes. my RPC debugging is off by default.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: