XMetaL stops responding when trying to generate a file

[carmstrong]

I'm using XMetaL version 6.0.2.070. Anytime I try to generate a document, XMetaL stops responding. I don't get an error or a time out in the Generating Output window, but it never completes the file generation. However, when I look at the destination folder, the completed file is there. I'm trying to determine if it's a PC issue or an XMetaL issue. Thanks.

Reply

[Derek Read]

I'm going to assume you are running XMetaL Author Enterprise and that you are working with DITA content. Let me know if that is wrong.

I think the best you can do would be to do the following (in this specific order) to try to correct any issues with XMetaL Author Enterprise.

These assume that either something in the currently running (in memory) copy of files XMetaL Author Enterprise is using is corrupt, or one or more files it loads when starting up or generating output are corrupt:

1) Reboot your machine.

If that fails to fix the issue try…
2) Redeploying the DITA Open Toolkit by following procedure (a) or (b) here:
http://forums.xmetal.com/index.php/topic,237

If that fails to fix the issue try…
3) Repair the installation:
Windows Control Panel > Add or Remove Programs > select XMetaL Author Enterprise > click “Change” > select the “Repair” option.

If that fails to fix the issue try…
4) Uninstall then reinstall XMetaL Author Enterprise.
Note: If you have any 3rd party software installed (anything that modifies the XMetaL Author Enterprise installation, including CMS integrations) then check with the 3rd party as to how to uninstall / reinstall. The basic order should be:
a) Uninstall 3rd party software.
b) Uninstall XMetaL Author Enterprise.
c) Install XMetaL Author Enterprise.
d) Install 3rd party software.

Reply

[gcrews]

Sounds like the output hang /crash issues we continuously run into.

http://forums.xmetal.com/index.php/topic,2836.msg7291.html#msg7291
http://forums.xmetal.com/index.php/topic,971.0.html

