Kyocera FS 2020D Printer Causes PDF PostOffice Invoice Printing to Crash

Release Date: 3/12/2019
Modified on: 5/1/2019
Version: 8.2 and 8.5

Q - This started to happen two days ago when printing a PDF PostOffice Invoice document. On the printer page, we selected the output printer as Kyocera FS2020D.  When we printed a batch of invoices, the one that did not have an eContact to send the PDF PostOffice document to, printed to the Kyocera FS2020D printer. Then the whole Windows OS crashed with the bug check option. Should I send you the debugging information?

A - The fact that the Windows OS crashed indicates this is a printer driver issue. Elliott Business Software is an application software that can't crash the Windows OS.

We did try to duplicate this problem on our side, but we can't recreate it. We added the same printer to a Windows 10 workstation. Then we deliberately updated to the latest Windows 10 SP (2019-03 Cumulative Update for Windows 10 Version 1809) and rebooted before we started our test. We printed an invoice with a PDF PostOffice Document that does not have a corresponding eContact, so the printer output would go to the Kyocera printer.  Of course, we don’t really have the actual Kyocera. But we were just testing the printer driver, so the hardware should not matter when it comes to recreating this problem.  We did receive a message that the printer was not available and I can see that the print spooler for Kyocera FS-2020D was created.

From our past experience, we have never had a problem with HP printers. So we suggest that you buy an HP printer in the future if you need to buy a new one.

On 5/1/2019, another user post a similar scenario:
Netcellent Elliott running on MS Windows Server 2019 Remote Desktop Services (essentially latest version of terminal server).
Printing via redirect to a local networked printer (network printer installed/configured on local workstation, available to RDS session via printer redirect).
When printing a laser form enabled document (invoice, statement, PO etc.) appears to hard crash server. Not just the user session - but the _entire server_.
Are you guys seeing this in any of your other installations?
Thanks,
Later on, the user confirmed that the printer they were using was indeed "Kyocera."

Here is the continued communication from our user for this case:
The interesting thing is that the driver itself does not reside on the RDS server. The print job is “redirected” to and then processed by the printer driver on the client.
It’s not the client (where the print job is being processed by the driver) that’s crashing – it’s the server itself. And, so far, it seems to be limited to laser forms output…. 
Here is our response to the user:
My understanding on how the printer driver is handled by the RDS server after Windows 2008 is that it does not require the remote workstation printer driver to be installed on the server. They developed a universal way of handling the printing. This makes sense because you can’t control the RDP client based on what printer drivers they are going to use. It is difficult to install all printer drivers on the RDP server that are used by the RDP client. The fact that the RDP server does not have a Kyocera printer installed does not mean the server itself does not execute the printer driver.

I think there are certain laser form functions that trigger this bug in the “Kyocera” printer driver, which causes the crash. The other user who had this same problem doesn't use RDP. The result is the workstation Windows 10 OS got rebooted. They actually have been using the Kyocera printer for some time, The crash did not happen until they had a Windows 10 1809 update. Somehow, there is a weird interaction between the Kyocera printer driver, Windows 10 OS update, and the Elliott laser form printing combination to cause the reboot to happen. Since your server is Windows 2019, which matches the latest Windows 10 OS, I suspect your scenario happened after the Windows 2019 update as well. We don’t know the exact mechanism that causes this to happen. But the circumstantial evidence is pretty strong here.
The user followed up with the following comments:
https://community.spiceworks.com/topic/2187199-printing-certain-documents-in-word-2019-causing-brand-new-pcs-to-bsod
I also keep finding reference to this “OpenType” fonts with CCF outlines. Does that mean anything to you as relates to Laser Forms?
“After the Windows 10 1803 update, no application (not just Office) is capable of printing any document that references OpenType fonts with CFF outlines, if the printer driver is a "Type 4" printer driver.
This issue was not one of those fixed in the June 12th update for v1803, and remains live at the time of writing.”
We responded with the following:
I don’t think the issue has to do with font selection. For one thing, the issue only happens with Kyocera printers.

Also, the user actually does not select the font in laser form definition. This is obvious because if we do, then there’s no way to ensure the compatibility for different workstations using the same laser form. Different workstations can have different fonts installed.

The font is decided at the time of printing. If no specific font is chosen (font 99) by the user, then the system automatically picks a best-fit font from those available.. This is done on a workstation-by-workstation level. This font selection process is no different than regular reports vs. laser forms printing.

The article you found confirms there is some issue with the Kyocera printer and the Windows 10 update. We just don’t know what it is.

One thing I would caution you about is that Microsoft SP updates have been degrading in the last two years. They often break things with their updates and that’s not just small stuff. They would break things in one update, and fix it in the next update and break more things. This does not just apply to Windows 10 updates. My main RDP server, where all users login, is a Windows 2008 server, and last year their routine automatic nightly Windows update corrupted the image of that server and it took me two days to recover. That was a major productivity hit for my company! Unfortunately, because of that, we are now treating the routine Windows OS updates as major upgrades. I just turned off my Server Windows OS automatic update option. We don’t update our server unless we have a compelling reason to do so.

On 5/15/2019, we received an update information from the same user indicating the following:
Replacing the drivers with the most recent from Kyocera seems to have resolved the issue.


EMK

Feedback and Knowledge Base