Hello @Leon Xu ,
I would not read this stack as WinRT “throwing more exceptions” by itself. You should check which HRESULT is being thrown. Right now the stack only shows where the failure surfaced, not why the API failed.
From the stack, the only meaningful line is:
DeviceAccessInformation::CreateFromDeviceClass(...)
The rest are just the internal mechanics of how the exception is propagated through the layers.
Since the machine is running on Windows 10.0.16299, which is quite old, it might be failing because of a mismatch between the SDK 10.0.26100.0 used to build the app and the Windows version it’s running on.
Although it doesn't automatically mean the SDK is the cause, but it makes me want to verify runtime compatibility and the exact device class being passed. A newer SDK can expose APIs and behavior that still need to be handled correctly on older Windows builds.
I would wrap this call and log the HRESULT:
try
{
auto info =
winrt::Windows::Devices::Enumeration::DeviceAccessInformation::CreateFromDeviceClass(deviceClass);
// continue using info
}
catch (winrt::hresult_error const& ex)
{
auto hr = ex.code();
auto message = ex.message();
// log hr and message here
}
If this is running during app startup or window creation, I would also avoid letting this exception escape the constructor. Treat it as a permission/device-access initialization failure and fall back to an unknown or unavailable state instead of crashing the process.
I hope this helps you identify the root cause of the exception. If you found this informative, please consider leaving a feedback through this guide.
Thank you.