KB3176493 for Windows 10 and KB3177725 for Windows 7 broke printing in our software

Hi Kristjan,

I would be happy to assist you.

I would like to inform, the main reason for printer not printing is that your device drivers are not compatible on Windows 10.

The device manufacturer is the one who releases the latest drivers for the latest versions of operating systems. As there are no drivers for Windows 10 you can download the latest drivers and install them on Windows 10 in compatibility mode and check if it helps. 

You can install Windows 7/8/8.1 drivers in compatibility mode if there are no Windows 10 compatible drivers.

Follow the steps to install in Compatibility mode:

1. 1.    Download the updated driver from the manufacturer’s website.
2. 2.    Right click the driver installation file and select Properties then tap or click the Compatibility tab.
3. 3.    Place a check in the Run this program in compatibility mode for: box.
4. 4.    Tap the drop down box and select a previous operating system, then tap or click OK.
5. 5.    Try installing the driver and check.

Refer the article below for printer troubleshooting steps.

https://support.microsoft.com/en-gb/instantanswers/bdff0c68-6204-6025-dcc1-3aefaa14ab40/fix-printer-problems

If the issue persists, contact to the printer manufacturer and check for the latest driver available for the printer.

Hope this information was helpful and do let us know if you need further assistance. We will be glad to assist.

Thank you.

Hi Kristjan-

Thank you for reporting this.  I would like to let you know we are actively investigating this issue and have updated some of the KB articles involved with a Known Issues section:

"After you apply this security update and you print multiple documents in succession, the first two documents may print successfully. However, the third and subsequent documents may not print."

Links:

https://support.microsoft.com/en-us/kb/3177725

https://support.microsoft.com/en-us/kb/3178466

If publicly available information on this topic changes, we will provide an update here as well.

Thanks,

Dan Mattson

This is an issue only when attempting to use the same device context for multiple print jobs.  You can avoid this situation programmatically by creating a new device context with CreateDC for each print job. 

So it would look like this:

   for (int doc = 0; doc < numDocuments; doc++)
   {
    HDC hPDC = CreateDC(NULL, printerName, NULL, pDevMode);
    if (hPDC)
    {
     if ((jobId = StartDoc(hPDC, &docinfo)) > 0)
     {
      if (StartPage(hPDC) > 0)
      {
       //Write contents
       EndPage(hPDC);
      }
      EndDoc(hPDC);
     }
     DeleteDC(hPDC);
    }
   }

Instead of this:

   HDC hPDC = CreateDC(NULL, printerName, NULL, pDevMode);
   if (hPDC)
   {
    for (int doc = 0; doc < numDocuments; doc++)
    {
     if ((jobId = StartDoc(hPDC, &docinfo)) > 0)
     {
      if (StartPage(hPDC) > 0)
      {
       //Write contents
       EndPage(hPDC);
      }
      EndDoc(hPDC);
     }
    }
    DeleteDC(hPDC);
   }

Yes, this is exactly the problem, but the workaround isn't really practical for most people, because:

1. There's commercially available software packages which do this, which are now broken.  Users would have no recourse other than wait for every application developer to issue a patch.

2. The reason software is designed this way is because CreateDC is a slow call.  Any software designed for high speed generation of print jobs is going to be optimized to not recreate the DC unnecessarily.  I would think that most label printing software and ERP printing modules would be optimized like this, and they will all go down as soon as this patch is applied.

Microsoft has broken a fundamental Win32 API that has worked perfectly since Windows 95.  There are factories running 24/7 using software which is broken by this patch and production will be shut down if they install it unaware of this severe side effect.  I think it should be Microsoft's priority to fix the patch as quickly as possible, before the trickle of reports becomes a flood.

Unfortunately it is not only label printing and ERP modules that is affected by this bug.

Office 2010 and Office 2013 (have not tested 2016 yet) are broken as well.

Stefan

Hi Stefan-

Thank you for reporting this.

So far we have not been able to reproduce this problem with Office applications.  It may be driver or content dependent.  With that said, can you please provide the steps you used to reproduce this problem?  Please include the printer make & model, as well as which Office application(s) is/are impacted, and any other specifics which may be relevant (such as number of pages).

Thanks again,

Dan

Hello Dan,

We are using COM automation to run Word from an application running in a service context under a local user profile with administrative rights (the profile is a member of the local administrators group). The application driving Word has been used (and is actively developed/maintained) since 1998 with Word versions from 97 upto 2016.

We have consistently observed the exact behavior described in this thread / the KB articles (two jobs successful, after that random success or failure) on both Windows 2008R2 and Windows 2012R2, and with both Office 2010 (current patchlevel) and Office 2013 SP1 (no further patches). A significant percentage of the jobs fail.

The document format (DOC or DOCX) did not matter. I haven't verified if the rendering engine (Esher vs. Esher2) mattered for DOCX, but Esher should be covered by the DOC path anyway.

We did try to confirm the KB3177725 relationship first by patching a 2008R2 server upto the current patch level and then deinstalling KB3177725 -- which fixed the problem introduced after the patching, and on a 2012R2 server (with patch level june or july 2015), where we only installed KB3177725 (downloaded and installed manually, not through WindowsUpdate) -- which introduced the problem.  I think this confirmed KB3177725 as the trigger of the observed behavior.

At this time I am unable to verify Office 2016 on a fully patched 2012R2 server, as for some reason Windows Update refused to offer me KB3177725 for Windows 2012R2 today, nor any other fix that could be somehow associated with MS16-098 through the KB numbers.

