We are using the SDL Passolo 2016 and it is constantly crashing lately when trying to update/import/generate literally anything on one of our projects (.NET forms).
I am at the latest version on Windows 10 which is the 16.0.412.0
The Windows event viewer creates that entry but it doesn't say much.
Could you please help me through that?
Thank you in advance!
Hello altogether,
we're facing spontaneous crashes of Passolo 22.0.183.0 (and earlier) mainly during the update of .Net string lists, too.
What I've seen is, that prior to the crashes, the memory usage of Passolo increases to about 2.x, nearly 3 GB.
What I don't have any idea about is, why this increased memory usage is not happening every time during updating the string lists. At some days, updating is no problem, on other days it's nearly impossible to update the string lists. It seams as if Passolo wouldn't release (all) the memory used after updating each string list.
And even closing the project file doesn't release the memory. Only closing Passolo and reopening the project in a new instance releases the used memory. If Passolo didn't crashed earlier. 
Maybe, this is something, one of you could check, too and report here. Just to to find out, if you're affected by this increased memory usage, too and if this could be a reason for the crashes, too.
Thank you very much in advance.
Kind regards and have a great day.
Nils
Hello altogether,
we're facing spontaneous crashes of Passolo 22.0.183.0 (and earlier) mainly during the update of .Net string lists, too.
What I've seen is, that prior to the crashes, the memory usage of Passolo increases to about 2.x, nearly 3 GB.
What I don't have any idea about is, why this increased memory usage is not happening every time during updating the string lists. At some days, updating is no problem, on other days it's nearly impossible to update the string lists. It seams as if Passolo wouldn't release (all) the memory used after updating each string list.
And even closing the project file doesn't release the memory. Only closing Passolo and reopening the project in a new instance releases the used memory. If Passolo didn't crashed earlier.
Maybe, this is something, one of you could check, too and report here. Just to to find out, if you're affected by this increased memory usage, too and if this could be a reason for the crashes, too.
Thank you very much in advance.
Kind regards and have a great day.
Nils
We have the same problem with the version 22.0.183.0 (and earlier).
Passolo keeps crashing, the reasons vary and you can't predict or reproduce it.
It concerns updating .NET text lists, checking these text lists or even just activities in the translation window (automatic translation, fuzzy match search).
There is a support request, but unfortunately there has been no solution or result so far.
Hello Birgit Puchner ,
thank you very much for your reply.
We have a support case logged, too. But unfortunately, as in your case, there's no solution until now, because RWS Support has not been able to reproduce these crashes, even with our files.
Until now, we didn't face this issue during checking the string lists or while working with the string lists / the translation window. On our side, the crashes only occure during the update or leverage of the string lists.
Where are your .lpu files and the sources are stored? Are they stored on a network share?
And do you unpack the bundles prior working on the translations?
Which kind of files are you using as sources? Are you using .resx or .dll files? We're using .dll files as sources.
Kind regards and thank you for your further informations.
Nils
We are using dll-files too in this project.
The complete project (lpu and binx64-folder is stored local for editing and translating.
We don't unpack the packages before working on the translations.
Interesting, we're using .dll files, too but our .lpu as well as the source files are stored on a network path.
We don't unpack the packages before working on the translations, too.
O.k., maybe, it could help to compare our workflows a little deeper. After opening a .lpu, we're starting by reading changes to the bundle from the FTP server and then running an update of the source string lists. If that (updating) worked well without any crashes, we do some tagging and filtering of the string lists.
Sometimes, it helps, updating only some of the source lists at once, closing Passolo, reopening the lpu and continue with updating the next few string lists.
To me, it seams as if the issue could be related to a memory leak due to not releasing the whole used memory, which has been used for this string list, after each string list and even not after closing the .lpu file.
How about your workflow?
And can you confirm the increased memory usage right before Passolo crashes?
The memory leak problem was communicated to the support as extra ticket from our developer.
I didn't check the meory while crashing.
From the support was recommended to update only some of the source lists at once, closing Passolo, reopening the lpu and continue with updating the next few string lists.
But that only helped for a short time - by the way, that's not a solution.
Hello Birgit Puchner ,
I totally agree, updating only a few lists, closing Passolo and reopening it to continue with the workflow is no solution.
What I'm wondering about, too, is that Passolo doesn't release the used memory, even after the .lpu file hase been closed and only Passolo it self is running.
Hopefully, RWS Support will be able to investigate the issue further.
And maybe/hopefully other users will report similar issues. That meight increase the priority to search for a solution. 
Thank you very much for your informations. Maybe, we can stay in contact, to update eachother, if there are any new findings or updates according to this issue.
Kind regards and have a nice and easy day.
Nils
I would strongly recommend logging a support case. When Support is able to reproduce the error, development will be able to release a hot fix very soon.
Hello Achim, the support case is logged since more then one week, but until now without result. I'm waiting for the next steps. But tSharing knowledge here in the forum also helps other users with the same problems.
Hello Achim Herrmann ,
our case regarding this issue is logged, since quite a while.
Unfortunately, RWS Support has not been able to reproduce this issue on their site. 
Best regards and have a nice day.
Nils
This is the same as in our case....
Translate
