Call to native function crashes the application with no exception or error log

[dgellow]

Environment

Run the following in your terminal and copy the results here.

1. npx react-native --version: 5.0.1-alpha.2
2. npx react-native info:

info Fetching system and libraries information...
System:
    OS: Windows 10 10.0.21343
    CPU: (8) x64 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
    Memory: 7.38 GB / 15.92 GB
  Binaries:
    Node: 14.16.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.14.11 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK: Not Found
    Windows SDK:
      AllowDevelopmentWithoutDevLicense: Enabled
      AllowAllTrustedApps: Enabled
      Versions: 10.0.18362.0, 10.0.19041.0
  IDEs:
    Android Studio: Not Found
    Visual Studio: 16.9.31129.286 (Visual Studio Community 2019)
  Languages:
    Java: Not Found
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.1 => 17.0.1
    react-native: 0.64.0 => 0.64.0
    react-native-windows: ^0.64.0-0 => 0.64.2
  npmGlobalPackages:
    *react-native*: Not Found

Some Context

I'm experimenting with Native Modules and implemented a simple function that plays a sound by calling Windows.UI.Xaml.ElementSoundPlayer.Play().

You can see the complete project here: https://github.com/dgellow/rnw-crash-sample-1.

The module SoundPlayer is made of the C++ header, the C++ implementation, and the TypeScript wrapper.

Other calls to native modules work without problem (I used the FancyMath example from the documentation as an example of working native module).

Steps To Reproduce

1. git clone https://github.com/dgellow/rnw-crash-sample-1.git
2. cd rnw-crash-sample-1
3. yarn install
4. yarn windows
5. after the application started, click on a "play sound" button (see gif screencast below)
6. notice how the application crashes without stack trace or error log (it just exits directly)

Expected Results

I expected sound to be played. And in the case where something is wrong I expected an exception to be raised and displayed in the red LogBox, or an error log either in the attached browser or in metro.

Snack, code example, screenshot, or link to a repository:

[vmoroz]

@dgellow, what is the threading requirement for that API that must play sound? We execute all native module methods in a background thread where we execute the JavaScript code. In case if this API requires UI thread, we should use the ReactContext.UIDispatcher.Post method to schedule the work in UI thread. To access the ReactContext we use an Initialize method with the REACT_INIT attribute.

• An example how to get ReactContext: https://github.com/microsoft/react-native-windows/blob/master/packages/sample-apps/windows/SampleLibraryCPP/SampleModuleCPP.h
• The ReactContext definition: https://github.com/microsoft/react-native-windows/blob/master/vnext/Microsoft.ReactNative.Cxx/ReactContext.h
• Using UIDispatcher example: https://github.com/microsoft/react-native-windows/blob/master/vnext/Microsoft.ReactNative/Modules/ClipboardModule.cpp

[dgellow]

That's a good question. I would generally assume that playing sound doesn't have to be done on the UI thread and a background thread should be fine but given that ElementSoundPlayer is in the namespace Windows.UI.Xaml that may actually be a requirement? Honestly I'm not sure where to find that information, I checked various MSDN pages regarding UWP and WinUI documentation and did not find anything relevant.

I have a bit of time today, I will try to isolate the problem and experiment with REACT_INIT and ReactContext you mentioned.

[dgellow]

Sorry if I'm a bit verbose here, I'm still fairly new to the tooling, WinRT, and Windows development in general and find it useful to write down in details what I found.

Debugging the crash

So, I attached Visual Studio debugger to the process, then triggered the issue by clicking on one of the button of my example.

I can see that my call to winrt::ElementSoundPlayer::Play(sound) (see here) is the guilty line here as it resuts in an exception caught by winrt/base.h.

Looking at the call stack

Here is the relevant stack trace, as seen in Visual Studio.

ucrtbased.dll!01d1fe60()
ucrtbased.dll![Frames below may be incorrect and/or missing, no symbols loaded for ucrtbased.dll]
[External Code]
blablabla.exe!winrt::throw_hresult(const winrt::hresult result) Line 4837
	at C:\Users\Sam\Development\ElboraiSoftware\blablabla\windows\blablabla\Generated Files\winrt\base.h(4837)
