为什么TPrinter（XE7）今天突然出现问题？

Question

I am using C++ Builder XE7 VCL.

Around August 11 2016 2:00pm UTC, I started receiving multiple complaints from my user base about printing problems. Most of these printing modules have proven stable for many years, and there were no updates to my project within the past 24 hours. I was able to reproduce similar problems on my development/test environment.

Without going into many details of my project, let me present a very simple printing program that is failing:

void __fastcall TForm1::PrintButtonClick(TObject *Sender)
{
    // Test Print:
    TPrinter *Prntr = Printer();
    Prntr->Title = "Test_";
    Prntr->BeginDoc();
    Prntr->Canvas->Font->Size = 10;
    Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
    if (Prntr->Printing) {
        Prntr->EndDoc();
    }
}

On the first attempt to print, everything works perfectly as expected. If I click the button a second time, TPrinter produces a small PDF, but the PDF file is actually corrupted and appears to have a file handle stuck to it.

If I click the button a third time, I get no printing and the following error message appears:

Printer is not currently printing.

My own test was done using a PDF printer driver, but the complaints I am receiving from users include a variety of local printers, network printers, PDF printers, etc.

In my actual project, I have try/catch exception handling, so the actual results are slightly different, but substantially similar to this result. The results show the hallmarks of instability and/or memory leaks without much in terms of error messages.

I suspect there may have been some Microsoft Windows updates that are tangling with Embarcadero DLLs, but I have not been able to verify this so far.

Is anyone else having similar problems?

Answer 1

The reason using a TPrintDialog or TPrinterSetupDialog "works" to fix the error is because they force the singleton TPrinter object (returned by the Vcl.Printers.Printer() function) to release its current handle to a printer if it has one, thus causing TPrinter.BeginDoc() to create a new handle. TPrinter releases its printer handle when:

• it is being destroyed.
• its NumCopies , Orientation , or PrinterIndex property is set.
• its SetPrinter() method is called (internally by the PrinterIndex property setter and SetToDefaultPrinter() method, and by TPrintDialog and TPrinterSetupDialog ).

Without doing that, calling TPrinter.BeginDoc() multiple times will just keep re-using the same printer handle. And apparently something about the recent Microsoft security update has now affected that handle reuse.

So, in short, (without uninstalling the Microsoft update) in between calls to BeginDoc() you need to do something that causes TPrinter to release and recreate its printer handle, and then the problem should go away. At least until Embarcadero can release a patch to TPrinter to address this issue. Maybe they could update TPrinter.EndDoc() or TPrinter.Refresh() to release the current printer handle (they currently do not).

Therefore, the following workaround resolves the printing issue without requiring any changes to the user interface:

void __fastcall TForm1::PrintButtonClick(TObject *Sender)
{
    // Test Print:
    TPrinter *Prntr = Printer();
    Prntr->Title = "Test_";
    Prntr->Copies = 1;  // Here is the workaround
    Prntr->BeginDoc();
    if (Prntr->Printing) {
        Prntr->Canvas->Font->Size = 10;
        Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
        Prntr->EndDoc();
    }
}

Answer 2

There are no Embarcadero DLLs involved in printing. TPrinter simply calls Win32 API GDI-based print functions directly.

The "Printer is not currently printing" error occurs when one of the following operations is performed on a TPrinter when its Printing property is false:

• TPrinter::NewPage()
• TPrinter::EndDoc()
• TPrinter::Abort()
• a TPrinter::Canvas subproperty is being changed.
• the TPrinter::Canvas is being drawn on.

You are performing half of these operations in the test code you have shown, but you did not specify which line of code is actually throwing the error.

The Printing property simply returns the current value of the TPrinter::FPrinting data member, which is set to false only when:

• the TPrinter object is initially created (the Printer() function returns a singleton object that is reused for the lifetime of the executable).
• the Win32 API StartDoc() function fails inside of TPrinter::BeginDoc() ( FPrinting is set to true before StartDoc() is called).
• TPrinter::EndDoc() is called when Printing is true.

So, given the test code you have shown, there are two possibilities:

