Mattermost windows desktop crashes (unabe to start)

[GoVivace]

I confirm (by marking "x" in the [ ] below: [x]):

• [x] This is not a troubleshooting question. Troubleshooting questions go here: https://docs.mattermost.com/install/troubleshooting.html.
• [x] This doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
• [x] I have read contributing guidelines.

---

Mattermost Windows desktop client crashes right after launchind. I see the (enter server" window for about 1 second before it crashes.

Environment

• Operating System: Windows 11
• Mattermost Desktop App version: 5.1.0.19938
• Mattermost Server version: 6.3.1

Steps to reproduce Not sure - other people are not necessarily seeing this crash. Expected behavior Application should just give me the window with all channels and messages. Observed behavior Crash with following entry in system event viewer log: Faulting application name: Mattermost.exe, version: 5.1.0.19938, time stamp: 0x624dbec5 Faulting module name: Mattermost.exe, version: 5.1.0.19938, time stamp: 0x624dbec5 Exception code: 0x80000003 Fault offset: 0x0000000001955b67 Faulting process id: 0x11c64 Faulting application start time: 0x01d8742c99dcb78b Faulting application path: C:\Program Files\Mattermost\Desktop\Mattermost.exe Faulting module path: C:\Program Files\Mattermost\Desktop\Mattermost.exe Report Id: 28406878-fd98-4db8-a65b-fc23fc3f097d Faulting package full name: Faulting package-relative application ID: - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> - <System> <Provider Name="Application Error" /> <EventID Qualifiers="0">1000</EventID> <Version>0</Version> <Level>2</Level> <Task>100</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2022-05-30T13:53:15.8136208Z" /> <EventRecordID>92321</EventRecordID> <Correlation /> <Execution ProcessID="54404" ThreadID="0" /> <Channel>Application</Channel> <Computer>vivace</Computer> <Security /> </System> - <EventData> <Data>Mattermost.exe</Data> <Data>5.1.0.19938</Data> <Data>624dbec5</Data> <Data>Mattermost.exe</Data> <Data>5.1.0.19938</Data> <Data>624dbec5</Data> <Data>80000003</Data> <Data>0000000001955b67</Data> <Data>11c64</Data> <Data>01d8742c99dcb78b</Data> <Data>C:\Program Files\Mattermost\Desktop\Mattermost.exe</Data> <Data>C:\Program Files\Mattermost\Desktop\Mattermost.exe</Data> <Data>28406878-fd98-4db8-a65b-fc23fc3f097d</Data> <Data /> <Data /> </EventData> </Event>

Possible fixes

[amyblais]

@hmhealey Would you be able to help take a look at this, or do we wait for Devin to take a look?

[StrikeForceZero]

I think I'm experiencing a similar thing. Although I'm on Windows 10 and I can get a little further. I got a notification about 5.1 a week or so ago and ever since I upgraded I haven't been able to start Mattermost. Even after uninstalling, re-installing, or downgrading. If I clear the roaming profile I can get it to load and let me configure a server. The server loads and I click the button for one of our SSO providers, then I can briefly see the username/password form before it crashes to desktop and leaves behind a core-dump.

Oddly non of my team members are experiencing this issue. So I've been hesitant to open an issue. Will keep an eye on this issue and see if it provides any information to eventually resolve.

[hmhealey]

@amyblais We probably have to wait for Devin to get back for this. Given the data available, I'm not sure what the issue might be. Devin also uses Windows for development, so he'd be the most familiar with debugging on it.

@GoVivace @StrikeForceZero The only other thing I could think that might be helpful is knowing if you have the app installed using the exe installer or the msi installer. After checking that, perhaps you could try downgrading to In the mean time, perhaps you could try downgrading to 5.0.4 and seeing if that still works. Hopefully your configuration should be saved, but there's a chance it might be lost when downgrading in which case you'd have to reconfigure your server URLs

[StrikeForceZero]

perhaps you could try downgrading to In the mean time, perhaps you could try downgrading to 5.0.4 and seeing if that still works.

@hmhealey So I had tried downgrading previously but never after clearing AppData/Roaming/Mattermost. After clearing that folder, 5.0.4 seems to work. Thanks!

[dfun90]

Just wanted to chime in on this as I've been experiencing crashes very similar to the one described here and I think they are probably caused by the same thing.

Details when the crash happens for me:

• Device: Laptop at Home
• OS: Windows 10 Pro (Latest Version, 21H2)
• Mattermost Desktop App: 5.10
• Steps to trigger the crash:
  • Start the app and switch to the Mattermost Community Server (I have two servers added in the app, my company's server and the Mattermost Community one)
  • After a few seconds of loading the app simply crashes and closes itself
  • Important Information: This ONLY happens on said device, here on the computer in my office those crashes do not happen (OS Version and App Version are the same)

Additional Information: If I remember correctly before I updated to 5.10 I was using 5.04. That was around the time when @amyblais started the Playbook run for the Self-Managed Release for v7.0 and right after I opened that Playbook the App also crashed. Then after updating the App to 5.10 it still kept happening. Back then I didn't think too much of it, just thought there were still some bugs to squash. Now I think this might also be related to the current issue.

I will try out the same that @StrikeForceZero did to get it working again, but will make a backup of the folder before that. I'll also make one on my computer in the office and then try to compare them. There might be an answer to finding the cause of the crashes.
Also. the logs of the app didn't show anything related to a crash, but I'll can try to set the logging to the highest verbosity level and see what it logs then.

I will report back on my findings later today or tomorrow when I'm off work.

[devinbinnie]

So usually hard crashes in the runtime that do not produce a stack trace of any kind aren't generally related to our code specifically, usually that will be an issue with Electron.

Nonetheless, we have a few steps we can take to see if we can figure out where it's occurring and if the issue has been reported back:

1. Do you see a uncaughtException file that matches the timestamp in your AppData/Roaming/Mattermost folder? If so, please attach that to this ticket.
2. Can you also attach the log file (located in AppData/Roaming/Mattermost/logs) so that we can see if there are any log messages that might indicate where the app crashes?

Thanks for the report :)

[dfun90]

So usually hard crashes in the runtime that do not produce a stack trace of any kind aren't generally related to our code specifically, usually that will be an issue with Electron.

Nonetheless, we have a few steps we can take to see if we can figure out where it's occurring and if the issue has been reported back:

1. Do you see a uncaughtException file that matches the timestamp in your AppData/Roaming/Mattermost folder? If so, please attach that to this ticket.
2. Can you also attach the log file (located in AppData/Roaming/Mattermost/logs) so that we can see if there are any log messages that might indicate where the app crashes?

Thanks for the report :)

