locked
Debugging Access violation exceptions RRS feed

  • Question

  • Hi,

    My app is producing an Access violation exception when I drag and drop a GridViewItem and then interact with that item. The crash only happens in touch mode and not when using the mouse. The GridViewItem is a custom table/data grid UserControl implementation. I have other types of custom grid items but interacting with them after a drag and drop operation does not crash the app. So I'm guessing something is wrong with this particular UserControl, which is causing this exception.

    Can anybody provide tips on how to debug this error for metro apps (now called 'Windows Store apps', I think)? I'm kind of working blindly here and don't really having a starting point. What steps can I take to identify the fault point?

    The following are the details:

    App Type: XAML C#

    Windows Types: Windows 8 RTM, Windows RT (Build 9200)

    Scenario:

      • Drag and drop a GridViewItem
      • Touch the GridViewItem (not mouse click)
      • Crash occurs

    Output Window:

    First-chance exception at 0x5898109e in PVMetro.exe: 0xC0000005: Access violation reading location 0x00000000.
    Unhandled exception at 0x5898109e in PVMetro.exe: 0xC0000005: Access violation reading location 0x00000000.

    Stack Trace:

    >	Windows.UI.Xaml.dll!5898109e() 	
     	[Frames below may be incorrect and/or missing, no symbols loaded for Windows.UI.Xaml.dll]	
     	Windows.UI.Xaml.dll!58981069() 	
     	Windows.UI.Xaml.dll!589e41a2() 	
     	Windows.UI.Xaml.dll!589e4089() 	
     	Windows.UI.Xaml.dll!589dd6b4() 	
     	Windows.UI.Xaml.dll!589dd54f() 	
     	Windows.UI.Xaml.dll!587ff904() 	
     	Windows.UI.Xaml.dll!587ffcfd() 	
     	Windows.UI.Xaml.dll!587ff80c() 	
     	Windows.UI.Xaml.dll!587ff2bf() 	
     	Windows.UI.Xaml.dll!587db3f8() 	
     	Windows.UI.Xaml.dll!587db3af() 	
     	user32.dll!753f77d8() 	
     	user32.dll!753f90e7() 	
     	user32.dll!753f787a() 	
     	user32.dll!753f899d() 	
     	user32.dll!753f8a66() 	
     	Windows.UI.dll!5b5b11dc() 	
     	Windows.UI.dll!5b5b1290() 	
     	Windows.UI.Xaml.dll!588ddee2() 	
     	Windows.UI.Xaml.dll!588ddea1() 	
     	Windows.UI.Xaml.dll!588dde65() 	
     	ntdll.dll!76f301a0() 	
     	twinapi.dll!6221c9dd() 	
     	twinapi.dll!6221cab2() 	
     	twinapi.dll!6221c9f6() 	
     	SHCore.dll!742f1ffd() 	
     	kernel32.dll!76c88543() 	
     	ntdll.dll!76f3ac69() 	
     	ntdll.dll!76f3ac3c() 

    Thanks


    • Edited by Siddarth23 Wednesday, September 26, 2012 6:15 PM put stack trace in code block
    Wednesday, September 26, 2012 6:13 PM