• StartDoc() fails and you are not checking for that condition. BeginDoc() will not throw an error (VCL bug?!?), it will simply exit normally but Printing will be false. Add a check for that:

   Prntr->BeginDoc(); if (Prntr->Printing) { // <-- here Prntr->Canvas->Font->Size = 10; Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *"); Prntr->EndDoc(); } 

• the Printing property is getting set to false prematurely while you are in the process of printing something. The only ways that could happen in the code shown are if:

  • random memory is being corrupted, and TPrinter happens to be the victim.
  • multiple threads are manipulating the same TPrinter object at the same time. TPrinter is not thread-safe.

Since you can reproduce the problem in your development system, I suggest you enable Debug DCUs in the project options, then run your app in the debugger, and put a data breakpoint on the TPrinter::FPrinting data member. The breakpoint will be hit when FPrinting changes value, and you will be able to look at the call stack to see exactly which code is making that change.

Based on this information, I am going to go out on a limb and guess that the cause of your error is StartDoc() failing. Unfortunately, StartDoc() is not documented as returning why it fails. You certainly cannot use GetLastError() for that (most GDI errors are not reported by GetLastError() ). You might be able to use the Win32 API Escape() or ExtEscape() function to retrieve an error code from the print driver itself (use TPrinter::Canvas::Handle as the HDC to query). But if that does not work, you won't be able to determine the reason of the failure, unless Windows is reporting an error message in its Event Log.

If StartDoc() really is failing, it is because of an Win32 API failure, not a VCL failure. Most likely the printer driver itself is failing internally (especially if a PDF print driver is leaving an open file handle to its PDF file), or Windows is failing to communicate with the driver correctly. Either way, it is outside of the VCL. This is consistent with the fact that the error started happening without you making any changes to your app. A Windows Update likely caused a breaking change in the print driver.

Answer 3

Try removing the following Windows update:

Security Update for Microsoft Windows (KB3177725)

MS16-098: Description of the security update for Windows kernel-mode drivers: August 9, 2016

This appears to resolve the issue for several test cases so far.

Answer 4

It started happening here today too. On my Windows 10 setup this would happen after calling TForm's Print() 3 times. I tried both the Microsoft Print to PDF and the Microsoft XPS Document Writer and both gave the same error.

I did some quick debugging and found that it's the call to StartDoc() that returns a value <= 0.

A temp fix until I can figure out what is really causing this is to re-create the Printer object in Printers by calling

Vcl.Printers.SetPrinter(TPrinter.Create).Free;

after calling anything that is using the Printer object. Might not be advisable to do that, but it solved my issue for now.

Looks like something is not released properly when calling EndDoc()

Answer 5

It seems that this is really a Microsoft problem and they should fix this buggy update. You can find more info at this on the company site .

Using a Printer Setup Dialog is only a workaround, not real solution, for this Microsoft bug. After confirmation, the printer setup dialog always creates a new handle for the printer. The next one or two print jobs will then succeed.

The patch should come from Microsoft, not from Embracadero. Thousands of programs are affected and it would be a massive waste of time and money to implement a workaround in all of them, if there is a bug in MS update.

Answer 6

I started experiencing the same weird behavior at more or less the same time, when running 32 bit Delphi applications built in XE7 on a Windows 10 64 bit system.

After uninstalling the latest security upgrade for Windows 10 (KB3176493), printing from these applications works normally again.

A rather surprising side effect of uninstalling this update seems to be that the file associations - which are the default programs for handling specific file types - are being reverted to Microsoft Windows default values...

Answer 7

The following variation of the code in the question will resolve the problem, but requires a TPrinterSetupDialog component added to the form:

void __fastcall TForm1::PrintButtonClick(TObject *Sender)
{
    // Test Print:
    TPrinter *Prntr = Printer();
    Prntr->Title = "Test_";
    PrinterSetupDialog1->Execute();
    Prntr->BeginDoc();
    if (Prntr->Printing) {
        Prntr->Canvas->Font->Size = 10;
        Prntr->Canvas->TextOut(300,1050,"* * * Printing Test * * *");
        Prntr->EndDoc();
    }
}

For program usage, the user will be presented with the printer setup dialog before proceeding to printing.

As to "why", my best guess at this point is that TPrinter used alone does not have all necessary permissions to access all necessary resources from Windows after the Security Update for Microsoft Windows (KB3177725) was implemented on Aug 10, 2016. Somehow a call to TPrinterSetupDialog (or TPrintDialog ) before calling BeginDoc() sets up the necessary conditions for TPrinter to perform successfully.