CDR Tickets

I'm investigating. What does it mean for an <Insertion> element which was marked as "approved" back in March to contain nested <Insertion> and <Deletion> elements marked "proposed" in April? I'm tempted to see what happens if I resolve the "approved" wrapper markup, but I want to understand what it was trying to do first. Is this a common thing to do?

Can you please provide step-by-step instructions for reproducing the problem? I just opened CDR792691 on DEV in XMetaL without any problems. I

1. logged on to CDR DEV in XMetaL

2. clicked on the "ID" icon ("Retrieve") on the CDR toolbar

3. entered "792691" (without the quote marks) in the "Document ID" field

4. clicked the "OK" button

5. saw the document come up without errors in read-only mode

It is the same steps above I use to open the document but in my case when I click OK, the CDR attempts to open the document and disappears. I will connect via Teams so you can see it.

This is not a common practice but it does happen in cases where multiple people review/QC the document before the document is finally reviewed, markup accepted and the document made publishable.

I think you're going to need to open a ServiceNow ticket. Best theory I can come up with is that some sort of intrusion detection rules are in place, dropping packets on the floor when it sees something it doesn't like. No idea why it affects different machines differently. Presumably different rules for different client machines?

I have reported the issue but there have not been any response yet.

The same user(Isabel) who first experienced the problem has reported another document. This time it is a GTN document 256553 (PROD). These documents have are still checked out to her and there is no way for her to check them in or for me to force a check in. I wonder if you can force the documents to be checked in or not or whether it will help in any way.

Adding a data point here:

I have opened the same document (CDR256553) and it crashed my XMetaL.  Then I opened the oldest version of the document that didn't crash XMetaL - version 16 - and compared it to the next version of the document.  Version 17 has the following text added, no additional differences exist between those two versions:

{}<TranslationResource>DTM</TranslationResource> {}{}<TranslationResource>García-Foncillas, et al. Conceptos básicos en biología molecular del cáncer. Susceptibilidad genética. ANALES Sis San Navarra 2001, Vol. 24, Suplemento 1 https://www.researchgate.net/profile/Eva_Bandres/publication/289349866_Basic_concepts_in_the_molecular_biology_of_cancer_Genetic_susceptibility/links/5629fa2f08ae04c2aeb14bab/Basic-concepts-in-the-molecular-biology-of-cancer-Genetic-susceptibility.pdf</TranslationResource>{}