Yea, I also think this might be something related to Electron. I did some rough testing the last weekend, as well as setting the logging output to silly. I didn't see anything in the logs that would relate to a crash and there were no uncaughtException files either.

I tried to then delete a bunch of the cache related folders at first, that change anything with the crash. Then I tried to delete the folder relating to the Community Server inside IndexedDB. No changes either. If I remember correctly I also tried deleting Local Storage and databases. No changes here either.

Then as a last resort I deleted the Session Storage folder as well, which then obviously made me login again. But after that it worked again. It's just grabbing in the dark right now, but I feel somewhere there might be the issue.

I'll upload the log file(s) of the app from before I tried out things (I made a backup of the entire Mattermost folder) and (if I still have them, I don't remember right now if I deleted the big silly log) while I was trying out things when I get home from work later today.

[devinbinnie]

Then as a last resort I deleted the Session Storage folder as well, which then obviously made me login again. But after that it worked again. It's just grabbing in the dark right now, but I feel somewhere there might be the issue.

Interesting, curious did you upgrade from an older version of the Mattermost Desktop App? I wonder if older Sessions stores between Electron v15 (or 16) are causing issues...if so we might have to ask users to blow them away.

[ai-arogers]

Hello, I just wanted to +1 this issue and see if maybe the desktop crashes we are experiencing would help troubleshoot it. Our environment is Gitlab's bundling of Mattermost, and the Windows desktop application can be reliably crashed by:

1. Opening our internal Gitlab server's login screen by selecting the purple "Gitlab" button
2. After logging in to a standalone instance of Mattermost (not Gitlab bundled) the application will crash as soon as the welcome walk-through is displayed
3. Starting a slash command by typing "/"

All three of these actions can be reliably repeated to cause the application to crash. The Electron stack trace of such a crash is:

