Validate VS Debugger UX for WinRT using CsWinRT generated source

[AaronRobinsonMSFT]

Debugging UX checklist:

• [ ] viewing properties in the Locals/Auto/Watch windows for RCW WinRT components.
• [ ] viewing properties in the Locals/Auto/Watch window for objects that previously were managed WinRT objects and now are something else.
• [ ] showing an exception for WinRT APIs that failed and provided IRestrictedErrorInfo.
• [ ] post-mortem crash viewing for failures that created a stowed exception.

[tommcdon]

@noahfalk @gregg-miskelly @jkoritzinsky @AaronRobinsonMSFT
Couple other suggestions to add to the check list:

1. mixed mode debugging testing with stepping from managed to native, and native to managed. If "Just My Code" is enabled, we should not step through the wrapper code. If JMC is disabled, it might be useful to be able to debug the wrapper code in case there is a bug in the CS code gen.
2. If "Just My Code" is enabled, the callstack should hide the wrapper code frames.

[Scottj1s]

Also to add:

There are a handful of COM/WinRTs-specific Managed Debugging Assistants that would be nice to preserve somehow:

• ExceptionSwallowedOnCallFromCom
• FailedQI
• InvalidApartmentStateChange
• MarshalCleanupError
• NonComVisibleBaseClass
• NotMarshalable
• RaceOnRCWCleanup
• ReportAvOnComRelease

[jkoritzinsky]

Managed Debugging Assistants aren't supported on .NET Core or .NET 5. They're a .NET Framework feature only.

[jkoritzinsky]

Ok so I took more of a look at the unhandled error path. It looks like the change in behavior that users will see is a task that throws an exception will, instead of calling RoReportUnhandledError, throw the exception on the thread pool. This is the current off-Windows behavior. Because of where this check is in System.Private.CoreLib, there's not a good place to insert a replacement from the C#/WinRT end.

We should definitely add a public static method on ExceptionHelpers to allow users to call RoReportUnhandledError though since that used to be exposed via WindowsRuntimeMarshal.

[jkoritzinsky]

Additionally, it looks like the actual call to RoReportUnhandledError was only done within the UAP app model.

[AaronRobinsonMSFT]

We should definitely add a public static method on ExceptionHelpers to allow users to call RoReportUnhandledError though since that used to be exposed via WindowsRuntimeMarshal.

@jkoritzinsky I was reading this issues as something that we need to add to the .NET API surface, did I misread that?

[jkoritzinsky]

We should definitely add a public static method on ExceptionHelpers to allow users to call RoReportUnhandledError though since that used to be exposed via WindowsRuntimeMarshal.

@jkoritzinsky I was reading this issues as something that we need to add to the .NET API surface, did I misread that?

The API was added to WinRT.Runtime in #247. No work for that is needed in dotnet/runtime.

[jkoritzinsky]

@tommcdon @AaronRobinsonMSFT I think for the stowed exception debugging support to work as expected, we'll have to enlighten the DAC about ComWrappers-based CCWs. I'll open an issue on dotnet/runtime.

[tommcdon]

FYI @caslan

[BenJKuhn]

We believe most of these issues, if not all, have been addressed since this issue was filed. Closing this issue. Please create new (separate) issues for any lingering concerns.