• Advertisement
Sign in to follow this  

[Win32] IFileOpenDialog::Show throw exception

This topic is 2537 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello!

Im observing a very weird behaviour when using the IFileOpenDialog interface. I have the following wrapper:


FileOpenDialog::FileOpenDialog()
{
    HRESULT res = CoCreateInstance(CLSID_FileOpenDialog, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&m_native));
    if(m_native == NULL)
        throw Win32Exception("CoCreateInstance", HRESULT_CODE(res));
}

void FileOpenDialog::ShowDialog(HWND hWindow)
{
    HRESULT hRes = m_native->Show(hWindow);
}


I also have my own exception system built up. But now if i use that code m_native->Show throws an exception with code 0x6BA which will launch my exception system. Normally i terminate my application if exceptions occur after displaying some infos about it. But if i now return EXCEPTION_CONTINUE_SEARCH the system doesnt care about that exception and all works as it should.

Image:
4d530a8ee5a354_ex.jpg


So i have three questions:
Why is there obviously another handler even if i set my handler up with AddVectoredExceptionHandler and First set to FALSE?
Why is that exception thrown?
How can i determine if i really have an unhandled exception which wont have any handler in later handlers?

Greetings and thanks
Plerion

Share this post


Link to post
Share on other sites
Advertisement
Vectored exception handlers are not the only type of SEH exception handlers. In addition to vectored exception handlers there are frame based exception handlers and a top level exception handler for the thread. When an SEH exception is raised, first the vectored exception handlers are tried, then any frame based exception handlers then finally the top level exception handler. For a vectored exception handler, there's always another exception handler that could be called. The default behavior of the top level exception handler is to "handle" the exception by displaying an error message saying there has been an unhandled exception, so trying to find out if there's an handler that will handle the exception isn't actually all that useful. However, it sounds like you don't really want a vectored exception handler, but you want your exception handler to be the top level handler. To do this you can use the SetUnhandledExceptionFilter() function.

Share this post


Link to post
Share on other sites
Hey!

Thank you for the tip, ive messed something up with my most recent project where i had to catch exceptions _before_  the games own handler comes to play (i was drawing a chatoverlay into a games client). But now i have the problem, that no exception is catched at all. I always get an APPCRASH-message from windows excatly pointing to the location where ive put my __asm cli; (checked with IDA). So it seems that the exception is not passed to my unhandled exception filter at all (set using SetUnhandledExceptionFilter).

Greetings

Share this post


Link to post
Share on other sites
If that's not working for you, I'd just use a frame based handler.

Share this post


Link to post
Share on other sites
Actually i would like to understand why its not working. Why is my call to SetUnhandledExceptionFilter obviously completely ignored? My exception handler never gets called at all and i get an appcrash. Ive used SetUnhandledExceptionFilter before without any problems but now im just skipped by the OS. May the problem be that i call the function inside a DLL and register a function within it?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement