New update on that issue—well, in fact, nothing new per se (the “0x%1” issue keeps popping up for more and more people in my organization), but here's what I noticed for now:

The error can happen in any of the circumstances below:

1. When creating a translation project, or a revision project package;

2. When confirming a segment;

3. When updating the preview;

4. When generating the target file;

5. When opening a project.

I couldn't say why it happens, but the messages seem to imply that it occurs because the file becomes temporarily unavailable, so that, usually, when the error occurs, you can retry the very next moment and it works. Or it still doesn't work several times in a row, and then it works without a problem.

I'm suprised than Paul has not yet followed up on that (I guess he's off for now), but here's the latest I could find about that from RWS: https://gateway.sdl.com/apex/communityknowledge?articleName=000019760

Unfortunately, in my organization, individual users don't have administrative rights to perform a checkdisk (chkdsk /r), but for anyone able to do it, that would be my first suggestion.

 Louis LaBonté 

Louis LaBonté said:

I'm suprised than Paul has not yet followed up on that (I guess he's off for now), but here's the latest I could find about that from RWS: https://gateway.sdl.com/apex/communityknowledge?articleName=000019760

I'm afraid this is the only update we have.  The dev team are still monitoring and it seems to affect some other applications as well.  So far we're not sure this is something we can actually fix so the KB may be the only way to resolve this which means users in some companies will have to raise a ticket and ask their IT to perform the fix for them.

I've also tried chkdsk to no avail, unfortunately.

Even more worryingly, I have a further development to report: "The case of the disappearing sdlxliff".

This has actually happened twice since this set of problems began, but it's so strange that the first time I assumed it was me who had done something stupid.

One day (after doing the chkdsk) I had repeated 0x%1 and 0x%2 error messages when trying to save my file, which were always resolved eventually after trying several times.

The next morning, I went into my project and tried to open my file to continue translating, only to be faced with this: 

When I went into the project file to have a look, the sdlxliff had indeed completely disappeared.

I had no choice but to recreate the project, which fortunately I was able to populate from my TM. Since then I've been very careful to back up my project files in a separate location before closing Trados, but it's a pain to do, and I don't really need the extra stress!

I've been a big fan and advocate of Trados for years, but this issue and the time it's taking to find a solution have me feeling like we're back to the bad old days...

I can confirm this, Caroline. chkdsk did nothing and I have lost several sdlxliff files and even an entire project, not to mention the time I spent to try and come up with a fix. I use the Professional version, by the way.

Louis LaBonté 

I have discussed this with the technical support team as they have been looking at this to see if they can help at all.  The current feedback is this:

1. From researching the web it seems Microsoft knows that the update has issues, but the issues only occasionally/randomly appear. We have only had 3 cases logged for this issue, so there is a limited number of users affected. I think Microsoft needs to identify and fix this issue with their update.
   
   
2. The update is probably automatically deployed so users don’t know or cannot control if they perform the update. Similar to the way we are also managed at RWS, on our computers the updates would be silently deployed by IT, and users only need to accept it.
   
   
3. The fact that the solution we offer via our KB requires Admin rights is not something we can address. In a corporate environment any action requires Admin rights, even installing Trados Studio. We have many articles that cannot be applied without admin rights. The solutions in the KB are for self-service, and users with Admin right will be able to self-serve, the others will need to contact their IT department internally. So most of the installation issues and KBs need Admin rights to be be applied.

I think you know all this already, and I doubt it will get better as there is little we can do on our side to address a problem caused by an operating system update other then than to solution we have suggested.  Quite a tricky one for you, but I'm thankful to see you sharing your progress in case you do happen to find something we have missed.

Thanks for the update, Paul . I always appreciate your straightforwardness, even when the news are not especially good.

I managed to have the 22H2 update removed half an hour ago by tech support (with admin rights) through a Windows roll-back (or “retour en arrière”, in French). Contrary to what Walter Blaser  mentioned yesterday, the time limit is 30 days (not 10), so I had three days left before it ceased to be an option.