Received fatal exception EXCEPTION_BREAKPOINT
Backtrace:
        IsSandboxedProcess [0x00007FF68A6B5B67+1943559]
        IsSandboxedProcess [0x00007FF68A6B574D+1942509]
        IsSandboxedProcess [0x00007FF68A6B0C76+1923350]
        std::__1::__vector_base<v8::CpuProfileDeoptFrame,std::__1::allocator<v8::CpuProfileDeoptFrame> >::__vector_base<v8::CpuProfileDeoptFrame,std::__1::allocator<v8::CpuProfileDeoptFrame> > [0x00007FF688F68453+47875]
        v8_inspector::V8StackTraceId::V8StackTraceId [0x00007FF68D7B0989+2641593]
        v8_inspector::V8InspectorClient::currentTimeMS [0x00007FF68D126201+1418193]
        v8_inspector::V8DebuggerId::operator= [0x00007FF6898040B6+431078]
        v8_inspector::V8InspectorClient::currentTimeMS [0x00007FF68D1444B2+1541762]
        uv_timer_get_repeat [0x00007FF68A0A9D34+3139908]
        v8_inspector::V8StackTraceId::V8StackTraceId [0x00007FF68DA12424+5138772]
        IsSandboxedProcess [0x00007FF68A74463C+2527964]
        node::GetEnvironmentIsolateData [0x00007FF689CFDB12+575906]
        node::GetEnvironmentIsolateData [0x00007FF689CFDEC5+576853]
        uv_timer_get_repeat [0x00007FF689F8774B+1950555]
        node::GetEnvironmentIsolateData [0x00007FF689D01A83+592147]
        uv_sleep [0x00007FF68A9E72C9+132521]
        Cr_z_crc32 [0x00007FF68C5A3BA0+626000]
        cppgc::internal::WriteBarrier::DijkstraMarkingBarrierRangeSlow [0x00007FF68C4DB528+3187944]
        Cr_z_crc32 [0x00007FF68C5A47D2+629122]
        cppgc::internal::WriteBarrier::DijkstraMarkingBarrierRangeSlow [0x00007FF68C4E97D5+3245973]
        uv_timer_get_repeat [0x00007FF68A44722D+6929981]
        uv_sleep [0x00007FF68A9E8C3A+139034]
        uv_timer_get_repeat [0x00007FF68A421155+6774117]
        node::GetEnvironmentIsolateData [0x00007FF689D50EC2+916818]
        node::GetEnvironmentIsolateData [0x00007FF689D52921+923569]
        node::GetEnvironmentIsolateData [0x00007FF689D4E202+905362]
        v8::metrics::LongTaskStats::LongTaskStats [0x00007FF6891C71DE+495230]
        v8::metrics::LongTaskStats::LongTaskStats [0x00007FF6891C85A2+500290]
        v8::metrics::LongTaskStats::LongTaskStats [0x00007FF6891C8002+498850]
        v8::metrics::LongTaskStats::LongTaskStats [0x00007FF6891C456C+483852]
        v8::metrics::LongTaskStats::LongTaskStats [0x00007FF6891C48E0+484736]
        std::__1::__vector_base<v8::CpuProfileDeoptFrame,std::__1::allocator<v8::CpuProfileDeoptFrame> >::__vector_base<v8::CpuProfileDeoptFrame,std::__1::allocator<v8::CpuProfileDeoptFrame> > [0x00007FF688F67F1D+46541]
        Cr_z_crc32 [0x00007FF68C8F7BE2+4115858]
        BaseThreadInitThunk [0x00007FFF56207034+20]
        RtlUserThreadStart [0x00007FFF566A2651+33]

After 5.1.0 gets removed and 5.0.4 is installed, there are no crashes performing any of the aforementioned tasks. The application also crashes before writing anything meaningful to the log file, which combined with how reverting to version 5.0.4 makes me suspect this is an issue with version of Electron that shipped with 5.1.0

I'll be happy to provide as much information as I can.

[devinbinnie]

Some users are reporting the crash is fixed for them in v5.1.1

Can anyone try and see if the issue persists?

[ai-arogers]

I can at least confirm that v5.1.1 has resolved all of the issues we were experiencing. Admittedly it's still early, but no users on v5.1.1 have reported a crash to us. Thank you!

[devinbinnie]

Closing as per above comment, looks like this crash was resolved.