Closed TACIXAT closed 2 months ago
I'm not sure there's much we could do to improve this, there's already a lot of retrying that's going on now that all failed (Possibly because of some sort of antivirus software?).
But if there's no way to write the necessary files then there's not much we can do besides show an error. The first error is a useful step to get it working again, but then the second error is an accurate description of the issue we ran into and there's not a lot we can diagnose about it otherwise
Any idea on what would be preventing it from shutting down or how to diagnose that? I do not have AV running, perhaps Windows Defender.
@TACIXAT does this issue persist after computer restarts? We had reports of lingering processes staying alive when installer attempts to close currently running Signal instance. Typically they also appear in task manager.
I will try rebooting before updating next time I have an update pending.
Same result. Update was available, rebooted my computer, opened Signal, applied update. There was a single Signal process with 4 child processes. They all shut down when the updater ran.
It is weird that it doesn't happen on my other Windows machines and reinstalling did not fix it. I will try to find the source for the updater and have a look.
After killing the installer, it comes back with no icon (in the taskbar as well as task manager), then the updater works.
The logs do not show a difference from what I could tell, both cases seem to shut down correctly. It feels like the installer cannot detect that it shutdown correctly.
INFO 2024-09-26T04:36:57.181Z close event {"readyForShutdown":true,"shouldQuit":true}
INFO 2024-09-26T04:36:57.182Z NotificationService: clearing notification and updating
INFO 2024-09-26T04:36:57.182Z show window
INFO 2024-09-26T04:36:57.182Z NotificationService not updating notifications. Notifications are enabled; app is not focused; there is no notification data
INFO 2024-09-26T04:36:57.189Z main window closed event
INFO 2024-09-26T04:36:57.189Z System tray service: updating main window. Previously, there was a window, and now there is not
INFO 2024-09-26T04:36:57.189Z System tray service: rendering no tray
INFO 2024-09-26T04:36:57.189Z will-quit event {"hasEventBeenPrevented":false,"windowCount":0,"mainWindowExists":false}
INFO 2024-09-26T04:36:57.189Z quit event {"hasEventBeenPrevented":false,"windowCount":0,"mainWindowExists":false}
// Update failed, took a screenshot and updated issue.
INFO 2024-09-26T04:41:13.283Z got fast localeOverride setting null
INFO 2024-09-26T04:42:31.196Z close event {"readyForShutdown":true,"shouldQuit":true}
INFO 2024-09-26T04:42:31.206Z main window closed event
INFO 2024-09-26T04:42:31.206Z System tray service: updating main window. Previously, there was a window, and now there is not
INFO 2024-09-26T04:42:31.206Z System tray service: rendering no tray
INFO 2024-09-26T04:42:31.206Z will-quit event {"hasEventBeenPrevented":false,"windowCount":0,"mainWindowExists":false}
INFO 2024-09-26T04:42:31.206Z quit event {"hasEventBeenPrevented":false,"windowCount":0,"mainWindowExists":false}
// Update succeeded.
INFO 2024-09-26T04:42:34.676Z got fast localeOverride setting null
Likely related issue, seems like NSIS problems - https://github.com/electron-userland/electron-builder/issues/6865
@TACIXAT looking at that electron builder issue it appears that the bug could be triggered by long paths or paths with unicode/non-latin characters. Does your path to Signal fall into either category?
I do not believe so. My computer is in English and the paths are well within the standard MAX_PATH
, and I believe I have long paths enabled.
C:\Users\username\AppData\Local\Programs\signal-desktop
(55)
C:\Users\username\AppData\Roaming\Signal\update-cache
(53)
I just tried running the installer as an administrator and that did not change the behavior.
Can the installer be built with debug symbols? I'd happily follow it in windbg. If not maybe I can use regshot or some syscall trace to see what it is trying to do.
Rebooted, I did not start Signal. Ran the updater from %APPDATA%\Signal\update-cache
, it still reports that it cannot be closed. It was definitely not running. On the next run the installer completes.
@TACIXAT does your Windows username have any unicode characters in it?
None at all.
On Fri, Oct 11, 2024 at 12:32 PM trevor-signal @.***> wrote:
@TACIXAT https://github.com/TACIXAT does your Windows username have any unicode characters in it?
— Reply to this email directly, view it on GitHub https://github.com/signalapp/Signal-Desktop/issues/7015#issuecomment-2408012072, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHP4RX5XOI3Y2WK3CFNIL3Z3ARTPAVCNFSM6AAAAABOEQ73N6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGAYTEMBXGI . You are receiving this because you were mentioned.Message ID: @.***>
Alright, I noticed C:\Users\username\AppData\Local\Programs\signal-desktop\
gets cleaned out on the failed update, then the next update succeeds. Through binary search I have identified that Uninstall Signal.exe
being present in that folder causes the update to fail (deleting that, it succeeds first try, deleting everything besides that, it fails first try).
Does the updater run that during the update process?
Does the updater have a problem because the file has a space character in it?
Using a supported version?
Overall summary
When an update is available, the first time I click the update button, Signal is unable to be closed. After it closes and reopens it will update correctly. This only happens on one of my computers. I reinstalled last week to see if that would fix it.
Steps to reproduce
This is likely specific to my machine, but clicking the update button.
Expected result
Signal is updated
Actual result
Signal cannot be closed. Please close it manually and click Retry to continue.
Failed to uninstall old application files. Please try running the installer again.: -1073740940
0xc0000374
Screenshots
Signal version
7.24.0 production
Operating system
Windows 11
Version of Signal on your phone
No response
Link to debug log
https://debuglogs.org/desktop/7.24.1/5ae4be7a69da2d22c8413a108753ccf057617ef7847b134afce6cd3eacca4b65.gz
I believe the minute timestamp :44 is failed update and minute :55 is the successful.