Does Xmetal also go to 100% CPU usage (or 100% divided by # cores)?  Does the output dialog appear but no “green” progress indicator shows? If so, sounds like it is the same exact issue we used to have about once a week where you would have to reboot the computer once or twice.  Sometimes rebooting once didn’t solve the issue, sometimes it did. Sometimes killing a few processes would fix it, sometimes it would not.

I have not seen the issue in over 2 months now for us so I’m not sure what fixed the issue for us.

Out of curiosity, is your PC a Lenovo?

Reply

[gcrews]

Looks like I spoke to soon, the problem has not fully disappeared for us. Last week on Monday it was happening for one of our writers.  Today (Monday) it was doing it for me now after being ok for about 3 months. I haven’t generated many outputs in the interim though.

This is very frustrating; it’s become a running gag with me and our writers.  Writers call me over and show me outputs not working, I say yup got to reboot. It’s been doing this for years not with Xmetal 6, and 7.

All I have been able to tell is is is something in CSSToXSL.dll.  Another morning wasted trying to resolve this stupid issue…

Reply

[Derek Read]

Sounds like we have two completely different issues here, we might even have different products (XMetaL Author Enterprise vs Essential).

carmstrong is discussing generating output from DITA files. It does not use CSSToXSL.dll at all, it uses the DITA Open Toolkit. The XSLT is fixed (never changing) and it is never generated by CSSToXSL.dll. Various moving pieces can cause this issue, and which problem it is invariably depends on which of the over 1 dozen or so output formats being generated and the current state of the system (locked files by 3rd party software — most commonly an Adobe tool) and possibly other factors. In this case the product must be XMetaL Author Enterprise.

gcrews is talking about generating either HTML or PDF using functions defined in the multipleOutput.mcr file in Startup (nothing to do with DITA or the DITA OT). This is done via XSLT fed into either MSXML or Apache FOP and is configured to mostly work out of the box but by writing a little bit of additional script. The XSLT can be auto-generated for you by CSSToXSL.dll but you don't have to do it that way. That process can be modified by changing multipleOutput.mcr or by implementing your own transform process (and removing that MCR file). If you really think it is CSSToXSL.dll that is getting stuck you could confirm that by debugging to check that the XSLT is not being generated each time output is produced. The way it was designed to work (long long ago) is that once the XSLT has been generated once the code in multipleOutput.mcr is supposed to notice that the XSLT files are already there and not do it again. The multipleOutput.mcr should be fairly easy to debug if you can find a reproducible case.

Reply

[gcrews]

carmstrong is discussing generating output from DITA files. It does not use CSSToXSL.dll at all, it uses the DITA Open Toolkit.

Bull, generating output from DITA files clearly uses that culprit CSSToXSL.dll.

gcrews is talking about generating either HTML or PDF using functions defined in the multipleOutput.mcr

No I'm not, I'm talking about when you “Generate output for DITA Map/Topic”.

Reply

[Derek Read]

OK, I'll have to investigate further and actually look at our code. The reason CSSToXSL.DLL was created was to aid with auto-generation of XSLT in order to allow people to more easily generate either PDF or HTML from any XML format. I estimate (from memory) that it was created around 2002 or so, long before the DITA OT or even DITA (in public form) existed. So, if it is being called in this instance then that is in error as far as I can tell. I can see no reason for it to be run or come into play at all.

Just got back from vacation today so will be in the office Monday and I can investigate then.

Reply

[Derek Read]

[Since this is apparently a DITA output issue it should be on that board (carmstrong never confirmed that but I guess we can safely assume so) — moving it to the “DITA and XMetaL Discussion” board]

Reply

[Derek Read]

Looks like we did add some functionality into CSSToXSL.dll around the time of the 5.0 release. There are a couple of additional functions it now contains related to duplicating folder tree structures and files. That is usually done before handing them over to the DITA OT for processing, so when generating output using the DITA OT this DLL does in fact get called.

None of the functionality that CSSToXSL.dll was originally designed for is used (ie: generating an XSLT file based on a CSS and a DTD) but this file management stuff is. So, gcrews is correct, CSSToXSL.dll is being called but not for any of its “real” functionality which is what I was assuming. None of this is easily discoverable so I had to go to dev to find this out.

A standard Windows System API “SHFileOperation” is suspected as a possible reason for the failure you are seeing. There are claims that this Windows API might function badly on newer versions of Windows (Vista / 7), and perhaps in particular on 64-bit systems. If that is true then it is possible that Microsoft could correct the problem at some point. It could very well be that we need to alter our code however, but in that case we need to be able to reproduce the issue here.

We don't know specifically if it is this Windows API that is causing the issues for you because we can't reproduce the problem in-house yet. If you want to help track this down XMetaL Support may be able to provide you with a debug build that you could run to provide information back to XMetaL development.

Reply

[QuadricRiddler]

Looks like we did add some functionality into CSSToXSL.dll around the time of the 5.0 release. There are a couple of additional functions it now contains related to duplicating folder tree structures and files. That is usually done before handing them over to the DITA OT for processing, so when generating output using the DITA OT this DLL does in fact get called.
…
We don't know specifically if it is this Windows API that is causing the issues for you because we can't reproduce the problem in-house yet. If you want to help track this down XMetaL Support may be able to provide you with a debug build that you could run to provide information back to XMetaL development.

I am experiencing carmstrong's issue also on todays newly delivered and configured Hp laptop (Win7 x64, XMetal 6.0.1.030).
Posting the screendump of process information of my analysis.

Reply

[Derek Read]

Hard to give an answer here as the 6.0 release wasn't supported on 64-bit versions of Windows. I would also expect it to have more issues that just this one.

Development tells me they corrected quite a few problems with the software when running on 64-bit Windows. One of the major areas they worked on for the 7.0 release was 64-bit support. They corrected a number of problems with the 7.0 release and possibly some more with the 8.0 release.

Whether any of those fixes will address this particular issue I'm not sure as I have yet to see it myself. The nature of the things they were mostly working on for the 7.0 and 8.0 releases weren't always directly reproducible either, a general code review in the context of “do we need to change this for 64-bit” was done and so I don't have specifics for those things.

It would probably be a good idea to be using a supported version (currently 7.0 or 8.0). Then if you find a specific reproducible case you can submit it to XMetaL Support.

Reply

[QuadricRiddler]

Yups. I have already initiated migration to Xmetal 8. The trial version behaves okay.

With regard to the  Xmetal 6, the freezing issue may seem to be overcome by clearing the UserAppDataLocalTemp dir.

Reply

[gcrews]

Interesting, I will try that next time it starts happing on my computer with Xmetal 7. I don’t think would cause the issue though; I suspect it just happened to resolve itself at that moment. I suspect XMetaL 8 will have the same issue to, but it just hasn't happened yet. It only seems to happen on my computer about once every 2-3 months now and sporadically resolves itself. 4 coworkers have had the issues just this week though.

• Monday – output was causing not responding for  one user
• Tuesday – One person got blue screen, another user was getting not responding.
• Wednesday – another user was getting not responding.

It’s not nice when a program makes you reboot being its acting up.  I suspect some code in that CSS DLL is relying on some memory being zeros by default when it’s not. It’s the only thing I can think of that would cause the sporadic  issue. This has been going on your years for us it’s really annoying.

Yups. I have already initiated migration to Xmetal 8. The trial version behaves okay.

With regard to the  Xmetal 6, the freezing issue may seem to be overcome by clearing the UserAppDataLocalTemp dir.

Reply

[Derek Read]

This offer still stands for anyone that is seeing this as an ongoing issue: “If you want to help track this down XMetaL Support may be able to provide you with a debug build that you could run to provide information back to XMetaL development.”

Note that if you are running version 7 or 8 then you have a build capable of being run in debug mode already. You just need instructions on how to generate a dump file and where you can send it and how to obtain procdump.exe (from Microsoft) and the right command line to run it.

Reply

[QuadricRiddler]

Derek,

I am willing to volunteer in tracking this issue with a debug build of XMetal 6 for testing under W7-x64.
You have my email address to notify me on getting that version 🙂

Q.

Reply

[Author]

Posts