Question

编辑9月26日

请参阅下文了解完整背景信息。 tl; dr：数据网格控件导致奇怪的异常，我正在寻找帮助隔离原因并找到解决方案。

我把它缩小了一点。我已经能够在较小的测试应用程序中重现行为，并且可以更可靠地触发不稳定的行为。

我绝对可以排除线程和（我认为）内存问题。新的应用程序不使用任务或其他线程/异步功能，我可以简单地通过向DataGrid中显示的对象类添加返回常量的属性来触发未处理的异常。这向我表明，问题在于无人管理的资源枯竭或者我还没想过的事情。

修订后的计划结构如下。我创建了一个名为EntityCollectionGridView的用户控件，它有一个标签和一个数据网格。在控件的Loaded事件处理程序中，我将List<TestClass>分配给具有1000或10000行的数据网格，让网格生成列。这个用户控件在页面的OnNavigatedTo事件（或Loaded中的MainPage.xaml中实例化2-4次，它似乎并不重要）。如果发生异常，则会在显示MainPage后立即发生。

有趣的是，行为似乎不会随着显示的行数而变化（它可以在10000行中可靠地工作，或者在每个网格中只有1000行可靠地失败），而是总数为在给定时间加载的所有网格中的列。有20个属性显示，4个网格工作正常。有35个属性和4个网格，抛出异常。但是如果我删除了两个网格，那么具有35个属性的同一个类就可以正常工作。

请注意，我添加到TestClass以从20列跳转到35列的所有属性都具有以下形式：

public string StringXYZ { get { return "asdfasdfasdfasdfasf"; } }

因此，后备数据中没有额外的内存（同样，我也不认为内存压力是问题所在。）

你们都在想什么？同样，任务管理器中的句柄/用户对象/等看起来不错，但还有其他我可能会丢失的东西吗？

原帖

我一直在使用Silverlight Toolkit DataGrid到WinRT的端口，它在简单测试（各种配置和最多10000行）中做得很好。但是，由于我试图将其嵌入到另一个WinRT应用程序中，我遇到了一个零星的异常（类型为System.Exception，在App.UnhandledException处理程序中引发），这很难调试。

Not enough quota is available to process this command. (Exception from HRESULT: 0x80070718)

错误始终可以重复，但不是确定性的。也就是说，我可以在每次运行应用程序时实现它，但它并不总是通过执行相同次数的相同精确步骤来实现。错误似乎发生在页面转换（无论是向前导航到新页面还是返回到上一页），而不是（例如）更改数据网格的ItemsSource时。

应用程序结构基本上是通过层次结构的递归访问，每个层次结构级别都显示一个页面。在层次结构中当前节点的页面上，显示了每个子节点和一些孙子节点，并且对于任何子节点，可以显示数据网格。在实践中，我一直使用以下导航结构重现这一点：

Root page: shows no datagrid
  Child page: shows one datagrid and a few listviews
    Grandchild page: shows two datagrids, one bound to the
                     same source as Child page, the other one empty

典型的测试场景是，从Root开始，移动到Child，移动到Grandchild，移回Child，然后当我再次尝试导航到Grandchild时，它失败，除了我上面提到的异常。但是我第一次遇到孙子时可能会失败，或者它可能让我在失败之前来回移动几次。

调用堆栈上只有一个托管框架，它是未处理的异常事件处理程序。这是非常无益的。切换到混合模式调试，我得到以下结果：

