A Renderer Process Crash Caused Storage Explorer to Stop Working Correctly

[bassem-mf]

Preflight Checklist

• I have installed the latest version of Storage Explorer.
• I have checked existing resources, including the troubleshooting guide and the release notes.
• I have searched for similar issues.

Storage Explorer Version

1.32.0

Regression From

1.31.2

Architecture

x64

Storage Explorer Build Number

20231101.3

Platform

Linux (tar.gz)

OS Version

Debian 12

Bug Description

Storage Explorer is able to to start and even load my storage accounts in the tree view on the left. But a few seconds after starting, I get a dialog with the following error message:

A renderer process crash caused Storage Explorer to stop working correctly.
Storage Explorer can try to restart the program. Reason: crashed. Code: 11

I start Storage Explorer from the terminal. So I can see this error message printed to the terminal.

[2023-11-08T18:43:03.725Z] (main:81601) <ERRO> Renderer process crashed, reason: crashed, exit code: 11

I went back to version 1.31.2 and installed it exactly the same way. And it works without problems.

Steps to Reproduce

1. On Debian 12, download Storage Explorer .tar.gz for version 1.32.0 and extract it.
2. Open a terminal. And make sure the PATH environment variable has the path to the dotnet directory.
3. Run StorageExplorerExe from the terminal. It should start. But after a few seconds, it crashes and gives the error message mentioned above.

Actual Experience

Storage Explorer crashes after a few seconds from starting it and gives this error message.

Expected Experience

No response

Additional Context

No response

[JasonYeMSFT]

@bassem-mf Since you are on Debian, would you be willing to try running Storage Explorer as a snap? You can try installing the snapcraft and see if it works for you. The snap installation is isolated from the .tar.gz you currently have. https://snapcraft.io/storage-explorer We only test our .tar.gz on Ubuntu and rely on snapcraft to support other Linux platforms.

Edit: By the way, I created a Debian 12 VM and installed our tar.gz in it. I was able to start the application, sign-in to my Azure account and view resources. Could you open ~/.config/StorageExplorer/appState.json, set "disableGpu" to true and see if it stops your renderer process from crashing?

[bassem-mf]

I installed the snap package and it is now working without problems. I wish I did not have to install Snap just for one application. But at least it works now. Thank you so much for your help!

I will let you decide on whether to close this issue or keep it open to investigate why the .tar.gz stopped working on Debian. I have been using it for about 6 months without problems.

[bassem-mf]

@JasonYeMSFT I tried setting "disableGpu" to "true". But it did not solve the issue. The application still crashes.

I noticed that the application runs without problems until I move the mouse, then it crashes. Feel free to ask me to do more tests.

[asinitson]

Have the same issue on openSUSE Leap 15.5. 100% reproducible with installation from *.tar:
https://download.microsoft.com/download/A/E/3/AE32C485-B62B-4437-92F7-8B6B2C48CB40/StorageExplorer-linux-x64.tar.gz

[asinitson]

Version 1.31.2 is running happily. So 100% same symptoms. I can also see it load initially and then crash after a few secconds.

[asinitson]

Also tried disableGpu flag: no difference.

[corstian]

Same problem on Arch using the 1.32.0 version. 1.31.2 works fine. The error code is slightly different though;

<ERRO> Renderer process crashed, reason: crashed, exit code: 139

Based on whether or not I'm using the disableGpu flag, or change OpenGL drivers I might or might not get the following additional warning after the error;

ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!

Behaviour does however remains as previously reported, regardless of which driver or disableGpu flag is used.

[JasonYeMSFT]

For all that encounters this issue, if your OS is supported by snap store, you can consider installing the snap version of Storage Explorer and keep using the snap in the future. It's more recommended and it will save your time maintaining application dependencies in the future. If your OS is not supported by snap store, you should revert to use 1.31.x for now.

There is an issue in Electron that seems to be related to what you are encountering. The thread contains an Electron fiddle sample that can help reproduce this issue. If possible, you can try it and share you findings here. That can help us determine what to do for this issue. comment giving Electron fiddle sample. We will upgrade the Electron we use in 1.33.x. If that's the root cause of this issue, this issue should be resolved then.

[JasonYeMSFT]

We produced a private build that upgrades to Electron 26.4.3, which hypothetically contains an upstream fix for the suspected root cause. Please try running this private tar.gz and see if it reproduces the issue. That will help us determine if we should upgrade Electron in 1.32.1.
https://storageexplorerpublish.blob.core.windows.net/privatebuilds/1.32.1-linux-renderer-crash/StorageExplorer-linux-x64-1.32.1-linux-renderer-crash.tar.gz

As a reminder, if you had a chance to try the private build, please uninstall it and reinstall the official 1.32.1 release once it's available. It's not recommended to use a private build other than just verifying the fix.

[asinitson]

https://storageexplorerpublish.blob.core.windows.net/privatebuilds/1.32.1-linux-renderer-crash/StorageExplorer-linux-x64-1.32.1-linux-renderer-crash.tar.gz

Works well on openSUSE Leap 15.5: I tried browsing a file storage account, switching folders, etc. No crashes experienced!

[MRayermannMSFT]

We've released 1.32.1 which includes the new Electron version. If anyone runs into this same issue again (renderer process crash on Linux using the .tar.gz package), please open a new issue. Thanks!