Answers

  • Sorry for the slow response Siddarth.  I have now had time to dig into your dmp file and have determined this is a known issue.  Unfortunately it was caught too late in the development cycle to be part of the patches available this Friday (10/26).  Basically the bug occurs when a ScrollViewer is leaving the tree while a touch manipulation is still in progress and is about to complete. Code that executes when the ScrollViewer's viewport is removed from the tree is delayed until the manipulation is complete (i.e. until the UI (main application) thread has a chance to post a command to the compositor thread telling that the viewport is disappearing).   The bug generally occurs if the ScrollViewer (or its content) reenters the tree before that previous manipulation had a chance to complete, making the old viewport (which is about to be unregistered) and the newly created one will momentarily point to the same ScrollViewer.Content.

    This bug will definitely be fixed in a future patch but I cannot give better specifics about when.  Thus, it's probably best to try to work around the issue, specifically taking steps to avoid removing and re-adding objects containing ScrollViewers from your visual tree in a short period of time.  Some suggested workarounds include:

    - Delay a bit before performing any action that could re-parent a control with a ScrollViewer
    - If not possible, use new objects in Drag/Drop code to prevent two objects with the same content via cloning

    If you can provide a simple repro project that hits your problem (by default a simple GridView won't hit this) I'll be glad to help provide workarounds. 

    Hope this helps,

    Matt

     


    XAML SDET Lead : Input / DirectManipulation / Accessibility



    Monday, October 22, 2012 4:32 PM
  • I also ended up with a repro myself.  I have one more thing you can try, that I am more certain helps.

    Starting with your repro project, just make the following change in TableControl.xaml, line 74:

     

                                            <ScrollViewer x:Name="ScrollViewer" HorizontalScrollMode="{TemplateBinding ScrollViewer.HorizontalScrollMode}" HorizontalScrollBarVisibility="{TemplateBinding ScrollViewer.HorizontalScrollBarVisibility}" IsHorizontalRailEnabled="{TemplateBinding ScrollViewer.IsHorizontalRailEnabled}" IsVerticalRailEnabled="{TemplateBinding ScrollViewer.IsVerticalRailEnabled}" Padding="{TemplateBinding Padding}" TabNavigation="{TemplateBinding TabNavigation}" VerticalScrollBarVisibility="{TemplateBinding ScrollViewer.VerticalScrollBarVisibility}" VerticalScrollMode="{TemplateBinding ScrollViewer.VerticalScrollMode}" ZoomMode="{TemplateBinding ScrollViewer.ZoomMode}">
                                                <ItemsPresenter ManipulationMode="None"/>
                                            </ScrollViewer> 

    ... this way the DirectManipulation service is not used on this ScrollViewer, and you can drag/drop it to your heart's content.  I can't get a repro with this setup.

    Please try this and let me know,

    Matt

    Wednesday, November 21, 2012 6:12 PM

All replies

  • I did some more digging and was able to narrow down the problem to a ListBox within the UserControl. Basically, I removed/commented out all the other XAML code and the code behind within the UserControl. Then, I just tried to reproduce the crash and it still happened. If I remove the ListBox, then the crash no longer happens. The same thing happens when I replace the ListBox with a ListView.

    So, right now the only conclusion I can draw is that this crash is not caused by any of my code (i.e. user code). Any suggestions/comments?

    • Edited by Siddarth23 Friday, September 28, 2012 5:15 PM
    Wednesday, September 26, 2012 9:12 PM
  • I have a similar issue and I'm trying to figure it out by elimination too since it seems pretty random but stumbled upon this:

    http://stackoverflow.com/questions/11880611/win8-unhandled-exception-in-windows-ui-xaml-dll

    Don't know how helpful it is in your case

    Thursday, October 18, 2012 2:58 AM
  • xsterx's advice may help, but can you provide a dump file or repro application to investigate this with please?

    XAML SDET Lead : Input / DirectManipulation / Accessibility

    Thursday, October 18, 2012 6:21 PM
  • @Matt, as requested, here is the dump file: https://skydrive.live.com/redir?resid=DF54024697E8E5CA!530&authkey=!AJpqHGdtkjlF7po

    @xsterx, thanks for the link. The first answer on that link suggests that the error could be happening due to the passing of objects during navigation that implement INotifyPropertyChange. We do have an object that implements INotifyPropertyChanged, which then binds to the ListBox but we never pass it during navigation. We only pass primitive types during navigation.

    Thursday, October 18, 2012 7:49 PM
  • You can also open a support case with us and we will look at this problem.  You get two free support incidents with your Store account.

    http://aka.ms/StoreSupport


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Friday, October 19, 2012 7:08 PM
    Moderator
  • Sorry for the slow response Siddarth.  I have now had time to dig into your dmp file and have determined this is a known issue.  Unfortunately it was caught too late in the development cycle to be part of the patches available this Friday (10/26).  Basically the bug occurs when a ScrollViewer is leaving the tree while a touch manipulation is still in progress and is about to complete. Code that executes when the ScrollViewer's viewport is removed from the tree is delayed until the manipulation is complete (i.e. until the UI (main application) thread has a chance to post a command to the compositor thread telling that the viewport is disappearing).   The bug generally occurs if the ScrollViewer (or its content) reenters the tree before that previous manipulation had a chance to complete, making the old viewport (which is about to be unregistered) and the newly created one will momentarily point to the same ScrollViewer.Content.

    This bug will definitely be fixed in a future patch but I cannot give better specifics about when.  Thus, it's probably best to try to work around the issue, specifically taking steps to avoid removing and re-adding objects containing ScrollViewers from your visual tree in a short period of time.  Some suggested workarounds include:

    - Delay a bit before performing any action that could re-parent a control with a ScrollViewer
    - If not possible, use new objects in Drag/Drop code to prevent two objects with the same content via cloning

    If you can provide a simple repro project that hits your problem (by default a simple GridView won't hit this) I'll be glad to help provide workarounds. 

    Hope this helps,

    Matt

     


    XAML SDET Lead : Input / DirectManipulation / Accessibility



    Monday, October 22, 2012 4:32 PM
  • Thanks for your help Matt.

    I added a delay via the following:

    System.Threading.ManualResetEvent(false).WaitOne(1000);

    and it fixes the issue most of the time. However, if I continuously try to drag and drop items, eventually the issue occurs. So unfortunately, this solution is not full proof. Also, this method blocks the UI thread which degrades user experience.

    I haven't tried cloning the object yet as that is a longer undertaking so I can't say how well that will work.

    I understand that you cannot say when this bug will be fixed. But, when it eventually does get fixed, how can I found out so that I can remove any temporary work around that was added?


    • Edited by Siddarth23 Wednesday, October 24, 2012 8:48 PM spacing
    Wednesday, October 24, 2012 8:47 PM
  • I honestly don't know, I have reached out to the team which produces patches and will let you know if I learn more.

    The good news is hard-coded sleeps are not the only solution.  What I'd suggest here is to produce a repro application that hits your problem as similar to your real application as possible and share it here.  I'll try to correct the problem without adding sleeps and suggest fixes.

    -Matt


    XAML SDET Lead : Input / DirectManipulation / Accessibility

    Wednesday, October 24, 2012 9:11 PM
  • https://skydrive.live.com/redir?resid=DF54024697E8E5CA!662&authkey=!ABfroAfM3awNp74

    @Matt, I've created a simple project (see the above link) that replicates the issue. I've tried to keep the app quite simple while trying to follow what I did in my application. Obviously, the original application is more complicated but this little sample recreates the scenario pretty well.

    To replicate the issue just perform a drag and drop in touch mode and then attempt to click/press on the moved ListBox. You may have to try it a few times but eventually the app will crash.

    Your insight and recommendations on potential fixes are greatly appreciated. Thank you.

    Thursday, October 25, 2012 4:50 PM
  • @Siddarth23 I have the same problem.

    I'm using a GridView as a ContentControl DataTemplate is where various controls are loaded bound. This works great up to a specific point in time, I get an access violation. one has an idea on what could be wrong?

    Tuesday, November 6, 2012 4:10 PM
  • You replied the day I went on vacation, but I'll see if I can tease out a solution now :)


    XAML SDET Lead : Input / DirectManipulation / Accessibility

    Tuesday, November 6, 2012 11:56 PM
  • (EDIT: See later post.  This approach works but you must set it on the ScrollViewer's Content, NOT the ScrollViewer)

    https://skydrive.live.com/redir?resid=7C3D21FCF89964FA!1105&authkey=!ABtEiY-XUcZsXzM

    I think I've got it.  You're not actually the one bringing these ScrollViewers in and out of the tree rapidly, but you have two of them.   The fix is two-fold, and rather hacky (I'd like to go home) but it's a decent proof of concept.  In short you need to do two things:

    1) Set Manipulation Mode to != System for ALL ScrollViewers in your Table control.  This means the TextBox and and the ListView elements.  You can do this using styles, or by walking the visual tree, finding SCrollViewers, and making the setting.  I did both... ListView using Style, then both ListView AND TextBOx using a visual tree traversal.

                Queue<DependencyObject> hackyTreeWalk = new Queue<DependencyObject>();
                hackyTreeWalk.Enqueue(this);
                while (hackyTreeWalk.Count > 0)
                {
                    DependencyObject foo = hackyTreeWalk.Dequeue();
                    if (foo.GetType() == typeof(ScrollViewer))
                    {
                        ((ScrollViewer)foo).ManipulationMode = ManipulationModes.None;
                    }
                    for (int i = 0; i < VisualTreeHelper.GetChildrenCount(foo); i++)
                    {
                        hackyTreeWalk.Enqueue(VisualTreeHelper.GetChild(foo, i));
                    }
                }

    2) Since you've done #1, you need to also manually handle scroll wheel events, which I've also done in the sample above.

    // ... 
                // Setting ManipulationMode off from System will break pointer scrolling.  Plumb it back manually
                ((ScrollViewer)sender).AddHandler(UIElement.PointerWheelChangedEvent, new PointerEventHandler(ScrollViewer_PointerWheelChanged_1), true);
    
    // ... 
    
    
                PointerPoint pt = e.GetCurrentPoint(sender as FrameworkElement);
                int delta = pt.Properties.MouseWheelDelta;
                ((ScrollViewer)sender).ScrollToVerticalOffset(((ScrollViewer)sender).VerticalOffset - delta);
            }

    Hope this helps.  I've also followed up with the folks who make patches and filed a task on them to produce this but I still have no idea when this will take place.

    -Matt


    XAML SDET Lead : Input / DirectManipulation / Accessibility



    Wednesday, November 7, 2012 1:55 AM
  • @Matt, thanks for looking into this. So, I downloaded and loaded up the project your provided. Unfortunately, I can still get it to crash if I perform enough drag and drop operations. The good news is that it takes about 6-10 continuous drag and drop + touch interactions to produce a crash while before your change it only took one or two interactions.

    So, this fix is not ideal and quite "hacky" but it improves the odds that the crash will not happen, which makes it the best solution for now. Hopefully, you guys patch this soon and solve this issue once and for all.

    Friday, November 9, 2012 8:59 PM
  • I also ended up with a repro myself.  I have one more thing you can try, that I am more certain helps.

    Starting with your repro project, just make the following change in TableControl.xaml, line 74:

     

                                            <ScrollViewer x:Name="ScrollViewer" HorizontalScrollMode="{TemplateBinding ScrollViewer.HorizontalScrollMode}" HorizontalScrollBarVisibility="{TemplateBinding ScrollViewer.HorizontalScrollBarVisibility}" IsHorizontalRailEnabled="{TemplateBinding ScrollViewer.IsHorizontalRailEnabled}" IsVerticalRailEnabled="{TemplateBinding ScrollViewer.IsVerticalRailEnabled}" Padding="{TemplateBinding Padding}" TabNavigation="{TemplateBinding TabNavigation}" VerticalScrollBarVisibility="{TemplateBinding ScrollViewer.VerticalScrollBarVisibility}" VerticalScrollMode="{TemplateBinding ScrollViewer.VerticalScrollMode}" ZoomMode="{TemplateBinding ScrollViewer.ZoomMode}">
                                                <ItemsPresenter ManipulationMode="None"/>
                                            </ScrollViewer> 

    ... this way the DirectManipulation service is not used on this ScrollViewer, and you can drag/drop it to your heart's content.  I can't get a repro with this setup.

    Please try this and let me know,

    Matt

    Wednesday, November 21, 2012 6:12 PM
  • Hi Matt,

    This change seems to work. I haven't been able to reproduce the problem after making your proposed change. Thanks for all your help. I will mark your last post as the answer.

    Sid

    Monday, November 26, 2012 3:34 PM