blablabla.exe!winrt::check_hresult(const winrt::hresult result) Line 4964
	at C:\Users\Sam\Development\ElboraiSoftware\blablabla\windows\blablabla\Generated Files\winrt\base.h(4964)
blablabla.exe!winrt::impl::consume_Windows_UI_Xaml_IElementSoundPlayerStatics<winrt::Windows::UI::Xaml::IElementSoundPlayerStatics>::Play(const winrt::Windows::UI::Xaml::ElementSoundKind & sound) Line 1361
	at C:\Users\Sam\Development\ElboraiSoftware\blablabla\windows\blablabla\Generated Files\winrt\Windows.UI.Xaml.h(1361)
blablabla.exe!winrt::Windows::UI::Xaml::ElementSoundPlayer::Play::__l2::<lambda>(const winrt::Windows::UI::Xaml::IElementSoundPlayerStatics & f) Line 12381
	at C:\Users\Sam\Development\ElboraiSoftware\blablabla\windows\blablabla\Generated Files\winrt\Windows.UI.Xaml.h(12381)
blablabla.exe!winrt::impl::factory_cache_entry<winrt::Windows::UI::Xaml::ElementSoundPlayer,winrt::Windows::UI::Xaml::IElementSoundPlayerStatics>::call<void <lambda>(const winrt::Windows::UI::Xaml::IElementSoundPlayerStatics &) &>(winrt::Windows::UI::Xaml::ElementSoundPlayer::Play::__l2::void <lambda>(const winrt::Windows::UI::Xaml::IElementSoundPlayerStatics &) & callback) Line 6231
	at C:\Users\Sam\Development\ElboraiSoftware\blablabla\windows\blablabla\Generated Files\winrt\base.h(6231)
blablabla.exe!winrt::impl::call_factory<winrt::Windows::UI::Xaml::ElementSoundPlayer,winrt::Windows::UI::Xaml::IElementSoundPlayerStatics,void <lambda>(const winrt::Windows::UI::Xaml::IElementSoundPlayerStatics &)>(winrt::Windows::UI::Xaml::ElementSoundPlayer::Play::__l2::void <lambda>(const winrt::Windows::UI::Xaml::IElementSoundPlayerStatics &) && callback) Line 6254
	at C:\Users\Sam\Development\ElboraiSoftware\blablabla\windows\blablabla\Generated Files\winrt\base.h(6254)
blablabla.exe!winrt::Windows::UI::Xaml::ElementSoundPlayer::Play(const winrt::Windows::UI::Xaml::ElementSoundKind & sound) Line 12381
	at C:\Users\Sam\Development\ElboraiSoftware\blablabla\windows\blablabla\Generated Files\winrt\Windows.UI.Xaml.h(12381)
blablabla.exe!NativeModuleSample::SoundPlayer::Play(int effect) Line 19
	at C:\Users\Sam\Development\ElboraiSoftware\blablabla\windows\blablabla\SoundPlayer.cpp(19)

Going down the call chain, my call to winrt::ElementSoundPlayer::Play arrives here:

// winrt/Windows.UI.Xaml.h, line 12379
inline auto ElementSoundPlayer::Play(Windows::UI::Xaml::ElementSoundKind const& sound)
{
    impl::call_factory<ElementSoundPlayer, IElementSoundPlayerStatics>([&](IElementSoundPlayerStatics const& f) { return f.Play(sound); });
}

Eventually followed by this:

// winrt/Windows.UI.Xaml.h, line 1359
template <typename D> WINRT_IMPL_AUTO(void) consume_Windows_UI_Xaml_IElementSoundPlayerStatics<D>::Play(Windows::UI::Xaml::ElementSoundKind const& sound) const
{
    check_hresult(WINRT_IMPL_SHIM(Windows::UI::Xaml::IElementSoundPlayerStatics)->Play(static_cast<int32_t>(sound)));
}

The rest is the handling of the returned error via check_hresult (from winrt/base.h, starting at line 4958) then throw_hresult (also winrt/base.h, starting at line 4815):

Other crashing calls

The other functions for ElementSoundPlayer I can see from winrt/Windows.UI.Xaml.h are ElementSoundPlayer::Volume() and ElementSoundPlayer::State(). I tried to call both of them and they also result in a similar error error_not_implemented.

It might be that I am doing things completely wrong.

