Trados Business Manager
Language Weaver Connectors
Language Weaver Edge
Tridion Docs Developers
RWS User Experience
Internal Trados Ideas Community
RWS Community Internal Group
RWS Training & Certification
RWS Enterprise Technology Partners
Trados Approved Trainers
ETUG (European Trados User Group) Public Information
Nordic Tridion Docs User Group
Tridion West Coast User Group
Trados Studio Ideas
Trados GroupShare Ideas
Trados Team Ideas
Trados Team Terminology Ideas
Trados Enterprise Ideas
Trados Business Manager Ideas
RWS Appstore Ideas
Tridion Docs Ideas
Tridion Sites Ideas
Language Weaver Ideas
Language Weaver Edge Ideas
Managed Translation - Enterprise Ideas
LiveContent S1000D Ideas
Events & Webinars
To RWS Support
Detecting language please wait for.......
I'm using Studio 2017 and it randomly just shuts itself down without any warning. Poof and it's gone.
It doesn't happen when I'm doing a certain task in particular, just whenever it fancies apparently.
Can someone tell me why this may be happening and how to rectify it if possible?
I have been getting this problem in 3 different machines with Windows 10 and Studio versions 2017 and 2019. I just got it again, in a fresh Windows 10, 1903 install and latest Studio 2019 build. The only common denominator is Avast antivirus. At times I simply press Ctrl+Enter and it shuts down.
have you checked your RAM memory f.e. using Memtest?
Second thing - maybe it's not the right address but I'd check this. Open "Run" (use left WIN key with R on the keyboard) and type or copy&paste: eventvwr.msc and click OK. Alternatively: right-click or tap and hold the Start icon. Choose the Event Viewer.
See the logs there. Maybe you'll find something odd of any details that will be helpful in further diagnosis. Check especially windows system logs and software and services logs. The entries are in achronological order so it should be easy to find some second after encountering the problem. I don't have English windows so the names may be not 100% accurate. Sorry about that. Maybe it's not the remedy but it's worth trying.
More basic information about the Event Viewer: https://www.dummies.com/computers/operating-systems/windows-10/how-to-use-event-viewer-in-windows-10/
This is what I could find:
Fault bucket 2304622717258355442, type 5Event Name: RADAR_PRE_LEAK_WOW64Response: Not availableCab Id: 0
Problem signature:P1: SDLTradosStudio.exeP2: 18.104.22.168768P3: 10.0.18322.214.171.124P4: P5: P6: P7: P8: P9: P10:
These files may be available here:
Analysis symbol: Rechecking for solution: 0Report Id: 9201b011-ccb1-4919-814d-877364a4fa3cReport Status: 268435456Hashed bucket: 789985c528ef76fbeffbaa26a37ad2f2Cab Guid: 0
Ending a Windows Installer transaction: C:\ProgramData\Package Cache\SDL\SDLTradosStudio2019_SR1\modules\TranslationStudio15.msi. Client Process Id: 1796.
And this is an error I get when trying to check project settings:
<SDLErrorDetails time="5/7/2019 9:54:41 πμ"> <ErrorMessage>Δημιουργήθηκε εξαίρεση από τον προορισμό μιας κλήσης.</ErrorMessage> <Exception> <Type>System.Reflection.TargetInvocationException, mscorlib, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b77a5c561934e089</Type> <HelpLink /> <Source>mscorlib</Source> <HResult>-2146232828</HResult> <StackTrace><![CDATA[ σε System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) σε System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) σε System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) σε System.Activator.CreateInstance[T]() σε Sdl.Desktop.Platform.Settings.SettingsPageReference`1.Initialize() σε Sdl.Desktop.Platform.Implementation.Settings.AbstractSettingsHost.EnsurePageInitialized(ISettingsPageReference r) σε Sdl.Desktop.Platform.Implementation.Settings.AbstractSettingsHost.ActivateSettingsPage(String path) σε Sdl.Desktop.Platform.Implementation.Settings.AbstractSettingsHost.SetInitiallyActivePage() σε Sdl.Desktop.Platform.Implementation.Settings.AbstractSettingsHost.get_SettingsHostUI() σε Sdl.Desktop.Platform.Implementation.Settings.SettingsDialog.Dispose() σε Sdl.TranslationStudio.ProjectManagement.Actions.ProjectSettingsDialogHelper.Show(IProject project, IProjectManagementService service, ConfigureProjectSettingsDialogDelegate configureProjectSettingsDialog) σε Sdl.TranslationStudio.ProjectManagement.Actions.ProjectSettingsAction.Execute() σε Sdl.Desktop.Platform.Implementation.CommandBars.ActionService.<>c__DisplayClass30_0.<ExecuteAction>b__0() σε Sdl.Desktop.Logger.Log.Resources(Object message, Action action) σε Sdl.Desktop.Platform.Implementation.CommandBars.ActionService.ExecuteAction(IAction action, ActionOrigin origin, Boolean allowToggle) σε Sdl.Desktop.Platform.WinForms.IgCommandBarAction.Execute() σε Sdl.Desktop.Platform.WinForms.IgCommandBarAction._lazyButtonTool_ToolClick(Object sender, ToolClickEventArgs e) σε Infragistics.Win.UltraWinToolbars.ToolBase.OnToolClick(ToolClickEventArgs e) σε Infragistics.Win.UltraWinToolbars.UltraToolbarsManager.OnToolClick(ToolClickEventArgs e) σε Infragistics.Win.UltraWinToolbars.UltraToolbarsManager.FireEvent(ToolbarEventIds id, EventArgs e) σε Infragistics.Win.UltraWinToolbars.ToolBase.OnToolClick() σε Infragistics.Win.UltraWinToolbars.ButtonToolUIElement.DoClickProcessing(MouseEventArgs e) σε Infragistics.Win.UltraWinToolbars.ButtonToolUIElement.OnMouseUp(MouseEventArgs e) σε Infragistics.Win.ControlUIElementBase.ProcessMouseUpHelper(Object sender, MouseEventArgs e) σε Infragistics.Win.ControlUIElementBase.ProcessMouseUp(Object sender, MouseEventArgs e) σε Infragistics.Win.Utilities.ProcessEvent(Control control, ProcessEvent eventToProcess, EventArgs e) σε Infragistics.Win.UltraWinToolbars.UltraToolbarsDockArea.OnMouseUp(MouseEventArgs e) σε System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) σε System.Windows.Forms.Control.WndProc(Message& m) σε System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) σε System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) σε System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)]]></StackTrace> <InnerException> <Type>System.ArgumentNullException, mscorlib, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089</Type> <ParamName>source</ParamName> <HelpLink /> <Source>System.Core</Source> <HResult>-2147467261</HResult> <StackTrace><![CDATA[ σε System.Linq.Enumerable.Where[TSource](IEnumerable`1 source, Func`2 predicate) σε Sdl.TranslationStudio.Common.TranslationMemory.TranslationMemoriesControl..ctor() σε Sdl.TranslationStudio.ProjectManagement.Settings.TranslationMemoriesSettingsPageControl.InitializeComponent() σε Sdl.TranslationStudio.ProjectManagement.Settings.TranslationMemoriesSettingsPageControl..ctor() σε Sdl.TranslationStudio.ProjectManagement.Settings.TranslationMemoriesSettingsPage..ctor()]]></StackTrace> </InnerException> </Exception> <Environment> <ProductName>SDL Trados Studio</ProductName> <ProductVersion>184.108.40.206</ProductVersion> <EntryAssemblyFileVersion>220.127.116.11768</EntryAssemblyFileVersion> <OperatingSystem>Microsoft Windows 10 Home</OperatingSystem> <ServicePack>NULL</ServicePack> <OperatingSystemLanguage>1032</OperatingSystemLanguage> <CodePage>1253</CodePage> <LoggedOnUser>PAXOS\spiros</LoggedOnUser> <DotNetFrameWork>4.0.30319.42000</DotNetFrameWork> <ComputerName>PAXOS</ComputerName> <ConnectedToNetwork>True</ConnectedToNetwork> <PhysicalMemory>6221148 MB</PhysicalMemory> </Environment></SDLErrorDetails>
Hi Jasmine Stolk, Katia Zanarini, Sandor Juhasz, Martin Lund, Spiros Doikas and Rafał Kwiatkowski
A reinstall of Windows didn't solve the problem for me but my frequent crashes in Studio 2019 were completely stopped by turning off Match Repair. It has to be turned off in Project Settings:
Most of my work these days is proofreading so I don't need Match Repair. I systematically open each translated package I receive and turn Match Repair off.
I realise that's not a solution for translators who need Match Repair. However, I wondered if it might be a relevant factor in the search for a solution, ?
I thought it might be useful to find out how many users say it works for them...
All the best,
I can confirm that turning off Match Repair kept my Studio crash-free for the last 2 days. I guess we found the culprit.
Has this been logged as a Match Repair bug, Steven Whale?
Spiros Doikas said:Has this been logged as a Match Repair bug, Steven Whale?
Hi Alison Field ,
I have checked the logs and I cannot see/find any current bug logged for this exact issue, so I would absolutely recommend a support ticket if this is still ongoing (after upgrading to latest version?).
A support ticket isn't enough, this is widespread. Ever since the introduction of Match Repair, it has been known by at least a few of us that turning it off stops Studio crashing. I've lost count of the amount of times I've suggested it to a user asking for help with Studio freezing/crashing and it's solved their problem.
It needs elevating beyond investigating a single user's setup... that's why I tried to set up a survey 3 months ago, higher up in this thread.
Hi Steven Whale,I can confirm that this issue is as active as ever, even with version 1524.16.93 rendering Match repair an unusable feature. Issue stops appearing when Match repair is disabled. This was tested in 3 different machines.
I wonder what is being done about this. It has been over a year.
"recommended" that a support ticket be opened. Does that mean he was expecting the users to do something? Does that mean nothing is actually being done?
Not that it matters to me, since I don't use any of the "bells and whistles" in Studio. The software is good, but in my opinion it is too risky to use anything but the core functionality. (This bug is a good case in point.)
But I am curious about what it takes for SDL to consider a bug important enough to fix.
Paul has been recommending that we not use Look Ahead for years, and now it looks like Match Repair is also unusable and might remain unusable for years.
What could SDL possibly be working on that is so critically important that major problems like this are left unresolved for years?
I work for SDL and the situation is exactly the same for us as well. We need a support ticket logged for issues that we care enough about.
Whenever we ask about issues that we cannot find in JIRA, we often get a response from Product team like this: “At the moment we don’t have an item to cover this problem.”
So, there is not one JIRA ticket talking about a particular issue, we need to log a support ticket, only then a support engineer can verify the issue and log it in our JIRA, in which our Product team keeps track of their effort. Support ticket is the official channel to Studio Product team for all users. I hope this helps.
Unknown said:What could SDL possibly be working on that is so critically important that major problems like this are left unresolved for years?
Hi Naoko Jones
I would be pleased to but I can't log a support ticket. I don't have a PSMA (or an SDL Language Solutions Support and Maintenance Agreement as I see it's now called). I used to have one but almost never used it because I tend to be able to solve my own problems. I've been using the products since they were launched, I'm a beta tester and I love troubleshooting my problems and other people's, if and when I have time.
Also, this problem seems impossible to pin down. The crashing is spasmodic, it doesn't happen every day with every project. A help engineer during one remote session would almost certainly not encounter a crash.
I could run the software until it crashes so that I can make a copy of the stack trace but it is much easier to use the solution I know will work, to avoid the crashes in the first place. Namely, I have Match Repair, LookAhead and Fragment Matches all turned off under File>Options and/or in Project Settings as a matter of course. I also stopped using the web lookup plugin.
All of this added up to two positive effects. Firstly it prevented the frequent crashes I was experiencing. Secondly, it also solved the problem of Studio being ridiculously slow with some jobs. Thus, that's how I work unless I really need to turn the functionality on, which I only do when I'm translating. I work mostly proofreading / reviewing technical translations in Studio so those features are not necessary for me until I get a translation job to do.
I work well with this setup. I would love to help find a solution to the problems that turning these features off solves, which I why I set up a poll to find out if many others also experience the same as I do. However, I can only log a request for support if I have a licensing problem or an installation problem...
I understand what you say about JIRA (though I had to look it up to find out what JIRA is) but unless you can give me a way of logging a support ticket without signing up to a PSMA, I simply can't do it...
Thank you for your message, I'd love to be able to take this further and would be happy to let someone look at my PC remotely if there's a way I can help solve this issue...
All the best
So, another problem falls between the cracks.
It looks like a problem exists, and Studio -- as it is coded -- is not providing the information needed to isolate the problem.
One might even say that the real problem here is Studio's failure to provide the information needed to convince someone to open a ticket and investigate the problem.
This might be a silly idea, but couldn't a support engineer work with a small number of beta users like Ali and give them a special version of the program that provides better information for debugging purposes?
It might take several versions to zero in on the problem, especially since it can't be reproduced at will, but without additional information I can't see how bugs like this can be handled.
The alternative is to let it fall between the cracks and hope that it disappears by itself someday -- which appears to be what is happening.
We are not trying to say that Match Repair is not at fault somehow, but it is difficult to pinpoint an issue when this affects a limited (that we are aware of) amount of users.
A number of users who have contributed to this thread, also contacted support (who then performed a remote WebEx support session).
The results were, that in one case there was an issue with the installed .NET. In two further cases the issue lag with an OS that was not updated and either an update or reinstall seems to have solved the problem. A further case saw a conflict with a plug-in.
Other logged cases with support were resolved when full admin rights were made available to the user.
We do not know at this stage if the users are still using Match Repair or not-so we can only assume the issue is fixed and would invite @Spiros Doikas and @Alison Field to log a ticket (referencing this thread).
Anything we can do to try and get to the bottom of this is surely going to be welcome from all involved.