[RS6] [UWP] Windows.UI.Xaml.dll中的未处理异常 [英] [RS6][UWP]Unhandled exception in Windows.UI.Xaml.dll

查看:72
本文介绍了[RS6] [UWP] Windows.UI.Xaml.dll中的未处理异常的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个很大的C ++ / winrt UWP项目,直到我今天尝试用更新版本替换大型资产(一本html书籍)之前一直工作得非常好。在做完之后,VS报告了很多与图片等有关的错误,这些错误都没有找到
,最后我用昨晚的备份替换了整个项目文件夹 - 工作版本。我还重新安装了VS Enterprise 2019 16.1.0 Preview 2.0, 使用VS Installer中的"修复"选项,然后重新启动Windows。现在程序
在到达自己的代码之前崩溃,"0x777EE170处的未处理异常(Windows.UI.Xaml.dll)。"

I have a large C++/winrt UWP project that was working beautifully until I tried today to replace a large asset - an html book - with an updated version. After doing that VS reported many errors relating to images, etc. in the book that were not being found, and eventually I replaced the entire project folder with a backup from last night - the working version. I also reinstalled VS Enterprise 2019 16.1.0 Preview 2.0,  using the Repair option in VS Installer, and restarted Windows. Now the program crashes before reaching its own code, with "Unhandled exception at 0x777EE170 (Windows.UI.Xaml.dll).

如果我尝试在没有调试器的情况下启动我获取"无法激活Windows应用商店应用...激活请求失败并显示错误"操作不受支持。未知错误0x80040904"

If I try launching without the debugger I get "Unable to activate Windows Store App...The activation request failed with error 'Operation not supported. Unknown error 0x80040904"

对我来说,神秘之处在于为什么昨天的项目文件夹不再有效,尽管它没有被修改。你能提供一些关于如何让它回到正轨的建议吗?

The mystery for me is why the project folder from yesterday no longer works, though it has not been altered. Can you offer suggestions on how to get this back on track?

[p.s。操作系统是Windows 10 Home,1903,Build 18356.1]也许它刚刚在昨晚更新了。

[p.s. the OS is Windows 10 Home, 1903, Build 18356.1] Perhaps it just updated itself last night.

[pps]:在进一步尝试从这个混乱中恢复的时候,我试着去NuGet经理和将C ++ / winrt更新为当前版本 - 它已经是1.0.181992.2。现在,构建尝试会产生新错误,

[p.p.s.]: In further attempts to recover from this mess I tried going to NuGet manager and updating C++/winrt to the current version - it had been 1.0.181992.2. Now a build attempt produces a new error,

  错误
C2259
 'winrt :: Practica_Musica :: implementation :: XamlMetaDataProvider':无法实例化抽象类(编译   源文件
App.cpp)
Practica Musica
C:\Program Files(x86)\ Mesrosoft Visual   Studio\2019\Preview\VC\Tools\MSVC\14.20.2 7607 \include \memory
1526

 Error C2259  'winrt::Practica_Musica::implementation::XamlMetaDataProvider': cannot instantiate abstract class (compiling source file App.cpp) Practica Musica C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\VC\Tools\MSVC\14.20.27607\include\memory 1526

我不介意修复我的代码中的错误,但是当出现其中一个错误时我会感到茫然在系统内。这可能是一个单独的问题,还是与上述问题有关?上面也与xaml有关。

I don't mind fixing bugs in my code, but I'm at a loss when one of these errors appears within the system. Could this be a separate issue, or related to the above? The above is also related to xaml.

[更多信息:]我看到如果我在App构造函数中设置了一个中断,那么在离开该方法时会出现崩溃:

[More info:] I see that if I set a break in the App constructor, the crash comes when leaving that method:

App :: App()

{

   InitializeComponent();

   暂停({this,& App :: OnSuspending});
$


#if定义_DEBUG&&!定义DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION

   UnhandledException([this](IInspectable const&,UnhandledExceptionEventArgs const& e)

   {

     if (IsDebuggerPresent())

     {

       auto errorMessage = e.Message() ; $
       __debugbreak();

    }

  });
$
#endif

} //进一步产生崩溃,0x5169E170处的未处理异常(Windows.UI.Xaml.dll)

App::App()
{
    InitializeComponent();
    Suspending({ this, &App::OnSuspending });

#if defined _DEBUG && !defined DISABLE_XAML_GENERATED_BREAK_ON_UNHANDLED_EXCEPTION
    UnhandledException([this](IInspectable const&, UnhandledExceptionEventArgs const& e)
    {
        if (IsDebuggerPresent())
        {
            auto errorMessage = e.Message();
            __debugbreak();
        }
    });
#endif
} //A further step produces the crash,Unhandled exception at 0x5169E170 (Windows.UI.Xaml.dll)

 显然问题在于InitializeComponent()。但这是默认的BlankApp附带的所有代码;不知道该怎么做。

 so apparently the problem lies in InitializeComponent(). But this is all code that came with the default BlankApp; not sure what to do with it.

[更多信息:]我发现2018年报道类似问题的人的帖子,并且已经证明他正在为TextBox分配一个属于TextBlock的样式。也就是说,糟糕的xaml代码。我的xaml都是程序化的,我假设
,如果我犯了这样的错误,Intellisense或编译器会抱怨。有没有系统的方法来搜索这样的错误?它们没有出现在运行代码分析中。我的理论是,这突然出现了,因为我在项目
上做了一个Clean,试图处理上面提到的资源问题,所以Clean可能暴露了旧代码被更新版本重新编译的错误VS.但我有数百个包含xaml元素声明的文件 - 你知道如何追踪
这样的东西吗? 

[Still more info:] I found a post from a guy reporting a similar problem in 2018, and it had turned out for him that he was assigning to a TextBox a style that belonged on a TextBlock. That is, bad xaml code. My xaml is all programmatic and I had assumed that Intellisense or the compiler would complain if I made such an error. Is there any systematic way to search for such mistakes? They aren't showing up from running code analysis. My theory is that this showed up suddenly because I did a Clean on the project in an attempt to deal with the resource issue mentioned above, so the Clean might have exposed an error in old code being recompiled by a newer version of VS. But I have hundreds of files containing xaml element declarations - do you know of a way to track down something like that? 

[update]例如,如果这是由某个坏的xaml对象引起的,是否有任何方法可以获得关于哪个对象导致问题的提示?

[update] For example, if this is caused by a bad xaml object somewhere, is there any way to get a hint about which object is causing the problem?

[update]我看到我在C ++ / winrt版本中输入了一个拼写错误上面 - 我已经回到那个版本,即1.0.181002.2,同时试图找到这个问题的根源。

[update] I see I put a typo in the C++/winrt version above - I have returned to that version, which is 1.0.181002.2, while trying to find the source of this problem.

推荐答案

所以根据你的说法,你的操作系统版本是RS6 build 1903.不确定这是否与新的操作系统版本有关,所以我会请团队检查您的问题。可能会有一些时间延迟。感谢您的耐心等待。

So based on your words, your OS version is RS6 build 1903. Not sure if this is related to the new OS build, so I'll ask the team to check your problem. There might be some time delay. Thank you for your patience.

致以最诚挚的问候,

Roy


这篇关于[RS6] [UWP] Windows.UI.Xaml.dll中的未处理异常的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