All reproductions were done using the Amyuni v5 PDF printer driver. We are using an older revision (I think 5.0.0.7 or 5.0.1.2) that has been in use by us for at least two years.

All components (OS, Office and PDF printer driver) are 64-bit. Our own application driving the automation is 32-bit.

The following automation sequence is executed (these are the exact commands, but I left out options like 'open-read-only', 'do-not-print-in-background' as I don't have the exact code available at this time):

[Edit: See full repo script in reply below]

Documents.Open "c:\temp\test.docx"

WordBasic.FilePrintSetup Printer:="PDF driver" DoNotSetAsSysDefault:=True

Document.PrintOut OutputFileName:="c:\temp\spool1.pdf"

Document.Close wdDoNotSaveChanges

Documents.Open "c:\temp\test.docx"

Document.Close wdDoNotSaveChanges

Documents.Open "c:\temp\test.docx"

Document.Close wdDoNotSaveChanges

Documents.Open "c:\temp\test.docx"

Document.Close wdDoNotSaveChanges

...

So the printer is only set during the first print sequence. All print sequences use the same document, but generate new spool files. Note that we are explicitly instructing Word to use the 'print-to-file' options.

The content of the document seems to be irrelevant. I could reproduce the problem with a single-page document only containing the text generated by =lorem(5,5). I don't recall if the document was A4 or US Letter.

The resulting PDF files are either OK, or seem to be missing all page content (and therefore technically corrupt).

Restarting Word after every print fixes the problem.

We haven't had time to do much more testing or work on isolating a stand-alone reproduction scenario as our focus is still on damage control / finding workarounds for our customers.

UPDATE #1:

First tests:

Service context and application are a red herring. The problem reproduces interactively on the desktop with a trivial VBS script.

UPDATE #2:

More testing:

The printing device is a red herring as well. The problem reproduces with the (preinstalled) Microsoft XPS Document Writer driver as well. XPS files are either 107KB and OK, or 10KB and 7-Zip reports an error when I try to unzip.

UPDATE #3:

Uninstalling KB3177725 fixes the problem and generates consistent 107KB XPS files.

UPDATE #4:

Office 2016 (Click-to-Run install) is broken too.

(Final) UPDATE #5:

Due to the 'random' sort that Explorer performs on the 'Date Modified' field when all documents are produced in the same minute I hadn't noticed it yet, but the repro script consistently produces an OK / Broken sequence (so Spool 2, 4 and 6 are broken, the odd ones are OK). This deviates from the 'first two jobs are OK'. All prints are the same 1 page document.

Regards,

Stefan

E: stefan(dot)ten[no-dot]hoedt(at)outlook(dot)com

[Edit: added remark on print-to-file]

[Edit: added contact info]

[Edit: updated multiple times with additional test results, strike-through for obsolete information/red herrings]

Repo script:

Option Explicit

Dim objWord
Dim objDoc

Set objWord = CreateObject ("Word.Application")
Set objDoc = objWord.Documents.Open ("c:\temp\lorem.doc", False, True, False, , , True)
objWord.WordBasic.FilePrintSetup "Microsoft XPS Document Writer", , , True
objDoc.PrintOut False, False, 0, "c:\temp\spool001.xps", , , 0, 1, , 0, True, False
objDoc.Close 0
Set objDoc = objWord.Documents.Open ("c:\temp\lorem.doc", False, True, False, , , True)
objDoc.PrintOut False, False, 0, "c:\temp\spool002.xps", , , 0, 1, , 0, True, False
objDoc.Close 0
Set objDoc = objWord.Documents.Open ("c:\temp\lorem.doc", False, True, False, , , True)
objDoc.PrintOut False, False, 0, "c:\temp\spool003.xps", , , 0, 1, , 0, True, False
objDoc.Close 0
Set objDoc = objWord.Documents.Open ("c:\temp\lorem.doc", False, True, False, , , True)
objDoc.PrintOut False, False, 0, "c:\temp\spool004.xps", , , 0, 1, , 0, True, False
objDoc.Close 0
Set objDoc = objWord.Documents.Open ("c:\temp\lorem.doc", False, True, False, , , True)
objDoc.PrintOut False, False, 0, "c:\temp\spool005.xps", , , 0, 1, , 0, True, False
objDoc.Close 0
Set objDoc = objWord.Documents.Open ("c:\temp\lorem.doc", False, True, False, , , True)
objDoc.PrintOut False, False, 0, "c:\temp\spool006.xps", , , 0, 1, , 0, True, False
objDoc.Close 0
Set objDoc = objWord.Documents.Open ("c:\temp\lorem.doc", False, True, False, , , True)
objDoc.PrintOut False, False, 0, "c:\temp\spool007.xps", , , 0, 1, , 0, True, False
objDoc.Close 0
objWord.Quit

The lorem.doc contains the expansion of =lorem(5,5).

Hi Kristjan-

Thank you for reporting this.  I would like to let you know we are actively investigating this issue and have updated some of the KB articles involved with a Known Issues section:

.....

Thanks,

Dan Mattson

Since this is a security update, there is little comfort in uninstalling the update as it will just install again during next restart. Defering future updates also does not block this update from installing again right away (security update).

Any workaround to block it until Microsoft releases a fix??

best regards,

Kristjan

Edit: I´m testing this also with insider build 14901.1000 - same problem, confirmed with script from Stefan´s post

Thank you Stefan for providing these details.  I have passed the information on to the engineering team.

Thanks again,

Dan