Unigram 9.5.8088.0 crashes on Windows on ARM

[AkinoKaede]

Describe the bug
Unigram 9.5 crashes on Windows on ARM, although I reinstall it.

To Reproduce
Steps to reproduce the behavior:

1. Install Unigram in Microsoft Store
2. Open it

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Version Info

• Unigram: 9.5.8088.0
• Windows: Windows 11 22H2 22621.1485

Additional context
CPU: Qualcomm Snapdragon 8cx Gen 3

Sorry, I don't know how to get the crash log, could anyone tell me?

[punteroanull]

Same here (Surface Pro 9 5G), I installed the official version meanwhile.

[vitaminj]

Same, I get the splash and then the window immediately closes (Volterra Dev Kit).
Repair / clear app data, still broken.
Can attempt to run it up in VS to get a crash log if none of the devs have an ARM device?

[MarcAnt01]

Hi everyone thanks for reporting immediately, we are aware of this issue and its cause. A fix is being worked on.

@punteroanull TD has no Arm version, you simply emulate the x64/x86 version, being like this it requires no mantainance from the developers, since Unigram has an Arm version it requires some mantainance and this kind of issues can occur, we are sorry for the inconvenience of having to use another software temporarily

[MarcAnt01]

Fixed in 8.5.8101

[AkinoKaede]

Fixed in 8.5.8101

I upgrade it to 9.5.8106，but the problem doesn't seem to be resolved.

[FrayxRulez]

Can someone provide a crash dump?

[domcote]

Happy to. Can you pls provide some instructions for noobs? 😁

[punteroanull]

Can someone provide a crash dump?

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
 <Provider Name="Windows Error Reporting" Guid="{0ead09bd-2157-539a-8d6d-c87f95b64d70}" /> 
 <EventID>1001</EventID> 
 <Version>0</Version> 
 <Level>4</Level> 
 <Task>0</Task> 
 <Opcode>0</Opcode> 
 <Keywords>0x8000000000000000</Keywords> 
 <TimeCreated SystemTime="2023-04-04T16:42:46.8447366Z" /> 
 <EventRecordID>18473</EventRecordID> 
 <Correlation /> 
 <Execution ProcessID="12716" ThreadID="10984" /> 
 <Channel>Application</Channel> 
 <Computer>SurfacEdu</Computer> 
 <Security UserID="S-1-5-21-2817870534-2582539154-1409932555-1003" /> 
 </System>
<EventData>
 <Data Name="Bucket" /> 
 <Data Name="BucketType">0</Data> 
 <Data Name="EventName">POFContextAppCrash</Data> 
 <Data Name="Response">No disponible</Data> 
 <Data Name="CabId">0</Data> 
 <Data Name="P1">38833FF26BA1D.UnigramPreview_9.5.8106.0_arm64__g9c9v27vpyspw</Data> 
 <Data Name="P2">praid:App</Data> 
 <Data Name="P3">9.5.8106.0</Data> 
 <Data Name="P4">0x80040154</Data> 
 <Data Name="P5">69463437391835439dc7c5a67896be75</Data> 
 <Data Name="P6" /> 
 <Data Name="P7" /> 
 <Data Name="P8" /> 
 <Data Name="P9" /> 
 <Data Name="P10" /> 
 <Data Name="AttachedFiles" /> 
 <Data Name="StorePath">\\?\C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_38833FF26BA1D.Un_7d1569ff2373de29bfcb1a677d72715ee7f33_00000000_3bf386d9-5ae2-4a46-962f-8e9468a848f5</Data> 
 <Data Name="AnalysisSymbol" /> 
 <Data Name="Rechecking">0</Data> 
 <Data Name="ReportId">3bf386d9-5ae2-4a46-962f-8e9468a848f5</Data> 
 <Data Name="ReportStatus">4</Data> 
 <Data Name="HashedBucket" /> 
 <Data Name="CabGuid">0</Data> 
 </EventData>
 </Event>

[FrayxRulez]

Grabbed one from my Mac mini. Ironically, Visual Studio doesn't support inspecting stowed exceptions from ARM64 mini dumps.

[MarcAnt01]

Hi Arm64 users, just a quick update. In order not to prevent you from using Unigram the Arm64 has been removed from the store, so that you can keep using Unigram (even if in x64/x86), it's planned to fix the crash so that the Arm version can be sent back to the store in the future

[bam2000]

any update on this?

[FrayxRulez]

There are currently no plans to bring back support to ARM64.
Given the meager amount of users and lack of support by multiple app dependencies, this is not worth the effort.