WinRTClient.exe!WinRTClient.App.InitializeComponent.AnonymousMethod__14(object sender, Windows.UI.Xaml.UnhandledExceptionEventArgs e) Line 50 + 0x20 bytes  C#
[Native to Managed Transition]  
Windows.UI.Xaml.dll!DirectUI::CFTMEventSource<Windows::UI::Xaml::IUnhandledExceptionEventHandler,Windows::UI::Xaml::IApplication,Windows::UI::Xaml::IUnhandledExceptionEventArgs>::Raise(Windows::UI::Xaml::IApplication * pSource, Windows::UI::Xaml::IUnhandledExceptionEventArgs * pArgs)  Line 327  C++
Windows.UI.Xaml.dll!DirectUI::Application::RaiseUnhandledExceptionEventHelper(long hrEncountered, unsigned short * pszErrorMessage, unsigned int * pfIsHandled)  Line 920 + 0xa bytes   C++
Windows.UI.Xaml.dll!DirectUI::ErrorHelper::CallAUHandler(unsigned int errorCode, unsigned int * pfIsHandled, wchar_t * * pbstrErrorMessage)  Line 39 + 0x14 bytes   C++
Windows.UI.Xaml.dll!DirectUI::ErrorHelper::ProcessUnhandledErrorForUserCode(long error)  Line 82 + 0x10 bytes   C++
Windows.UI.Xaml.dll!AgCoreCallbacks::CallAUHandler(unsigned int errorCode)  Line 1104 + 0x8 bytes   C++
Windows.UI.Xaml.dll!CCoreServices::ReportUnhandledError(long errorXR)  Line 6582    C++
Windows.UI.Xaml.dll!CXcpDispatcher::Tick()  Line 1126 + 0xb bytes   C++
Windows.UI.Xaml.dll!CXcpDispatcher::OnReentrancyProtectedWindowMessage(HWND__ * hwnd, unsigned int msg, unsigned int wParam, long lParam)  Line 653 C++
Windows.UI.Xaml.dll!CXcpDispatcher::WindowProc(HWND__ * hwnd, unsigned int msg, unsigned int wParam, long lParam)  Line 401 + 0x24 bytes    C++
user32.dll!_InternalCallWinProc@20()  + 0x23 bytes  
user32.dll!_UserCallWinProcCheckWow@36()  + 0xbd bytes  
user32.dll!_DispatchMessageWorker@8()  + 0xf8 bytes 
user32.dll!_DispatchMessageW@4()  + 0x10 bytes  
Windows.UI.dll!Windows::UI::Core::CDispatcher::ProcessMessage(int bDrainQueue, int * pbAnyMessages)  Line 121   C++
Windows.UI.dll!Windows::UI::Core::CDispatcher::ProcessEvents(Windows::UI::Core::CoreProcessEventsOption options)  Line 184 + 0x10 bytes C++
Windows.UI.Xaml.dll!CJupiterWindow::RunCoreWindowMessageLoop()  Line 416 + 0xb bytes    C++
Windows.UI.Xaml.dll!CJupiterControl::RunMessageLoop()  Line 714 + 0x5 bytes C++
Windows.UI.Xaml.dll!DirectUI::DXamlCore::RunMessageLoop()  Line 2539 + 0x5 bytes    C++
Windows.UI.Xaml.dll!DirectUI::FrameworkView::Run()  Line 91 C++
twinapi.dll!`Windows::ApplicationModel::Core::CoreApplicationViewAgileContainer::RuntimeClassInitialize'::`55'::<lambda_A2234BA2CCD64E2C>::operator()(void * pv)  Line 560  C++
twinapi.dll!`Windows::ApplicationModel::Core::CoreApplicationViewAgileContainer::RuntimeClassInitialize'::`55'::<lambda_A2234BA2CCD64E2C>::<helper_func>(void * pv)  Line 613 + 0xe bytes   C++
SHCore.dll!_SHWaitForThreadWithWakeMask@12()  + 0xceab bytes    
kernel32.dll!@BaseThreadInitThunk@12()  + 0xe bytes 
ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes   
ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

这向我表明，无论我做错什么都不会在应用程序的消息循环中至少一个周期之后注册（我还尝试使用＆＃打破所有抛出的异常） 34;调试|异常......＆＃34; - 据我所知，没有任何东西被抛出和吞没）。我看到的有趣堆栈帧是WindowProc，OnReentrancyProtectedWindowMessage和Tick。 msg是0x402（1026），这对我来说并不意味着什么。 This page列出了以下上下文中使用的消息：

CBEM_SETIMAGELIST 
DDM_CLOSE 
DM_REPOSITION 
HKM_GETHOTKEY 
PBM_SETPOS 
RB_DELETEBAND 
SB_GETTEXTA 
TB_CHECKBUTTON 
TBM_GETRANGEMAX 
WM_PSD_MINMARGINRECT

......但这对我来说意义不大（它甚至可能都不相关）。

我能提出的三个理论是：

内存压力。但是我遇到了这个问题，24％的物理内存空闲，应用程序消耗的内存不到100MB。其他时候，该应用程序不会遇到任何问题导致一段时间导航并占用400MB内存
线程问题，，例如从工作线程访问UI线程。事实上，我确实在后台线程上进行了数据访问。但这是使用在WinForms环境和Outlook插件中非常可靠的（移植）框架，我认为线程使用是安全的。另外，我可以在这个应用程序中使用相同的数据，而不会仅仅绑定到ListViews等问题。最后，配置孙子节点，使得在第一个数据网格中选择一行开始对行的详细项目的请求，该请求显示在第二个数据网格中（最初是空的，并且可以保持不变，而不会阻止例外）。这种情况在没有页面过渡的情况下发生，并且只要我选择摆弄选择就可以完美地工作。但导航回Child可能会立即杀死我，即使此时应该没有数据访问权限，因此也不会进行我所知道的操作。
某种资源耗尽，也许是GUI处理。但我不认为我对这个系统施加了太大的压力。在一次执行中，打破异常处理程序，任务管理器使用662个句柄，21个用户对象和12个GDI对象报告该进程，而Tweetro则分别使用734,37和19而没有问题。我可以在这个类别中缺少什么？

