The Windows update KB4512489 on Windows 2012 R2 makes the use of TdxComponentPrinter impossible.
Make an application,. Place TdxComponentPrinter and TdxPSFileBasedExplorer components on the form.
Launch the application. The form does not show up until Ending Task for splwow64.exe in task manager.
The call from the application that freezes splwow64.exe is CreateICW in TdxPrintDevice.SetState in dxPrnDev.
This prevents printing
TdxComponentPrinter is freezing application on Windows 2012 R2 after applying KB4512489
Answers
The answer is found here
https://stackoverflow.com/questions/17312657/winapi-createdc-hangs-on-win-8/17335017
From Microsoft Premier Support: "All updates are supposed to be cumulative. Thus, KB4517298 and KB4512489 are supposed to be a superset of KB4507457, but due to a packaging problem, they are not. Splwow64.exe was updated in KB4507457 and KB4507448, so installing any KB from those or newer except KB4517298 and KB4512489 will install the updated splwow64.exe. Running Window Update should also install a missing update from the list to resolve the issue." – aolszowka Sep 13 at 20:30
Comments
(1)
Thank you for sharing your research results! This may help other Windows 2012 users who have similar problems with these cumulative updates.
Hello,
Right now we do not have a Windows 2012 R2 environment to emulate this scenario. In any case, CreateICW is the standard API we are using in our Printing System. We do not have control over it, so I am not sure that we will be able to fix this problem at the level of our component. Would you please check if updating the Printer's driver can be of help? Perhaps, there is a newer version of that driver that supports the latest Windows 2012 R2 update.
I can confirm that the issue still exists (VCL 20.1.6). While I can not reproduce this on my machine either, but our clients complain that our app sometimes hangs on start with the following call stack:
win32u.dll NtGdiOpenDCW gdi32full.dll hdcCreateDCW GDI32.dll bCreateDCW GDI32.dll CreateICW dxPrnDev.pas TdxPrintDeviceGetHandle dxPrnDev.pas dxInitPrintDevice dxPrnPg.pas TdxPrinterPage.ApplyToPrintDevice dxPSCore.pas TCustomdxComponentPrinter.SetCurrentLink System.TypInfo.pas SetOrdProp System.Classes.pas TReader.ReadData System.Classes.pas TComponent.ReadState Vcl.Forms.pas TCustomForm.ReadStateThe issue is that
TdxComponentPrinterdoes not allowCurrentLinkproperty to be not set. So, when app runs and creates a main form, it readsTdxComponentPrinterand setsCurrentLinkproperty - which apparently may hang. The reason for hang is not so important* - what is important is that there is no workaround.CreateICWhangs when printer(s) are not ready somehow. I don't know: not initialized yet? Network printer is inaccessible? Our clients use Windows 10. One of the customers confirms: "If the default printer (LAN printer) is off i have the hang. If it's on there's no hang."I would imagine that a fix would be something like calling
TdxPrintDeviceGetHandlein a thread-pool's callback with a timeout. Or at least allowCurrentLinkproperty to be unset at design-time, so one can set it at run-time immediately before printing.Hello,
I agree that the only workaround seems to be using a secondary thread. I cannot guarantee that we will be able to implement this in the near future. This will require significant changes in out Printing System's core code.