• State Suggested Answer
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 434 subscribers
  • Views 3123 views
  • Users 0 members are here
Options
Related

Studio 2017 Pro - frequent crashes with Office formats

Andreas Galambos

Hi everybody,

recently, our translators are encountering increased crashes of Studio 2017, especially with more complex docx or xlsx files. Studio will unexpectedly close down. After starting it again, there is a reference to an arbitrary temporary file as source file, which needs to be re-set to the original source file in order to be able to generate a target file.

Another thing that happened recently is that when we import a translator's return package, not only is there a reference to such a temporary file, but also a reference to a temporary FileFilter-Plugin! While the former is mostly a nuisance that can be fixed, the latter actually prevents us from generating target files due to a non-existent temporary file filter.

Our only option then is to add a copy of the originalfile to the project, perfect matching it with the translated sdlxliff and generating a target file from this copy.

 

Has anyone else encountered this unstable behaviour of Studio? Can it be remedied by any setting?

Note: all our projects are always set up on a network share, never locally. Our internal translators also work on a network share project.

P.S: we are NOT using roaming profile folders.

 

Thanks!

Andreas
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents Reply
  • 0 in reply to Andreas Galambos

    Update: Despite the whitelisting in our AV, Studio continues to close unexpectedly.
    I have checked the log files under %localappdata%\SDL\SDL Trados Studio\  for any occurence of an error at the reported times - none there.

    There are very few FATAL error entries complete with stack trace but none for the times of the crashes I was looking for. Instead, a second log is created with an extension of ".log.1" and a different number at the end, followed within the minute by a proper ".log" with the same number in it.

    Looks like the crash is not just an unhandled exception but one that prevents nLog from writing the trace to the log.

    I have looked through the logs on three different computers that experienced these crashes and found nothing.

    Will try to find something in the system event logs but I do not expect any more information than "appCrash".
Children