CDR Tickets

This was working on QA before today?

This is on QA

I get the same on PROD.

I get the same on PROD.

Yes, this is happening only to one user (Isabel Lansberry).

We can reinstall XMetal but it is strange that is happening only on QA and PROD and not on DEV.

I received the same message just a little while ago when I logged into PROD. I was unable to search for documents. I logged out and logged back in. Upon my second log in, I did not see the error message and everything appears to be working as usual.

Has she tried the trick of resetting XMetaL? (I don't remember the keystroke combination to be held down at startup, but I bet you do.)

Thanks ~juther. She's logged in and out of the CDR several times and even restarted her laptop a few times as well but the issue still persists. We may try to reinstalled XMetal to see if that resolves the problem.

It is SHFT-CTRL to reset XMetaL.

~oseipokuw, is this issue limited to GTN documents or are other document types affected as well?

Can we set up a screen-sharing session with Isabel on Teams, ~oseipokuw?

It affects all document types. It seems to affect drop down lists and cases where she has to do Ctrl + Enter to bring up a list.

CDR is working for the Isabel this morning. We did not have to reinstall XMetal even though there was already a ticket to do so. She turned her laptop off completely overnight and then this morning she was able to access the CDR without the errors she encountered yesterday. For whatever the problem was it looks like the laptop needed a very good night sleep and not just a short nap 🙂.

Sounds like Isabel was working too hard last week.  Laptops have feelings, too. 🙂 

Great to hear that Newton isn't to blame for those feelings.

Pleasant dreams!

I would have used "Can't reproduce" instead of "Won't fix" as the resolution, as the problem fixed itself. 😉

I have updated the ticket to say Can't reproduce" . I considered that too but I also thought we were able to reproduce the problem several times. Maybe we should have another option "The Problem fixed itself" 🙂

I have reopened this ticket because another user Pedro Bringas Casado, our new translator, is experiencing the same issue. He does not see the initial error message upon log in but does experience missing list items and he is unable to use the ctrl + enter macro. He restarted both the CDR and his laptop to no avail. He is leaving for the day so I will check with him again on Monday whether the problem is resolved or not but it is turning out to be a more widespread problem than initially thought and I am yet to send out the email to all users.

Crystal experienced the problem this morning. She was able to work normally after restarting. Christina also experienced the same problem about an hour ago, the CDR worked after restarting as well.

Let me know if you get any more reports today (or Monday) and we'll try another remote diagnostic session.

Sure. Pedro's CDR is still showing signs of the problem this morning. I will send you a Teams' invite.

I've cleared my calendar so I can be available for this whenever you are.

I already sent you an invite in Teams.

Any chance you sent it to one of the other Bob Klines at NCI?

Ah, I see it. Your name didn't show up in the left panel.

Looked at Robin's machine after yesterday afternoon's status meeting, as it was exhibiting some of the symptoms connected with this issue (error message about an invalid document at startup, empty document type picklist for the search dialog, and missing valid values dialogs). The evidence points to a failure of the DLL to parse and extract information from the CdrDocTypes.xml file when it starts up, and one theory was that this file gets replaced as the user switches tiers or when a new DLL is deployed, and the file system hasn't finished unpacking the file from the zip archive retrieved from the server, making the file unreadable. However, the file was clearly present, and Robin had not been on a different tier for her previous login, and that login has been after the Newton release. I will try to add some additional debug logging and hope we can reproduce the problem on the lower tiers.

I have no idea how to estimate the LOE for this ticket, as we don't know enough about what's causing the behavior.

As I was investigating possible ways to capture more information about the causes of these random failures by adding more debug logging I found a bug which has been around at least since CBIIT took over our hosting back in 2013 (and probably much longer than that), and is a plausible candidate for the cause of the behavior reported by this ticket. It's the kind of bug which is triggered by the (seemingly) random content of the memory directly adjacent to a buffer the software is populating, which means that the bug does not occur all the time, and conditions which are unrelated to what the currently running code is doing and which can be affected by countless factors over which we have no control (for example, what's in the machine's environment variables, including those unrelated to our software) can determine when and how frequently the bug is triggered. I have fixed the bug (and added more debug logging) on CDR DEV and CDR QA.

... probably much longer than that ...

Indeed, this bug will be 15 years old tomorrow. 😛

Closing this ticket because no issues have been reported since the hot-fix. Thanks!

~oseipokuw I tried calling you through Teams to follow up on the report of a DOM failure in XMetaL this afternoon, but didn't get a response. Is this the ticket for those failures, or is there another ticket?

I have reopened the other ticket OCECDR-5014