none
"Async Callback exception causes w3wp to crash" when hosting a workflow in IIS is considered "Resolved - by design"? RRS feed

  • Question

  • A connect case regarding workflows hosted in IIS as been marked resolved as by design. See connect ID 558275 "Async Callback exception causes w3wp to crash when loading old instances of workflows in WorkflowServiceHost".

    This seems like a really lame resolution to me.  Is there any avenue of appeal for the design of this implementation?  Does anyone else in the community share my distaste for the current harsh exception handling of tearing down the whole w3wp.exe just due to an error in one particular .xamlx?  I think this forum has better traffic than connect so I'm hoping that if a few more people get exposed to this issue the community can provide additional feedback that might be missed on connect.

    I know that AppFabric is not yet RTM, so I hope there is still time to get this addressed maybe as part of the AppFabric release even if it requires a change in the core 4.0 bits.  It seems like there is already a presumption that if you are hosting in IIS you will use AppFabric so I would find it acceptable if the AppFabric release had a better more robust solution when a single workflow gets in a bad state.

    See http://connect.microsoft.com/VisualStudio/feedback/details/558275/async-callback-exception-causes-w3wp-to-crash-when-loading-old-instances-of-workflows-in-workflowservicehost 

    Anybody else have any thoughts on this issue?

    • Edited by PaulG Tuesday, May 18, 2010 6:52 PM another spelling fix
    Tuesday, May 18, 2010 6:52 PM

All replies

  • Hi, Paul

    Could you mail me a sample VS project with this crash prone xamlx file.
    Mail address: xhinker[at]gmail.com

    Regards
    This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft Online Community Support
    Friday, May 21, 2010 1:36 AM
    Moderator
  • Hi Paul,

    The crash of w3wp when you load an instance of a workflow whose definition has changed is indeed by design. We had planned to handle this case in a better way but didn't get to implement it.

    AppFabric won't be able to save you. The w3wp crash is designed into the WorkflowServiceHost, which is used by AppFabric.

    Regards, Ru 

    Friday, May 21, 2010 10:38 PM
    Moderator
  • Hi,

    I am facing the same issue, is there any solution?

    Regards,

    Tze Wen

     

    Monday, October 25, 2010 3:47 AM
  • So we had a similar issue with our ASP.NET / WCF server application when doing async calls and throwing exceptions within async voids.

    To solve this we made sure that we

    • used Task instead of void, so that there was a Task operation handle, as async void is pure fire/forget and could have a delayed error thrown which kills IIS.
    • make sure that the new tasks are awaited. This will make sure that all Tasks under the hood can be joined at some stage and the exception dealt with in the proper thread.

    From this point instead of IIS dying as an async exception was called, WCF was able to catch the exception and send a proper response.

    Hope this helps.

    Monday, November 11, 2019 10:13 AM