[asklar]

@dgellow that error code (-2147417842) represents 0x8001010E

RPC_E_WRONG_THREAD	The application called an interface that was marshalled for a different thread.

So indeed, this API has thread affinity and must be called from the UI thread, by using the UIDispatcher property as Vlad mentioned.

[vmoroz]

@dgellow, could you try changing your code as the following:

header file

REACT_MODULE(SoundPlayer)
struct SoundPlayer {
  REACT_INIT(Initialize)
  void Initialize(React::ReactContext const &reactContext) noexcept;

  REACT_METHOD(Play, L"play")
  void Play(int sound) noexcept;

 private:
  React::ReactContext m_reactContext;
};

.cpp file

void SoundPlayer::Initialize(React::ReactContext const &reactContext) noexcept {
  m_reactContext = reactContext;
}

void SoundPlayer::Play(int effect) noexcept {
  const auto min = static_cast<int>(winrt::ElementSoundKind::Focus);
  const auto max = static_cast<int>(winrt::ElementSoundKind::GoBack);

  if (effect >= min && effect <= max) {
    const auto sound = static_cast<winrt::ElementSoundKind>(effect);
    m_reactContext.UIDispatcher().Post([sound]() {
      winrt::ElementSoundPlayer::Play(sound);
    });
  }
}

I am adding accepting the reactContext and then calling the API in UI thread.

(Note that the ';' after the REACT_MODULE, REACT_INIT, and REACT_METHOD macros is optional - we were adding it in the past for better automated code formatting. If formatting works without them, then they can omitted.)

[dgellow]

@asklar I see, that makes perfect sense then! The exception being reported at the same line as the check for impl::error_not_implemented mislead me. Thanks for pointing that out and sharing the documentation link :)

@vmoroz Yes, that works great! Thank you very much, I can now play sound successfully 😊

Is there documentation regarding REACT_INIT and the ReactContext, or is it too early and I'm better to look at the actual implementation?

Happy Easter to both of you ✌️

---

I ended with the following code (just in case someone trying to use ElementSoundPlayer finds this issue)

Header (SoundPlayer.h)

#pragma once

#include "winrt/Windows.Media.Playback.h"
#include "winrt/Windows.Media.Core.h"
#include "NativeModules.h"

namespace winrt {
    using winrt::Windows::Media::Playback::MediaPlayer;
    using winrt::Windows::Media::Core::MediaSource;
}

namespace NativeModuleSample {
    REACT_MODULE(SoundPlayer)
    struct SoundPlayer {
        REACT_INIT(Initialize)
        void Initialize(React::ReactContext const &context) noexcept;

        REACT_METHOD(Play, L"play")
        void Play(int sound) noexcept;

    private:
        React::ReactContext _context;
    };
}

Implementation (SoundPlayer.cpp)

#include "pch.h"
#include "SoundPlayer.h"
#include "winrt/Windows.UI.Xaml.h"

namespace winrt {
	using namespace winrt::Windows::UI::Xaml;
}

namespace NativeModuleSample {
	void SoundPlayer::Initialize(React::ReactContext const& context) noexcept {
		this->_context = context;
	}

	void SoundPlayer::Play(int effect) noexcept {
		const auto min = static_cast<int>(winrt::ElementSoundKind::Focus);
		const auto max = static_cast<int>(winrt::ElementSoundKind::GoBack);

		if (effect >= min && effect <= max) {
			const auto sound = static_cast<winrt::ElementSoundKind>(effect);
			this->_context.UIDispatcher().Post([sound]() {
				// enable sound, the default `Auto` mode, the default, didn't work for me
				winrt::ElementSoundPlayer::State(winrt::ElementSoundPlayerState::On);
				// play the sound
				winrt::ElementSoundPlayer::Play(sound);
			});
		}
	}
}

[dgellow]

@vmoroz It's a detail, but given that you mentioned it: at least in my case Visual Studio doesn't format my code correctly if I remove the ; after REACT_* macros.

Edit: oopsy, I didn't want to add a label "Needs Attention"...

[asklar]

We've had this issue open to tract the REACT_INIT and related macros: microsoft/react-native-windows-samples#254

For IReactContext docs, please see https://microsoft.github.io/react-native-windows/docs/IReactContext