Framemaker crashes during save as PDF with windows 7 event log report MSVCR100.dll exception code 0xc0000417

[bille0906]

I am attempting to create a PDF from several Framemaker book files. Framemaker version is 2015 (13.0.5.547). Each time I try to build the PDF, Framemaker pops up a window saying it has encountered a problem and will then abort the operation without any message to indicate where it occurred or why. Windows 7 (x64) event log consistently shows:

Faulting application is Framemaker.exe version 13.0.5.547

Faulting module name: MSVCR100.dll version 10.0.40219.325

Exception code: 0xc0000417

Faulting module path: C:\windows\system32\MSVCR100.dll

This fault is occurs consistently each time I attempt to build the PDF using File > Save As PDF, and is preventing me from doing my job.

Has anyone encountered this problem and what must be done to resolve it?

[Matt S - Tech Comm Tools]

Hi bille0906, sorry to hear you're having trouble...

Here's the list I put together to prevent crashes, and to speed PDF generation.

Let me know if it solves your problem.

FrameMaker PDF Tips and Tricks - Tech Comm Tools

-Matt

[bille0906]

Matt,

Thanks (if for nothing else, at least commiserating with me). I checked the PDF properties and all seemed in order, except for the font business. I'll give this a try. Problem is that I have 20 folders containing books, 2 or 3 Framemaker documents, and images that are being built into one big textbook. When the build fails, I then need to turn around and remove lck files from every folder. I will try your suggestions when I go to Save As PDF, which may be tomorrow.

[daveg42240029]

Bille -- Did you resolve this?  I'm seeing the exact same issue.  If the temp postscript hits 2.1G, it aborts with the same error. If I modify the FM file and remove a little data, and temp postscript is just over 2G and runs fine.  Seems the 2.1G is a problem, but I'm running on a 64bit machine with 8G of memory.

[bille0906]

DaveG,

Funny you should ask. I am able to generate a PDF when I create a book with fewer modules, too. This seems to point in the direction of hitting a 2.1 GB limit which would be the case with a 32 bit application. As for me, I am running on a Core I7 processor with 16 GB memory.

Direct answer to your question is No, the problem is not resulved.

BillE

[daveg42240029]

Found this ... haven't try it yet as I'm not an admin on the machine (VM box) ...May be worth trying
How To Fix 0xc0000417 Error?

[bille0906]

I checked with my Help Desk team... their impression was/is that the Fix 0xc0000417 provider is trying to sell software.Maybe so. If this is a 2Gig limit issue, then installing a new dll may not do any good because 2 gigabytes is 2 gigabytes. So... I'll see what the Windows and Framemaker gurus can tell from viewing the entrails left from the crashes.

[Bob_Niland]

re: I am able to generate a PDF when I create a book with fewer modules, too. This seems to point in the direction of hitting a 2.1 GB limit which would be the case with a 32 bit application. As for me, I am running on a Core I7 processor with 16 GB memory.

The "Faulting module path: C:\windows\system32\MSVCR100.dll" suggests that you are running on 32-bit Windows. If so, the only way to fix this would be to install 64-bit Windows and re-install FM (which has presumably been 64-bit capable for many releases now).

How much RAM you have is irrelevant, as Virtual Memory can pretend to be more than you have, perhaps up to the free space on your drive. 2147483647 bytes is simply as high as signed integer 32-bit can count. Any thing higher is a negative integer, and could be expected to throw an error on an API call (MSVCR100.dll is Microsoft Visual C++ 2010 SP1 Runtime dynamic link library).

Usually, an easy way to test for .ps or .tps file size being too big is to switch off graphics and see if it renders.

I used to run into this with 32-bit FM on Unix. The only fix then was to reduce the size of some number of graphics imports.

[bille0906]

Hi Bob,

Thanks for your contribution. According to Adobe support, Framemaker 2015 is a 32 bit application that runs on Windows 7 (64 bit edition) in compatibility mode, which is also indicated by Framemaker's install path of C:\Program Files (x86)\AdobeFramemaker2015\Framemaker.exe. It seems perfectly logical for a 32 bit application to use a 32 bit runtime C++ DLL. When I look around my system, I note that MSVCR100.dll is in the system32 directory and, also in C:Windows\SysWOW64, which, I am going to take to mean that it is a 64 bit version of C++ library and would be used when needed by a 64 bit app or any app not running in compatibility mode.

