locked
Infinite loop within Input Handling Code on CoreWindow side. RRS feed

  • Question

  • Hello,

    I hope this is right place to ask this question. Not yet sure if this is issue on my side or there is a bug on the system side of things. Short background: We are porting existing C++ engine to Windows Phone / Windows Store. While testing we found out that the games sometimes freeze.

    I almost tear-up whole engine upside down and found out that this is an issue even with minimalistic approach to the project using similar techniques to do the XAML/DX Interop.

    The easiest way to produce the bug is to put 3-4 fingers on the phone screen and start moving fingers, tapping etc. After a short while it freezes. The problem is that you don't have to go crazy with 3-4 fingers on the screen because it also happens during regular gameplay if you swipe/tap properly. After further investigation it seems that it goes crazy throwing, catching and re-throwing the same exception I guess. This is the call stack I managed to get:

    >    KERNELBASE.DLL!RaiseException()    Unknown
         MSVCRT.DLL!_CxxThrowException()    Unknown
         MINUSER.DLL!Cn::Throw::Now(class System::Exception *,char const *,unsigned int,void *)    Unknown
         MINUSER.DLL!Cn::Throw::IndexOutOfRangeException(void)    Unknown
         MINUSER.DLL!Input::InputQueue::SetAmbientEntry(class Input::InputEntry *)    Unknown
         MINUSER.DLL!Input::InputQueue::RemoveOrDelegateEntry()    Unknown
         MINUSER.DLL!Input::InputQueue::Read()    Unknown
         MINUSER.DLL!Input::InputQueue::PeekForInput(class Core::MessageFilter *)    Unknown
         MINUSER.DLL!minPeekMessageW()    Unknown
         WINDOWS.UI.DLL!69f07220()    Unknown
         WINDOWS.UI.DLL!69f07136()    Unknown
         WINDOWS.UI.XAML.DLL!CJupiterWindow::RunCoreWindowMessageLoop(void)    Unknown
         WINDOWS.UI.XAML.DLL!CJupiterControl::RunMessageLoop(void)    Unknown
         WINDOWS.UI.XAML.DLL!DirectUI::DXamlCore::RunMessageLoop(void)    Unknown
         WINDOWS.UI.XAML.DLL!DirectUI::FrameworkView::Run(void)    Unknown
         TWINAPI.APPCORE.DLL!Windows::ApplicationModel::Core::CoreApplicationView::Run(void)    Unknown
         TWINAPI.APPCORE.DLL!CWrlLightweightHandlerBase::ReleaseMarshalData(struct IStream *)    Unknown
         SHCORE.DLL!SHCreateThreadRef()    Unknown
         NTDLL.DLL!RtlUserThreadStart()    Unknown

    Also in Output Windows of Visual Studio I get this message all the time when the freeze occurs:

    First-chance exception at 0x775859A3 in Test.WindowsPhone.exe: Microsoft C++ exception: Cn::XH at memory location 0x0203FB78.

    We were using (as our publisher suggested in his samples)

    CompositionTarget::Rendering::add

    To wire our update/rendering logic in a XAML page containing swapChain although I don't know if this is relevant. He also advised that they got similar reports from other developers using the same technique and finally switched to other solutions. He suggested we try to run DispatcherTimer and so we did - the effect is exactly the same.

    It seems that there is some problem with inputs but the strange thing is that we keep getting the OnPointerPressed/OnPointerReleased callbacks but the Dispatcher stops ticking and the game does not Update nor Render.

    Any help would be appreciated.

    Friday, December 5, 2014 10:35 AM

Answers

  • Hello,

    I was asked to look at this for you. I believe that I have been able to reproduce the issue. A link to my test code is included below. Please review it and make sure that it fits your scenario.

    Assuming that this code matches what you are doing in yours, the issue appears to be due to a very complex interaction between the Core UI dispatcher and the direct manipulation module. Theoretically you should be able to avoid this problem by disabling direct manipulation for the control. Unfortunately setting the manipulation mode to "none" does not have the desired effect.

    If this code does match what you are doing please let me know and I will continue to investigate.

    http://1drv.ms/1wir7Gt

    Thanks,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Thursday, December 11, 2014 1:00 AM
    Moderator

All replies

  • Hi Adrian,

    I’m trying to reproduce your issue at my side. But I failed to reproduce this issue by creating a new “DirectX and XAML App (Windows Phone)” project. Would you mind sharing a sample project through OneDrive and giving the repro steps to help us reproduce this issue?

    Regards,

    Jeffrey


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Monday, December 8, 2014 6:47 AM
  • Hi Jeffrey,

    Actually I found out what was causing this more precisely. The sample with XAML/DirectX Interop had a dedicated background thread for Input Processing, but we didn't use this since we already had Update/Tick working on XAML UI Thread (via CompositionTarget)

    So what I had was hooks for OnPointerPressed/Released/Move directly in the SwapChainPanel object (or the XAML DirectXPage - it doesn't matter - outcome is the same)

    This is actually enough. If you tap a lot for a couple of seconds it breaks with the given callstack.

    Regards,

    Adrian

    Monday, December 8, 2014 6:20 PM
  • Hello,

    I was asked to look at this for you. I believe that I have been able to reproduce the issue. A link to my test code is included below. Please review it and make sure that it fits your scenario.

    Assuming that this code matches what you are doing in yours, the issue appears to be due to a very complex interaction between the Core UI dispatcher and the direct manipulation module. Theoretically you should be able to avoid this problem by disabling direct manipulation for the control. Unfortunately setting the manipulation mode to "none" does not have the desired effect.

    If this code does match what you are doing please let me know and I will continue to investigate.

    http://1drv.ms/1wir7Gt

    Thanks,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Thursday, December 11, 2014 1:00 AM
    Moderator