I'll let you know if it solves the issue. If so, it would be a good idea to update the article at https://gateway.sdl.com/apex/communityknowledge?articleName=000019760.

Also, for people whose time limit expired for the rollback, it think it would be a good idea to further explore the Known Issue Rollback (KIR) option, which seems to be a different thing, possibly available for a longer period. Some information about that (including for computer ruled by a corporate group policy) can be found at learn.microsoft.com/.../status-windows-11-22h2.

P.S. You said that you have “only had 3 cases logged for this issue”, but I work at the Canadian government's Translation Bureau, where the issue will potentially impact hundreds of people, and I know it already impacts many of us.

I'm not a spokesperson per se, but I'm one of the organization's superusers, and I keep others informed, because they don't have time to come here create an account and individually log the issue. But believe me, it probably impacts (or will impact) hundreds of times the cases logged as of now. 

Louis LaBonté 

Louis LaBonté said:

P.S. You said that you have “only had 3 cases logged for this issue”

Case per customer...we have tens of thousands of customers so in this context it's not a lot.  But I do acknowledge that a single case could easily be for an organisation where hundreds of users could be affected.  The interesting thing though is that it could also be environment based and each customer in their environment has something else triggerring this.

Who knows...these sort of things can sometimes be very hard to resolve.  The main thing is we are continuing to investigate and we also appreciate your support.

 Paul 

For now, the roll-back cancelling Windows update 22H2 works with no issue.

So, considering that it's a non-critical update and that it has caused numerous problems to various applications, I would recommend to anyone having the “0x%1” issue to go for the roll-back (or ask someone in their organization with admin rights to do so), and to avoid reinstalling it at least until Microsoft corrects its flaws.

The sooner the better, since the rollback option has a 30-day time limit. Otherwise, maybe the Known Issue Rollback (KIR) would be an option (including for iorganizations with a group policy), but that would remain to be confirmed. To find information about it, type 22H2 and "Known Issue Rollback" in a search engine, and you should easily find it (the links don't seem to work when I post them on this forum). 

New update: we are having more and more cases of translators sdlxliffs disappearing  from their computers, for example, when trying to finalize their projects. We´ve tried to look for the deleted target xliffs in all the folders we can think of to no avail. Just gone. Any ideas where else to look?
The number of users affected and of scenarios where the bug prevents Studio from functioning properly or at all keeps increasing. Some translators are becoming so frustrated or just afraid of losing their translation and not being able to deliver on time that they are considering not using Studio for the time being until the issues are resolved.
Has RWS been in contact with Microsoft Windows to inform them of these  issues with their latest update and how it affects Trados Studio so that they can find a solution or is it up to the individual users of Trados Studio to directly contact Microsoft Windows to inform them about the issues (Windows 11, version 22H2 known issues and notifications | Microsoft Learn)?
Any developments or news from RWS development team since your last message Paul?
Thank you.

I have the same problem since 3 days. Now I can't return a package without having this error.

I have no issue before and the Windows update was already done. 

Some people in my organization also have the Windows 11 22H2 version without experiencing the bug, but as far as I know, ALL people who experience it have the 22H2 version.

On my end, since the rollback to version 21H2, I have not experienced the bug a single time, while, before the rollback, it happened almost every time I confirmed a segment.

So, at least in my case, the 22H2 version of Windows 11 Enterprise was clearly the culprit.

For reference, here are the exact current specifications of my system (in French), on which I DO NOT have the bug anymore (since the rollback): 

Some people in my organization also have the Windows 11 22H2 version without experiencing the bug, but as far as I know, ALL people who experience it have the 22H2 version.

On my end, since the rollback to version 21H2, I have not experienced the bug a single time, while, before the rollback, it happened almost every time I confirmed a segment.

So, at least in my case, the 22H2 version of Windows 11 Enterprise was clearly the culprit.

For reference, here are the exact current specifications of my system (in French), on which I DO NOT have the bug anymore (since the rollback):