Signal won't show on screen after launch on Windows 10 x64

[AlecClaire]

I've got Signal paired with my Android and Windows 10 x64. It was running as it should until.

So, after circa a week of using Signal on desktop. when I want to launch it. the app window won't appear on my desktop. However, the task manager shows it it running. No way to get it to appear on the screen. I had to reinstall. It's the second time it happened in three weeks.

Any ideas why this issue is occurring?

[cob16]

Just to add until this gets addressed the only workaround I found was to install the current signal beta. Reinstall was no use.

Current download as of 03/09/2018
https://updates.signal.org/desktop/signal-desktop-beta-win-1.16.0-beta.1.exe

[scottnonnenberg-signal]

@AlecClaire We've had some problems in recent builds on computers that run out of disk space or restarted at odd times; key data can be lost when that happens, preventing startup. The beta has a fix to solve this problem.

Anyway, if you start Signal Desktop (prod) from a Command Line window and provide the output, we can be sure about what's going wrong for you. It would also help if you could think back to anything unusual (like I mentioned above) that may be happening with your computer.

[mad-engineer]

This is the error log from the command line:

{
  "name": "log",
  "hostname": "private",
  "pid": 12536,
  "level": 30,
  "msg": "app ready",
  "time": "2018-09-06T09:36:07.595Z",
  "v": 0
}
{
  "name": "log",
  "hostname": "private",
  "pid": 12536,
  "level": 50,
  "msg": "Uncaught error or unhandled promise rejection: Error: SQLITE_NOTADB: file is not a database",
  "time": "2018-09-06T09:36:07.607Z",
  "v": 0
}

The loss of key data and no way to sync the data is a bad combination. Signal makes it so easy to loose all the data. Let me explain why.

Recently an LineageOS bug killed the keystore.

It does not seem to be related to Signal but at this time the desktop was the only working backup since media wasn't stored in the mobile backup.

There was also no well-designed working backup function in signal desktop. Syncing the phone again would erase the old datastore on the computer.

Somewhere in the forum here I found an console-javascript-hack which made it possible to keep my data and sync the phone. I had to do the following steps.

1. Export the data from the desktop with the javascript-hack.
2. Link the phone again to the desktop and loose all the data on the desktop.
3. Sync the new phone messages to the desktop.
4. Import the exported (old) desktop data into the new desktop data store.

It's an very awkward solution but it worked. Awkward because using this way the imported (old) desktop messages won't be synced back to phone. This is bad but not as bad since they can still be found on the desktop.

Recently, there was an commit which blocked the import/export function from javascript. This killed the last possibility to backup something in a reasonable way. Remember that the old messages were not synced back to the phone.

Now something seems have to killed my keystore on the desktop. I can only explain it myself that after the keystore was loaded into memory, some routine deletes it on the hard drive and writes it back at exit. I might be wrong. Correct me. Whoever designed it must never thought about an spontanous crash. Remember that there was never a working backup after years since the initial android version was released. A simple crash kills the entire keystore? It's not a bug, it's an complete design fail.

At this point I had only an old desktop backup and the new messages on the phone.

I have a full hard-drive-backup but since I haven't used the desktop messengers since a week or so, the regular backup will be out of date as well.

Correct me if I'm wrong, we are talking about an secure messenger but data integrity, the most basic feature has been violated for years due to the lack of an working backup function. All the security considerations make no sense if you can't rely on that your precious messages from business partners are available.

One thing which makes it even worse is that there are no useful error messages to start which are visible to the user. You have to dig yourself which probably only 1% of all users able to do.

Sooner or later more and more people will fall into this trap and loose all their data. 99% of them won't even have a starting point to get their data back and will end up frustrated and deinstall Signal from their phone. From my point of view backup and sync must have the highest priority.

Whoever (if someone does it?) is planing the software architecture should take some lessons in software development. These are the sort of mistakes which ruin entire software ecosystems. Especially the messenger market has a hard competition with almost no chances for newcommer.

[scottnonnenberg-signal]

@mad-engineer I understand that you're frustrated. The good news is that a fix was put in place in v1.16.0 to make it way less likely that you'll lose important configuration data.

Going forward, I suspect that your backup will still be more useful than starting from scratch - you'll need to 'Reset Session' with most conversations, but you'll still have your historical messages.

Lastly, please consider starting a thread on the forums for your backup preferences and history. For this bug we need the detailed situations on your computer that may have caused the erasure of configuration data (config.json). You seem to think that it was due to a 'spontaneous crash' - can you talk a little more about that?

[scottnonnenberg-signal]

@mad-engineer Details of your Signal Desktop version would be really useful as well. You might consider taking a look at the full bug template - it's a great tool to ensure that enough information is included in any bug report.

[mad-engineer]

@scottnonnenberg-signal: My latest version before crash was 1.15.5

Unfortunately I can't describe the situation which caused the failure. I guess I forgot to charge and my laptop battery got empty when it was in standby over the weekend.

My config.json looks like this

{
"key": "some base64 like key"
}

[scottnonnenberg-signal]

@mad-engineer: Thanks for the additional detail. Either way v1.16.1-beta.1 has changes to ensure that this doesn't happen in the future.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to inactivity.