I'm not closing this, as there's always the hope that things will change in the future.

[Soneoylys]

There are currently no plans to bring back support to ARM64. Given the meager amount of users and lack of support by multiple app dependencies, this is not worth the effort.

I'm not closing this, as there's always the hope that things will change in the future.

I have a Snapdragon 860 tablet with Windows 11 installed, if I want to compile the old known work version for myself as I'm not bothering to use a slightly old version, may I using cross-compile on amd64 desktop?
I'm able to install Visual Studio on the tablet but due to lack of ram (which only have 6 gigs) it's hard for compile on itself, or is there any old prebuild installer archive which still support arm64 can download?

[FrayxRulez]

@Soneoylys Yes. It is possible to cross-compile, still compiling Unigram is not an easy task.

[Soneoylys]

@Soneoylys Yes. It is possible to cross-compile, still compiling Unigram is not an easy task.

Thanks! I've succeeded cross-compiled arm64 build.

To someone wants to try: Confirmed this release works, follow the build instructions in this file, but while you configure the Visual Studio, make sure you install Windows 10 SDK as well, otherwise vcpkg might throw an exception about cannot found SDKs.

[domcote]

NICE! thanks for working on this. 👍 Do your have binaries I can test? I'm no dev and compiling stuff is beyond me. 😁 Dom

…

