locked
Application crash when using WorkItemHandler from C++ that handles exceptions

    General discussion

  • I have a simple setup, with a main C# project (Windows Store) that uses a C++ Windows Runtime Component.

    What I've found is that, whenever I use the WorkItemHandler from within C++ and an exception is thrown and catched inside the handler code, the termination just fails with a crash somewhere inside threadpoolwinrt.dll.

    The code is pretty simple. In the C#project, as a response to an item click, I'm just invoking an static class method from C# like:

     TestComponent.Test.testThread();

    And the C++ code is like:

    void Test::testThread() {
    
    	WorkItemHandler^ workItemHandler = ref new WorkItemHandler([=](IAsyncAction^)
    	{
            try
            {
    		OutputDebugString(L"Test");
    		throw 1;
            }
    	catch (int i) {
    		OutputDebugString(L"Error (int)!");
    	}
            catch (...) {
    		OutputDebugString(L"Error!");
    	}
    	}, CallbackContext::Any);
    	ThreadPool::RunAsync(workItemHandler, WorkItemPriority::Normal, WorkItemOptions::TimeSliced);
    }

    No matter how I play with the options passed to the ThreadPool::RunAsync method, the code inside the lambda function executes normally; the exception is thrown and correctly catched; but when the WorkItemHandler terminates (when it's actually destroyed after the task has been completed) the application just crashes.

    No more meaninful information is provided; just the standard crash info (Uncontrolled excepción at 0x000007FF8E0363D8 (threadpoolwinrt.dll) in oetestRT.exe: 0xC0000005: Access violation reading address 0x00000620FFFFFBA8).

    Am I doing somwthing wrong here? It's a very basic sample...maybe I'm not getting something right.

    Any hints?

    PS: I'm using VS2012 Express, and the project is built for x64 architecture (just in case that helps)






    • Edited by derodo Tuesday, August 6, 2013 11:01 AM typo
    Tuesday, August 6, 2013 10:53 AM

All replies

  • Just found the problem goes away when building for x86 architecture.

    I guess there's something wrong with x64 and exception handling and/or ThreadPool (or again, I'm doing something wrong I'm not aware of).

    Still looking for a solution/workaround on x64

    Tuesday, August 6, 2013 11:11 AM