Passolo 2016 client constantly crashes.

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!

emoji
Parents
  • 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. Wink

    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

    emoji
  • 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.

    emoji
  • Hello ,

    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

    emoji
  • 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.

    emoji
  • 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?

    emoji
Reply
  • 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?

    emoji
Children