Have you done something to change which DLL Windows 7 would use with an app that uses compatibility mode? If so, would you be willing to share the technique?

Again, thanks for your post.

BillE

[Bob_Niland]

re: According to Adobe support, Framemaker 2015 is a 32 bit application that runs on Windows 7 (64 bit edition)...

Well, that's depressing, considering that x86-64 and 64-bit Windows have now been around for 15 years (and Windows itself got large file support 22 years ago). I would have expected FM (and the Distiller pathway components) to at least special-case filesystem ops for 64-bit. Perhaps they do, and this is some other problem that can be fixed.

re: ...in compatibility mode, which is also indicated by Framemaker's install path of C:\Program Files (x86)\AdobeFramemaker2015\Framemaker.exe.

Yes, there are VisC++ DLLs in the SysWOW64 path as well, but they likely only work with 64-bit apps that conform to their entry point calling conventions and passed/returned data structures (esp. word length).

re: Have you done something to change which DLL Windows 7 would use with an app that uses compatibility mode?

No. Actually, I'm still running FM7 under XP/32 (in a VM inside Win7/64).

[Mayank_Meh]

Hi Bille0906,

I am from Adobe FrameMaker support team and would like to connect with you for the crash issue you are facing. I just sent you a private message. Kindly reply back so that we can look into the issue.

Regards,

Mayank

[bille0906]

Hi Mayank,

Thanks for reaching out. I am currently working with Shashank Shekhar on this issue. Are you working with him as well?

I would gladly work with you, but do not want to discard the data collection and work that Shashank has invested in helping me to resolve this issue. Please confirm where you are coming in to this case, as a next step after Shashank, or; in parallel.

Thanks,

Bill Eshbach

[daveg42240029]

Bill - I'm following alone on this.  Please share with me what you find out.  Just a FYI, guys here with Windows 10 converting the same book are just fine.   In the end, I may need to go that way.

Thanks, Dave

[bille0906]

I understand, Dave.

There are others in my group who can save as PDF the same content I am unable to build the PDF from. Makes me wonder if there is some optimization setting involved.

[daveg42240029]

Anyone making any progress on this.  I even converted to Windows 10, and am getting the same error.  Is there a 64 bit version of Framemaker 12?  It seems to hang on a dll from windows/system32.

Dave

[Jeff_Coatsworth]

Nope, I don't think any version of FM has been re-engineered to run as a 64-bit application. It CAN run in a 64-bit environment though.

[Bob_Niland]

re: I don't think any version of FM has been re-engineered to run as a 64-bit application.

I suspect the tough problems are:
1. recoding for 64-bit-safe is not trivial

2. you still need to have a separate 32-bit version

The entire Adobe code stack for FM might have to be reviewed and re-written to expand 32-bit data structures to 64. FM then relies on a bunch of other code (Distiller and tons more in TCS) that would need review, not to mention whether the result would be stable with any random Postscript driver installed. This is a major effort, and might even be impossible if any source code has been misplaced over the last 30 years.

Had Windows 10 been 64-bit only, it might have been an opportunity, but it's not. Just checking, I was a bit surprised to discover that despite all the other bridge-burning that MS did with Win10, it is still offered in native 32-bit versions. So any 64-bit app for Windows, even if restricted to Win10, also needs to be supplied in a 32-bit Win10 version, unless it wants to impose a 64-only constraint that might surprise many users (such as those stuck on 32-bit due to legacy PCI cards).

Having dual 32/64-bit installs is like supporting multiple platforms, which FM used to be (Win32, Mac, multiple Unix). If Adobe were to add a platform, I suspect there would be more demand for Mac than for native Win64.

re: It CAN run in a 64-bit environment though.

Reportedly, the majority of Windows apps are still 32-bit. So even if some far future Win10.99 is released 64-bit-only, the 32-bit Windows-on-Windows (WoW32) onion skin must remain indefinitely.

If re-writing FM is in the cards for any reason, in addition to restoring Mac support (or adding Linux), I suspect that there's an even larger interest in a complete re-engineering of the graphics engine, to support things like transparency/opacity, deep color, HDR, not to mention restoring stable CMYK.

