During october-novermber I installed Windows 10 in parallel to the existing Windows 7 (dual boot) and discovered some strange things with this OS - although I postponed the transiton some years. I hoped that these faults and annoyances will disappear once I have a single-OS system (Win10 on the first partition replacing the old system). But no...
Save as PDF (in FM-22.214.171.1241) is set to use the PDFL. In about 1 of 4 processes to create the PDF of a particular book the last book file is not finished and FM just disappears into the blue without message or dump. In the Windows Reliability monitor I then see this information:
Problem Event Name: BEX64 Application Name: FrameMaker.exe Application Version: 126.96.36.1991 Application Timestamp: 5d540b1d Fault Module Name: MSVCR120.dll Fault Module Version: 12.0.40660.0 Fault Module Timestamp: 577e0cc7 Exception Offset: 0000000000074890 Exception Code: c0000409 Exception Data: 0000000000000007 OS Version: 10.0.183188.8.131.52.256.48 Locale ID: 8192 Additional Information 1: e465 Additional Information 2: e465c6ab898a83cdc3475f3520c2a007 Additional Information 3: aec2 Additional Information 4: aec29a6a17c5d7c27264393a75a28be0
Somewhere I read that BEX stands for "Buffer Overflow Exception", but this may be an urban legend. Anyway: I never ever had this problem in Windows 7!
I know that the faulty module (MSVCR120.dll) is part of a MS Visual C++ Redistributable package - and the module version (12.0.40660.0) points to Visual C++ Redistributable Packages for Visual Studio 2013 - but it does not tell whether the 32-bit or the 64-bit variant is meant. Both have the same version.
While I do not lose any data with this fault, the left overs (all book files are leaving a lock file) must first be removed, before I can try again.
Any ideas how to get rid of this?
There is internet chatter that seems to confirm your description of BEX, and suggesting that if allowed, turning off DEP for the offending app might dodge the crash.
I'm not running Win10 yet, so unable to confirm if this is the dialog path:
Control Panel » System Properties » Performance Options » Data Execution Protection
Odds of it accepting the change, and working, don't appear high. In any event, if it does, it would appear to be hacking a bug.
These issues are many a time caused due to .Net update or Windows update.
Is there any pending update ? or just try to updating .Net version.
I sometimes get these unexpected closing of the app but Updating pending windows update resolves the issue for me every time.
After reading your post I got notice from Windows:
So I will observe the situation.
… But this update did not help either. So I searched for the old msvcr120.dll and found it in C:\Program Files (x86)\Common Files\Adobe\OOBE\PDApp\DECore\
I copied the newer version from C:\Windows\SysWOW64\msvcr120.dll
Lets look, whether this cures the problem.
It seems that this (replacing the msvcr120.dll in the Adobe\OOBE directory) has cured the problem. Have now 6 times successfully created PDF of the failing book with the PDFL method.
Oh no - the fix did not hold it's promises!
Today I just wanted to create a pdf from one of the files in a book. And guess what?
Towards the end of transformation FM disappeared (lck files left), Acrobat opened with a file with strange name containing only one page which is not correct at all and does not have any relation to this document (page 1-15).
So, yes, Adobe, we must have a look on this. The only trace is provided in the Windows Reliability Monitor, where we have this entry:
Description Faulting Application Path: H:\Adobe\FrameMaker.15en\Adobe FrameMaker 2019\FrameMaker.exe Problem signature Problem Event Name: BEX64 Application Name: FrameMaker.exe Application Version: 184.108.40.2061 Application Timestamp: 5d540b1d Fault Module Name: MSVCR120.dll Fault Module Version: 12.0.40664.0 Fault Module Timestamp: 59260924 Exception Offset: 0000000000074890 Exception Code: c0000409 Exception Data: 0000000000000007 OS Version: 10.0.183220.127.116.11.256.48 Locale ID: 8192 Additional Information 1: cdf9 Additional Information 2: cdf9f0abf882e3f2d3f1c787d0f5efc4 Additional Information 3: f294 Additional Information 4: f29427254349442da4f580dcfd53e205 Extra information about the problem Bucket ID: b26d7a2ae68882230a2e294e10f26f7d (1886490709183328125)
Killing this bug will become tough! It seems to be random (have just created successfully the full book pdf).
About a week ago i had the idea to change the order of files in the book which creates these problems.
Since then the error has disappeared (about 8 pdf generations without problems so far).
Of course I have no idea what caused the problem.
The problem hit again:
Since beginning of this year in !-Sysdoc.book (in which I reordered the chapters) 3 times and in compendium.book just yesterday. In all of these cases the Fault Module Name is MSVCR120.dll with Fault Module Version: 12.0.40664.0.
→ What the heck is going on here?
The incriminating MSVCR120.dll can be found on 3 locations:
All have the very same version and date, just different size (x32 vs x64)
Trying to download the newest version of this dll I only find older ones (e.g. 12.0.21005.1, 2016-08-10) - mine is 12.0.40660.0, 2017-08-24. Mine obviously came into the system by a .Net update. The following .Net versions are installed (reported by Raymond.cc .Net Detector):
.Net 2.0 Service Pack 2
.Net 3.0 Service Pack 2
.Net 3.5 Service Pack 1
→ What kind of .Net do You have installed who do not face these problems?
I managed to create a video during the pdf creation via PDFL:
So far the problem happened only in books, but it may be just a matter of time to surface also in single files, because the phenomenon is random:
After processing all files with the progress indication showing per file
The final step (Postprocessing PDF document) is not executed. Instead FM just quits with the trace in the Reliability Monitor (BEX64 with faulting module MSVCR120.dll Version: 12.0.40664.0) and a very strange PDF file is opened:
Its name is taken from the moon (Just Great Software Invoice S104550.pdf) and its contents is one or two garbled pages from the (to be produced) pdf. And yes, the document files are not closed, lots of *.lck files left.
Hoping that Adobe can do something about this, i filed FRMAKER-7757.
I have "MSVCR100.dll" as faulty module instead of "120" while my FM publishing server tries to create PDFs, but it may help anyway.
My issue only occured when FM was trying to access "AppData\Local\Temp" (This happens with book.Save()). 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.