________________________________ Von: Soneoylys ***@***.***> Gesendet: Mittwoch, 22. November 2023 20:14 An: UnigramDev/Unigram ***@***.***> Cc: domcote ***@***.***>; Comment ***@***.***> Betreff: Re: [UnigramDev/Unigram] Unigram 9.5.8088.0 crashes on Windows on ARM (Issue #3010) @Soneoylys<https://github.com/Soneoylys> Yes. It is possible to cross-compile, still compiling Unigram is not an easy task. Thanks! I've succeeded cross-compiled arm64 build. To someone wants to try: Confirmed this release<https://github.com/UnigramDev/Unigram/releases/tag/v8.3> works, follow the build instructions in this file<https://github.com/UnigramDev/Unigram/blob/7e900c82edbc92d58725b26f5e160453adb66828/Documentation/Build-instructions.md>, but while you configure the Visual Studio, make sure you install Windows 10 SDK as well, otherwise vcpkg might throw an exception about cannot found SDKs. — Reply to this email directly, view it on GitHub<#3010 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AI43EQ45HJSJACUHWBBQEALYFZFHVAVCNFSM6AAAAAAWMBC6JKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRTGM2TCOJRG4>. You are receiving this because you commented.Message ID: ***@***.***>

[Soneoylys]

NICE! thanks for working on this. 👍 Do your have binaries I can test? I'm no dev and compiling stuff is beyond me. 😁 Dom

The app bundle's certification signature will not valid cross device.

Technically you can trust a custom ROOT CA to workaround AFAIK, but it also could be dangerous if you install CA from unknown person, which can do A LOT including decrypt your HTTPS data.

So I don't really want to upload precompiled binary with my custom signed CA because of that, sorry.

[ofoacimr]

There are currently no plans to bring back support to ARM64. Given the meager amount of users and lack of support by multiple app dependencies, this is not worth the effort.

I'm not closing this, as there's always the hope that things will change in the future.

Hi, I'm wondering if there are any chances to use Arm64EC? It can contain x64 binary and x64 lib.

By recompiling the modules that take the most time or are the most CPU-intensive from x64 to Arm64EC, the resulting workload receives the most improvement for the least amount of effort each step of the way.

https://learn.microsoft.com/en-us/windows/arm/arm64ec

[gus33000]

The developer of this project repeatedly claims as part of the reason for not bothering to port the app to arm64 that the userbase is too low to care about this.

I would be interested in the source for above claim as well as how it was gathered (telemetry for an app compiled as x64 can only report x64 obviously)

With the quick emergence of even more hw, it is also irresponsible to continue denying the eventual possibility of looking into doing such a port.

I also seriously wonder if it's really about business justification on userbase, or just personal hate?

To cite the developer: (message sent on telegram publicly once)

In my opinion they can suffer. Maybe it’s Microsoft choice not to provide a better emulation nor to push properly for arm64 adoption as Apple started to do 4 years ago.

[FrayxRulez]

I would be interested in the source for above claim as well as how it was gathered

The app has natively supported ARM64 until recently (Can't say exactly when, but I would say late 2022, early 2023) and it was one of the first (widely used) UWP apps to do that.

As the ARM64 user base has always been insignificant (we're talking about a few thousands people on the peak) I've decided to drop the support, because it's in fact non trivial, as Unigram has few native external dependencies that just don't care about ARM64 support on Windows (while they do on UNIX/Darwin) and they require writing patches and fixes for them and their build scripts every time they change something.

While I did this for years, I decided that's not worth it given the meaningless impact on user base.

Regarding Arm64EC comment from @ofoacimr, I don't think that this is doable: main code base for Unigram is C# compiled using .NET Native toolchain, and I'm not aware of Arm64EC for .NET Native.

[FrayxRulez]

By the way, I think it's a bit unfair to post that quote completely decontextualized from the rest of the conversation:

[vitaminj]

Thankyou for your previous support (and considered response here), Unigram was one of the few when I first bought my Volterra box that I was pleasantly surprised had an ARM version!
It's a shame the deps broke, but thankfully Unigram isn't exactly a CPU hog that needs to be run natively, so emulation is a perfectly fine fallback (and not noticeable for me).
Let's hope that the dependencies change their stance now that all the Snapdragon X stuff is coming and there is a legitimate push (after the small push with Volterra which kinda fizzled out)

[FrayxRulez]

@vitaminj agreed! Let's see what happens. Of course, it there will be a growth I'll be happy to get those libraries compatible again by myself (but hopefully it won't be needed)

[gus33000]

By the way, I think it's a bit unfair to post that quote completely decontextualized from the rest of the conversation:

In my honest opinion I don't see how the context you added here changes the messaging in a significant way.

I appreciate your reply but I'll remain on a disagreement with you on marketshare that makes little to no point. It really feels more like you don't want to care about the platform which is a real shame.

Calling my comment on this thread childish on different channel does nothing but recomfort me in the feeling that you really don't want to provide the right argument into this matter. While I appreciate your answer and obviously understand you're working alone on this app (and am thankful as well for this), I among others have also wanted to help you make that switch, but due to incredibly difficult instructions to build this app on its intended target at the moment (x64) and past issues reproducing the build steps, (for various reason, unpushed changes hard-coded paths etc), I at least never followed to contribute to make this switch as it simply feels unwelcoming and takes too much of our time to help. This may have changed now, I haven't checked this year. But I hope you at least understand the mood feels a bit unwelcome here, especially when everytime the conversation or state moves elsewhere. At the same time, it might make more sense to contribute into different project firsts. Tdesktop marketshare is what compared to unigram?

[gus33000]

In my honest opinion the real childish move here is the way you reply to this. I wasn't after all being in the wrong. Banning users because they offer help for you and want to make you change your stance and realizing supporting an emerging platform is the real childish thing. I'm thankful at least I got to know your real reason here. Unless you really want to recomfort us and excuse you for this behavior.

[FrayxRulez]

In my honest opinion I don't see how the context you added here changes the messaging in a significant way.

A clearly provocative message gets replied accordingly.
Talking about "making someone suffer" because they're forced to use a software compiled using an architecture that's not their native one is far from making someone suffer.

If you feel discouraged by Unigram build instructions and you don't want to contribute, what does it make you think that's any different for me towards all the libraries that don't support ARM64 on MSVC by so many years and they care absolutely nothing about it?

Chrome rolled out ARM64 support just a couple of months ago, I guess that now it should be fairly easy to compile WebRTC for the architecture. Until then, WebRTC itself and 4-5 of its dependencies required patches to compile on ARM64.

WebRTC still requires a 10.000 lines patch to work with UWP, and this as well requires a lot of maintenance on every release.

LibVLC is not shipped pre-built for ARM64 and I'm not sure whether compiling it for UWP ARM64 is possible at all, because their community is as welcoming as this one and their documentation is just terrible and broken (but still, I did my best at least to compile their library for x64 by myself).

FFmpeg somehow builds on ARM64 but decoded videos are full of artifacts and glitches. Still, depending on the version it won't build or would just crash on x64 because of some bug in their ASM code that will likely never get fixed because their community is as helpful as this one (by "this one", I of course refer to myself), so we're stuck on some ancient version that at least won't crash.

I can keep on going, if you want.

This said, I find it extremely offensive that you consider your time so much valuable not to want to invest any of it in trying to do something (that currently) would be helpful only for you and a few more people, but you decide to ignore all of the above and you accuse me of "hating" and "not caring".

[gus33000]

I don't see how calling my message childish and every time the arm topic is brought up saying the marketshare is low makes me any welcome to help here? If you find the message you said yourself offensive, so do I? I wasn't intending the quote to be provocative, it more highlights one of the few examples where it felt like you preferred us to suffer other than having a native build. I of course remain happy to help one day, but only if we can have a conversation on the topic other than calling each other childish and if you're willing to help us a little as well. Saying every user should suffer is a bit wrong. The emulation layer isn't even originally this bad. People benchmarked it on apple laptops originally where it was as good as rosetta

It wouldn't even benefit just me, there's a lot more users, plus, you use an arm MacBook for a while, you had access to this architecture no? Unless I'm mistaken and I am sorry if I am.

I don't see how I'm supposed to feel welcome or happy to help here, you maybe still have a point on marketshare if you want to but at the same time if we really have to consider marketshare it would make way more sense to port tdesktop first. I really am not here motivated by marketshare. I just wish the in my personal opinion, best telegram experience for windows users would be native again, and I would be happy to help. But you really don't encourage me to continue.

Just today users were discussing using telegram web as a workaround. I wish they would have a native version of this app. It's not just me thinking you don't care here. If I'm wrong, I'm sorry and I would be happy to be. But others say it too. And I really am not sure the marketshare is this low to begin. With...

Happy to forget what happened but only if you are willing.

I dont think asking you to at least, make the ability to build the app on amd64 easier from scratch or at least helping us doing so is a hard feat for you, you do this all the time to build the app anyway, its what really doesnt help us at all trying to contribute. Why would I spend time myself guessing how you build the app normally here, when you could just help us do it? Is it that wrong to not want to spend the time doing that guesswork? And as you said, it wouldnt even be just, here have premade libs, we obviously need to know how you built them...

so no, of course i dont want to help here, you ban us, react in a negative way, and are often unwilling to help us rebuild the app from scratch. How does that make me the one being in the wrong for not wanting to?

[GeldHades27355]

Foks, love the discussion right now.

Why don't we wait a few weeks/months and revisit this? Especially @FrayxRulez I bet with the advent of Snapdragon X for Windows and MSFT's extreme interest in establishing it as the NEXT benchmark for Windows experiences, there will be a flurry of new development and compilation, including all the Unigram dependencies.

Going forward, devs and their business manager can't afford to ignore Arm64 support anymore, as even large hardware and software corporations are fully buying in to Arm64 now.

As pointed out, Unigram runs quite well as an emulated x64 app right now, so there shouldn't be real urgency. But I see how other universal apps have gotten super-charged after they switched from emulated x64 to native Arm64 code.

@FrayxRulez while we're at it, can you ensure there are no Arm32 fragments left? Windows will drop support for Arm32 entirely by 24H2. Current previews already won't run Arm32 anymore (Minecraft now is emulated... 😭)

[FrayxRulez]

Why don't we wait a few weeks/months and revisit this?

Of course, I never said never, I always just referred to right now.

[gus33000]

What tells us you're going to test these builds later on? Afterall, twice in the past they broke, you referred before as 2022, but you forgot the app broke the year before. Even if I'm willing to help you kickstart the port here, what tells me everything will have to be redone later on because the app broke with some update due to a lack of testing, and that it's going to come back to x64 only? Or that you adopt a new library one day (like libVLC which didn't use to exist) We really need this assurance as well.

I fully get you want to talk about right now and that you'll revisit this, but the history really isn't helping.

The argument about chrome itself just being out is also awkward. Chromium has been running on arm64 for years, and that has always used WebRTC. I in fact made WebRTC compile for you years ago... (remember: https://gist.github.com/gus33000/7a7f310528082d5b7ba555fed6379e03)

And I'm really not taking the argument well that I'm not even contributing here on my own before complaining, who made a guide to help you build your own app myself, spent an entire two weeks figuring out what exact commit hashes you even used to build it (which again, today, proves to be likely the reason as to why people can't rebuild it, a few examples: #3095 #3038 or this one, where you simply told the person to go fix it on his own... #3068), and correct the hardcoded paths? Like i'm sorry, but i find the argument very unjustified.

https://gist.github.com/gus33000/7a7f310528082d5b7ba555fed6379e03

To me the app doesn't simply need to wait on some library maintainers to fix their things (and i agree with you here), it also needs assurance that you're going to commit to test and maintain this platform afterall. Can we trust you on this? Or would you want to rely on others for doing so?

The problem is bigger when the app suddenly fails one day compared to the previous one, than when it's not pefoming as it should.

Once again, I'm more than willing to provide feedback and help here, but only if you don't act in a hostile way to us and your end users that only realistically complain because they love your app and just want it to run great on their device.