App Crashes on 32-bit Windows upon startup

[jbsupport]

We use castlabs-electron release(v14.2.3-wvvmp) in order to build a Widevine supported Desktop player. The setup files are generated for Windows 64-bit and 32-bit versions.

We use Shaka player with Widevine in order to play MPEG-DASH files.

The 64-bit versions work without fail. The 32-bit version works when it is installed on a 64-bit system but crashes a few seconds after starting on 32-bit systems. Our target OS is Windows 7 Professional 32-bit.

We have spent the past two days working on this and are no closer to the solution.

Any help would be appreciated. If you need further info on this, please let me know

[khwaaj]

As you are probably aware the ECS 14 is outside of the supported window, so you should consider updating. Unfortunately I don't have a 32-bit Windows machine readily available for reproduction either. However, a couple of things to try:

1. Update to v14.2.9-wvvmp, as it is the latest/final release for that series.
2. To determine if this is related to the Widevine installation/registration, did you try passing --no-verify-widevine-cdm on startup? If so, does the crash still happen?

[jbsupport]

Thank you for your suggestions.

Did try out your solutions but I took a crash dump after and realized that the issue lay in the "system_media_controls" which caused a "FAILURE_BUCKET_ID: NULL_CLASS_PTR_READ_c0000005_jookebox.exe!Unknown". Essentially, the app crashes when the HTML video element calls "play()".

I found a related issue on the Electron repository https://github.com/electron/electron/issues/32120 which fixed the issue.

Could you take a look and let me know if the Castlabs-Electron repo has this particular fix? If not, is there anything I could do for a workaround.

[khwaaj]

All our releases are based on the corresponding mainline Electron release, so yes, the fix will be there in the same version of ECS as it was incorporated in mainline.

In this case it seems it was fixed for v14.2.4 (for that release series). The other alternative seems to be downgrading to v14.2.0, where the flaw was not present. But if you tried my suggestions above you should already be on v14.2.9, right? And that release would contain this fix...