Good sleuthing. So does CIT believe that the presence of the string "susceptibility" represents a security susceptibility in the data? You might want to pass this along to the folks handling your ticket, ~oseipokuw. As an FYI, he last time we ran into similar failures (security rules causing packets to disappear, resulting in mysterious failures in our software) was back in January, and Aaron Taye and Tommy Ming were the ones tracking down the problems (not sure which team(s) they're on, but they're CBIIT, I'm pretty sure).

Also adding another data point. While I am not able to retrieve the document in XMetal, I am able to see the XML using the  Show CDR Document XML report to retrieve the XML. I am not sure what that means but it is getting very exciting 🙂.

I unlocked one of the documents (256553, I think), but then my entire Terminal Server session froze up, so I'll try the rest tomorrow.

I don't think it's that simple.  Looking at the other two documents I don't see that string "susceptibility" as part of the documents.  I did compare those GTC documents with these differences of the GTN document but I can't see anything obvious that they share.

William, you might want to test if you can add a copy of the above TranslationResource to another document - try is on DEV first - and see if that makes XMetaL crash after the save.  If that crashes XMetaL we would have a reproducible sample.

I created a ticket which is currently assigned to David M from the CBIIT application support team. I have been contacted by David M. His initial response is that we are using version 9 of the software when the latest version is 16. He seems to think that this version of the software is not fully supported by the new windows operating system.

As I continue to look into this, I wanted to mention one red flag I’ve noticed – Xmetal Author Essential is version 9.0 which is quite old.  The base application (not CDR customized) was last updated by the vendor in mid-2014.  Latest version of Xmetal appears to be 16.0.

 

I’ll keep researching to see if there is anything we can do from the desktop administration side to resolve this but it may be the case that this software component needs to be updated.

David

Often times, more than just feature updates are included in later versions of the software.  Deprecated software is not maintained for current OS compatibility.  According to the vendor’s ftp download page, version 9 was not designed/tested to work with anything past Windows 8.  In my experience, most software that worked on Windows 7 works on Windows 10 but when it doesn’t, and the vendor no longer supports the software, it can make troubleshooting very difficult.

The vendor has a system requirements page for Xmetal but I assume this is for current version of the application: XMetaL System Requirements

 

I’ll keep digging to see if there is anything else I can find.

He also thinks that this is not likely an IDS issue because it would happening to all machines and not some. 

In any case, I have scheduled a troubleshooting session with him at today at 2:30PM. We will uninstall and reinstall XMetal to see if that helps. But generally CBIIT is unwilling to support applications when they think we are using a dinosaur era version of the software 🙂

OK, let's add the XMetaL upgrade to Pauling.

OK. Will do.

Reinstalling XMetal did not work. However, Windows recorded an error in the event logs each time the application failed. David M. is going to research what he can find about the error message. I am posting a screenshot of the log from the event viewer here:

Hi ~bkline This is what David M. said about the file that is causing CDR to crash. I am wondering if you have any idea what this file is?

"The WT10LI.dll file is located in C:\Program Files (x86)\Corel\Shared\XMetaL\Writing Tools\10.0.  I  have no idea what the file does or why it would cause Xmetal to crash when accessing those specific documents.  I’ll continue to look for differences between the specified systems to see if we can, by process of elimination, figure something out but this may be difficult."

That's one of the DLLs included with the XMetaL distribution.

Hi ~bkline  Could you please force unlock these documents 792693, 256553  and 792691 ?

Done.

Could you please unlock 792691 from Isabel's account?

Done.

Bob and I spent some time to look into these XMetaL crashes and we've been able to eliminate a couple of possible causes for the crash along the way.  We have found that XMetaL crashes when the document contains a single word that is longer than 81 characters!!!  The document in question CDR792691-V20 contains a URL in the element DefinitionResourse with a much longer "word":

• what_is_bile_duct_cancer_cholangiocarcinoma_what_are_causes_and_risk_factors_for_bile_duct_cancer

XMetaL sees this as a single word (no spaces) and it causes the crash.

Apparently, a user at CIAT fixed this problem and removed/shortened the link which prevents XMetaL from crashing.  However, this finding hasn't been included in this ticket although it would have been useful debugging information.  Anyway, we have identified this long word to be a problem but as we know, not every user experiences the crash.  ~bkline, for instance, can't recreate the crash on his machine but I myself can.  We noticed that Bob's machine has 8GB RAM while my machine has 4GB RAM.

~oseipokuw, I'd like you to go around to your users with a little survey to answer the following questions for each:

• How much RAM is on the machine (Open File Explorer; Right-click "This PC"; Select Properties;  Select the "About" tab; Look for "Installed RAM")

• Open the document on DEV in XMetaL:  If 4 GB RAM does XMetaL crash?  If 8 GB or more does XMetaL crash?

When we have this information we will think about next steps - possibly upgrading XMetaL and try with a recent version of XMetaL.

Pedro and I were able to retrieve the document on both PROD (CDR792691 version 20) and DEV (CDR0000806053) without any issues.

It appears that the problem only kicks in when the spell checker is running.

And the reason Volker's Windows VM showed the problem and mine didn't had nothing to do with the amount of memory installed on the machine, but on which dictionaries were installed.

I had typed up this comment but didn't submit it...

I believe I found the true reason for the XMetaL crash.  It seems that it is the spell-checker used by XMetaL.  This would explain the differences in behavior we've seen:

• XMetaL doesn't crash for everyone.  If you have the spell-check turned off there is no crash.

• XMetaL appears to crash when loading a document.  This is true when a document's spelling is checked when it's opened.

• XMetaL crashes for long words.  The spell-checker cares about words.  

• XMetaL crashes when typing a word - not when loading a document.  This is only true when the "spell-check as you type" option is on.

Also (as noted below) it makes a difference which dictionaries you have installed.

So, is it the relatively recent update to the spellchecker that may be causing this issue? I remember, they had to write a quick patch for XMetal 9.0 support not too long ago.  Or it is one of the new dictionaries we created for the Spanish team that may be causing this?

Yes, it is related to the new Spanish dictionary file we added.

There are 5 different dictionary files in 3 different formats we're using, a *.mor, *.lex, and *.dic format.  If I turn off our new Spanish dictionary (.dic format), the spell-checker does not cause a crash.  I also copied the Spanish dictionary to my local drive and see the crash if I only use the Spanish dictionary file.

We also know now that the existence of a super-long word doesn't crash XMetaL and it's possible to use the spell-checker in a document with a super-long word as long as that word isn't checked!

Just to confirm that there is nothing wrong with the Spanish *.dic file itself, I took that dictionary file and added it to MS-Word.  I don't see any issues with the spell-check on Word but Word stops spell-checking once a word gets longer than 62 characters long.

I am able to retrieve the affected documents without CDR crashing (it used to crash for me). I checked and I don't have any of the Spanish dictionaries/spellchecker installed currently. I definitely had them installed at some point but I don't know when I removed them. What surprises me though is that Linda has the Spanish dictionaries installed but she never ran into the crashing problem when retrieving the same docs while Isabel, who also has the Spanish dictionaries installed always ran into the crashing problem with the same doc. One thing that is clear is that if you've not touched the Spanish dictionaries, you wouldn't run into the crashing problem.

If you don't have the Spanish dictionary setup you won't see the crash.  

The difference between Linda and Isabel may be that Isabel has the spellcheck run "as you type".  This will perform a spellcheck when you load the document in order to create the squiggly lines under a misspelled word.  If that option isn't turned on you have no issue to load the document.  XMetaL will not crash until you start the spellchecker and reach that super-long word.

The problem of crashing XMetaL when using the Spanish dictionary file has been corrected when using the latest version of XMetaL.

We have identified that our current version of XMetaL 9.0 crashes when using the Spanish dictionary files (es.dic, es.aff) on a word that is longer than about 80 characters.

The latest version of XMetaL (17) corrects this issue by ignoring any word longer than 60 characters to be spellchecked.  Since the upgrade of XMetaL to version 17 is part of the Pauling release and we have work-arounds to avoid the crash, we won't try to investigate or correct this issue any further.

I have been testing this issue on the VM/XMetal 17 and I experienced crashes each time I try to retrieve one of the two documents 792693 with Check Spelling While Typing checked. If I uncheck that option, CDR does not crash. I am not sure what else needs to be done about this.

~oseipokuw , you are saying "... each time I retrieve one of the two documents..." but you only list one CDR-ID.  Which is the other document?

I opened CDR792693 while the option "Check spelling while typing" is turned on and XMetaL 17 does not crash for me.  Could you please send a screenshot of the General options you have checked and a screenshot of the enabled spellcheck files?

The other document is 792691. I did not provide that because it is already in the original comment for this ticket and I did not test with this document in XMetal 17. I have attached the screenshot. Please let me know if you want me to do a screen share with you. 

I have the same options set but I have additionally the option: Replace words from my word list while typing

I was able to open both documents (CWD) without a crash.

Could you please show me which dictionary files are included for you?  Are you opening the documents in read-only mode or read/write?

I checked the Replace words from my word list while typing and it still crashes for me. I am opening in read-only mode. This is how my setup is linked to the dictionaries.

What is the file "dic_medicos.dic"?  I don't have that linked.  I have instead the file "es.dic".  However, I have it locally and am not using the network copy.  What is the reason for using "dic_medicos.dic"?

Try to switch it and check if XMetaL is still crashing.

Unfortunately, it still crashes after switching the files. 

OCECDR-5025 explains the files. I am not sure about the es.dic file. It is probably the same as the medicos file. I think it is the data you found on github or so.

Yes, you're right.  The "medicos" file is the medical dictionary in Spanish but it's not the same as the file es.dic.

Does your XMetaL also crash with only the standard dictionaries? (uncheck all but the *.lex files)

No. My XMetal does not crash with the standard dictionaries.

I also copied the Spanish files to my desktop and linked them there and XMetal still crashes even if the Spanish files are linked locally.

Can you tell which of the Spanish dictionaries is the one that is causing the crash?  You'd have to add them one by one.

I will try to add the "medicos" dictionary to see if that makes my XMetaL crash.

I tried each individual Spanish file with the regular English STEDMANS files also removed and XMetal still crashed. All along, I have been testing with only CDR792693 so maybe I will try to test with the other document to see if there are any differences.

I am wondering if the crash is related to another CSS issue rather than the dictionaries but you said you were able to make the crash go away by unchecking the "check as you type" option.  I'll dig a little deeper on this one today.

It still crashes on DEV but not on QA when I tried today. I am marking IT as DEV Verified because it least it works on QA.

I have not been able to recreate this on behavior on QA. 

Verified on PROD. Thanks!