[bille0906]

Hi Bob,

Yes, it goes beyond simply building/compiling a 64 bit version of Framemaker. One item that you mention, however, is one that I would find really unforgivable: losing source code. While I realize s*** happens, and Framemaker has been passed around a bit, it would still be pretty serious if someone misplaced source code, don't you agree?

Even though I may not agree with you, your input starts some old neurons firing and I start to think about options.

Is it possible that I should start thinking about Windows DLL versions, hardware, or some other factor that would influence my machine to fault consistently around 2.1 GB file sizes?

Bill

[Bob_Niland]

re: One item that you mention, however, is one that I would find really unforgivable: losing source code. While I realize s*** happens, and Framemaker has been passed around a bit, it would still be pretty serious if someone misplaced source code, don't you agree?

We have no idea if that's happened, but it would complicate a 64-bit port, because the elements would have to be:
development-locked, or
restored to deveopmental state by:
emulation at the API level as new code, or
even de-compilation to assembly.

This situation actually happened to a company I used to work for. They lost the source for a whole library. They ended up locking: supporting the library's binary API and runtime across two more CPU architectures, right up until the host OS itself was end-of-lifed. They'd actually dug the hole extra deep, because they were contractually obligated to provide the source to one or more key customers if they discontinued the feature. Oops. The binary keep-alive gambit worked, fortunately. And no, the lib never did get ported to 64-bit

I've also worked for two companies that lost the source for manuals, and had to regenerate them from scans of surviving hardcopy. One of those efforts required buying some expensive early OCR equipment (fairly capable OCR, of course, is now included as a freebie with low-end scanners and cheap MFPs).

re: Is it possible that I should start thinking about Windows DLL versions, hardware, or some other factor that would influence my machine to fault consistently around 2.1 GB file sizes?

I think we need to start with these questions about FM2015 (and 2017), and for which I don't know the answer:

1. Are newer FMs supposed to be able to open, read and write large files (over 31bits)?

2. Are there size considerations for other elements of the output workflows: Distiller, RH, Postscript driver?

The file types of interest might include .ps, .tps, .mif/.recover and .fm. Of these, the MIF (and recover is a MIF) would tend to be larger than the Postscripts (.ps & .tps), which would be larger than the .fm binaries. So if FM crashes on a 32-bit .tps file, I'd be unsurprised if crash itself crashed, because the .recover might also be over 31 bits.

If the answers are no(1) or yes(2), then I would not expect any DLL hacking to provide a solution.

[bille0906]

Still working with Adobe Support on the issue I reported. There have been no updates to date.

BillE

[Mayank_Meh]

HI Bill,

Thank you for informing. You can continue working with Shashank. I will check with him about the progress.

Regards,

Mayank

[Matt S - Tech Comm Tools]

Pardon me if this has already been suggested, but this thread is getting LONG...

Have you saved a .ps file using the Adobe PDF driver?

I occasionally need to go the .ps route with large files. Not only have I always gotten it to work (eventually), it cuts down the time to restore Fm editing capability to no more than a minute or two.

In sharp contrast, I've often been locked out of editing for hours with the Save As PDF route, even when the processing of the PDF via Distiller takes only a few minutes.

[bille0906]

Hi Matt,

Maybe this thread is getting long because this problem is not resolved. There is no root cause, there is no workaround, thus far; there is no answer. When there is an answer to the issue, I will glve proper attribution to the person who has the correct answer and the thread can be closed.

Hope that's okay.

Bill

[daveg42240029]

Bill -

I am currently working with Adobe.  The error that EventViewer kicks out about MSVCR100.dll  is bogus.  Adobe told me that FM kicks out an error, and the error code just happens to match up with that error message. He said that FM doesn't even use that dll.

Sure enough, I temporarily rename the dll to dll_keep and rebooted.  When it started up, a few programs complained that the dll was missing, so I know nothing was seeing it.  I ran FM on my book, it died at 2.1G, and kicked out the same error about that dll.

Adobe sent me a trial FM17 to test if it has trouble converting the book.   If it works, then they will work on a fix. I'll keep you posted.

[bille0906]

Dave,

That's good news.

I have a call with Adobe later this morning. Hopefully, the same story will be told.