我有足够的磁盘空间，并且除了配置文件以外我没有使用磁盘（并且在添加datagrids之前一切正常）。

我的下一个想法是尝试逐步完成一些有趣的＆＃39;有趣的＆＃39;数据网格代码的一部分，并跳过任何有问题的。我确实尝试过使用datagrid的ArrangeOverride，但异常并不关心我是否这样做。此外，我不确定这是一个有用的策略。由于在消息循环中循环之后才会抛出异常，并且因为我无法确定它何时会发生，所以我需要覆盖大量的排列，运行每个排列很多次，以隔离问题代码。

调试和释放模式都会引发错误。而且，作为最后的背景说明，我们在这里处理的数据量很小，远远小于我隔离的10000行数据网格。它可能大约50-100行，可能有30-40列。在抛出异常之前，数据和网格似乎都能正常工作并且响应很好。

所以，这就是我来找你的原因。我的两个问题是：

错误信息是否会为您提供有关可能出现问题的任何提示？
您将使用什么调试策略来隔离问题代码？

非常感谢您提供的任何帮助！

Answer 1

好的，有一些critical input from Tim Heuer [MSFT]，我知道发生了什么以及如何解决这个问题。

令人惊讶的是，我的三个初步猜测中没有一个是正确的。这与内存，线程或系统资源无关。相反，它是关于Windows消息传递系统的限制。显然它有点像堆栈溢出异常，因为当你同时对可视化树进行太多的更改时，异步更新队列会变得很长，以至于它会使一条线路跳闸并抛出异常。

在这种情况下，问题是有足够的UIElements进入我正在使用的数据网格中，允许网格一次性生成所有自己的列，在某些情况下可能会超出限制。我一次使用了多个网格，并且所有加载都是为了响应页面导航事件，这使得它更加难以确定。

值得庆幸的是，我遇到的限制不是视觉树或XAML UI子系统本身的限制，只是在用于更新它的消息中。这意味着如果我可以在调度员时钟的多个滴答中分散相同的操作，我可以完成相同的最终结果。

我最终做的是指示我的数据网格不自动生成自己的列。相反，我将网格嵌入到用户控件中，当加载数据时，该控件将解析所需的列并将其加载到列表中。然后，我调用了以下方法：

void LoadNextColumns(List<ColumnDisplaySetup> colDef, int startIdx, int numToLoad)
{
    for (int idx = startIdx; idx < startIdx + numToLoad && idx < colDef.Count; idx++)
    {
        DataGridTextColumn newCol = new DataGridTextColumn();
        newCol.Header = colDef[idx].Header;
        newCol.Binding = new Binding() { Path = new PropertyPath(colDef[idx].Property) };
        dgMainGrid.Columns.Add(newCol);
    }

    if (startIdx + numToLoad < colDef.Count)
    {
        Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () =>
            {
                    LoadNextColumns(colDef, startIdx + numToLoad, numToLoad);
            });
    }
}

（ColumnDisplaySetup是一种简单的类型，用于存放已解析的配置或从文件加载的配置。）

使用以下参数分别调用此方法：列列表0和我任意猜测5作为一次加载的相当安全的列数;但这个数字是基于测试和期望可以同时加载大量网格。我向蒂姆询问了可能为这部分流程提供信息的更多信息，如果我了解更多关于如何安全的信息，我会在这里报告。

在实践中，这似乎可以正常工作，虽然它会导致你期望的渐进式渲染，列可见弹出。我希望这可以通过使用{{1的最大可能值来改善和其他用户界面的手法。我可能会在生成列时调查隐藏网格，并仅在所有内容都准备就绪时显示结果。最终，这个决定将归结为更加“快速和流畅”的决定。

如果我得到它，我会再次提供更多信息来更新这个答案，但我希望这可以帮助将来遇到类似问题的人。在倾注了更多的时间，而不是我愿意承认这个虫子，我不希望任何其他人为此而自杀。

Answer 2

在重新定位我的Windows 8.1应用程序后，似乎在Windows 8.1预览版中修复了此问题。我不能再通过将数千个视觉效果转储到屏幕上来重新创建此问题。

在DataGrid的WinRT端口中，神秘的“没有足够的配额可用于处理此命令”

2 个答案: