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?

[daveg42240029]

My trial version of FM17 died too.  Same error ...

With frame12, it died when file reached this size ..

2248397882 Apr  4 19:35 STL_Vol1.temp.tps

With 17 ..

2254875729 Apr  6 08:03 test.tps

Faulting application name: FrameMaker.exe, version: 14.0.0.361, time stamp: 0x587f39d7

Faulting module name: MSVCR120.dll, version: 12.0.21005.1, time stamp: 0x524f7ce6

Exception code: 0xc0000409

Fault offset: 0x000a46a9

Faulting process id: 0x2b58

Faulting application start time: 0x01d2aee3e40fe463

Faulting application path: C:\Program Files (x86)\Adobe\Adobe FrameMaker 2017\FrameMaker.exe

Faulting module path: C:\windows\SYSTEM32\MSVCR120.dll

Report Id: fa9ac6b4-f6ab-41b0-be13-8ebe49d0f9fe

Faulting package full name:

[daveg42240029]

Bill -- Any luck on your end?  So far, nothing has worked for me.

Dave

[bille0906]

As yet, nothing. I am going a new hardware route. New computer, new Framemaker install, only difference is that the laptop will be Win10. Fresh system eliminates many variables and, of course introduces a few new ones. But at least we start from a known point. I am finding that other folks in my workgroup have the same issue as me. They get to a 2.147 or so threshold and FM falls over. One variable appears to be using CMYK to build the PDF. RGB seems to build using smaller intermediate files. Unfortunately, parts of my content did not render without using CMYK. That content has been changed.

[daveg42240029]

Thanks for the reply.  I was running on a Win7 64bit machine.  I also tested on a new Win10 64bit  and the same error.  Working with Adobe, they sent me a trial of FM17 (I use FM12), and still the same.  Then they had me load up some mif dll that would do a mif wash of the book/chapters.  Didn't work.  I keep mentioning this forum thread, how you are seeing the exact same thing, unrelated book ... company for that matter.  But they don't think the 2.1G is the problem ... I asked if they could build a testcase where their postscript (.tps) exceeds 2.1G and see what happens.  We'll see if they do.  I can't send my book because of company security policies. ugh...

[bille0906]

From what I understand, they can reproduce my issue and are looking into it. I need to produce good courseware. Meanwhile some of us here believe the template we are using could be at fault. Will let you know.

[Matt-Tech Comm Tools]

Have you tried saving a test version of your doc and removing all graphics from body, ref, and master pages?

If I were testing this, I'd selectively remove "types" of graphics (screenshots, PDFs, WMFs, etc.) and I start with graphics that are historically subject to corruption (WMF, OLE) then move on to EPS, TIF, JPG, then finally remove PDFs, AI, and PSD.

Not fun, but I'd wager you can isolate the problem from there.

[FabianK007]

Hey,

Also having "MSVCR100.dll" as faulty module while my FM publishing server tries to create PDFs, I stumbled upon your post.
The issue only occurs when FM is trying to access "AppData\Local\Temp". Changing the environment variable or clearing the folder resolved the issue.
I hope this helps anyone who may stumble upon this page as I did.

Kind regards,

Fabian

[Be.eM]

Fabian,

you mean changing the environment variable for the Temp folder, i.e. pointing it to a different folder solves the problem? We have this problem here with a few documents, reproducible on several FM2015 installations in Win7/64 Pro. Finding a solution would be perfect…

Bernd

[FabianK007]

Hi Bernd,

We found the solution because we could not reproduce the issue when operating the PC via RDC. When accessed remotely, the user uses a subfolder, in our case "\Temp\2".
We had the choice between finding what's causing the issue in Temp, or changing the environment variable, or deleting everything in Temp.
We opted to delete everything.

Regards

Fabian

[Be.eM]

Hi Fabian,

I've tested it by modifying the environment variable (to "/Temp/Test"), restarted the computer and started a PDF creation with a document that reproducibly crashes in FM2015 when doing so. Unfortunately this crash still happens, and it seems definitely tied to reaching 32-bit limits. There is a leftover *.tps file on the server, which reached a size of about 4.38 GB, and the content of the newly defined (and previously almost emtpy) Temp/Test folder is now also about the same size (4.14 GB). This is exactly what a 32-bit process would do. I'm afraid cleaning folders or modifying the environment variable doesn't solve it. It just creates a more or less empty folder to start with, so you can create more temporary files until you reach the 4 GB limit.

An interesting fact in addition: Throwing that 4GB *.tps file onto Distiller creates a perfectly fine PDF file. This has been working before, too (no change by the environment variable). Of course this brings up one question: if the *.tps is sufficient for a complete PDF file, what is it that FrameMaker still wanted to write to that *.tps file, which made it finally crash?

Bernd