stevewhims
commented
5 years ago Hi, Simon.
I can repro the crash (I updated Microsoft.Windows.CppWinRT to the latest version in order to get a build). Then, I updated the C# project to 17763, and that got me further in the debugger. But still, there seemed to be an issue with the code someplace. I see you're using one of the helper functions for collections. In this case, though, I tweaked your code to use the equivalent one of the base classes for collections. And I was able to bypass the issue of m_Impl being invalid. FYI, here's the class:
struct ThingCollection :
implements<ThingCollection, IVector<A::Thing>, IVectorView<A::Thing>, IIterable<A::Thing>>,
winrt::vector_base<ThingCollection, A::Thing>
{
ThingCollection()
{
m_values.push_back(winrt::make<A::implementation::Thing>());
}
auto& get_container() const noexcept
{
return m_values;
}
auto& get_container() noexcept
{
return m_values;
}
private:
std::vector<A::Thing> m_values{ winrt::make<A::implementation::Thing>(), winrt::make<A::implementation::Thing>() };
};The C# project is Output-ing the expected Size(). Since that sidesteps the immediate issue, you might want to just go that way.
Meanwhile, I'll let the product team know about this GitHub Issue in case they want to advise us and/or file a bug on the debugger. And, just FYI, customers always have these options: For issues, or suspected product bugs, there's Microsoft Support; a support engineer will look at the repro and see whether the issue is a product bug or something else. For Visual Studio issues, there's the Visual Studio User Voice feedback website, or the Developer Community. The Windows developer feedback site is the right place to file a product bug.
For problems/errors/omissions with the actual documentation, this is the right forum to raise those. Please let me know if there's anything that I can do to improve the documentation here. And thanks again for the feedback and your diligence in reporting these issues. :) ~Steve
sichbo
Scottj1s
I may doing something wrong here, but a basic custom collection returned by a WinRT component seems to crash the IDE debugger.
I've posted an MVCE here: https://github.com/sichbo/WinRTCollectionCrash
The gist of it is: Basic MIDL definition
In your
ThingCollectionimplementation, simply shim all of the interface methods into a backing:Breakpoint on something like
ThingCollection.Size()and have an external app consume the component. Hovering overm_Implor attempting to seethisin the watch window will hose the app and crash the debugging experience.My assumption of the WinRT wizardry is that everything should be kept alive until the client app destroys its projected instance? What we're seeing instead are symptoms of stack imbalance/memory corruption. Digging into the disassembly we can see "this" is wiped out with a debugger hint address 0xCCCCCCCC. Trying to disassemble further up the ABI chain inside of the
Size()method will crash the debugger.Interestingly, you can get slightly further along by changing that IVector backing instance to
const&like so:… with that, you at least get what looks like a sane "this" pointer.. but alas, expanding it then crashes not only the debugger, but the full Visual Studio IDE.
What gives?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.