Recently Microsoft deployed some security patch that has broken UWP printing to serial printers. These are printers that interface to Windows through either a USB serial port or a Bluetooth serial port. Symptoms -
Upon printing, a print notification appears:
Print Notification
Error printing on [printer name]
The printer couldn't print [print job name]
The print job appears in the printer queue with "Error - Printing" as status. Restarting the print job from the queue causes the page to successfully print, however having to restart every print job is not an acceptable solution for any application.
In the Windows event viewer, under Custom Views, Administrative Events, the following error is logged at the time of print failure:
"The document Print Document, owned by [user], failed to print on printer [printer name]. Try to print the document again, or restart the print spooler.
Data type: XPS2GDI. Size of the spool file in bytes: 182104. Number of bytes printed: 0. Total number of pages in the document: 1. Number of pages printed: 0. Client computer: [\COMPUTERNAME]. Win32 error code returned by the print processor: 3012. No printers were found."
I have duplicated this bug using the Windows Universal printing example from Microsoft
I have duplicated the issue on multiple PCs, running Windows 10 21H1, 21H2, and Windows 11. I believe the issue to be related to some recent security fix deployed by Microsoft but I cannot identify which one is the cause. The problem did not exist until recently.
Are other people seeing this? Does anyone know which KB patch is the culprit? Is there any fix of which anyone is aware?
Here is the fix. The fix takes care of both Bluetooth and serial printing issue in Windows with the symptoms as described above. In an elevated command prompt:
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers" /v {CA791BB3-9742-4A0F-87B8-B3C4B1065856} /t REG_DWORD /d 1 /f
After issuing this command, reboot the PC. The fix works for both Windows 10 and 11.
I’m hopeful that Microsoft is going to patch the issue in the near future.
Related
We have a Windows 10 machine that can print from applications like MS Word. (Print server 2019) However, when we try to send a print job to the printer from another in-house application, the print job gets deleted by the spooler.
You can see the print job in the printer queue on the originating machine, you can see it in the queue on the print server, but then that's where it stops. It does not get to the status of "Printing job ". Instead the job gets deleted then throws an error (ox2) when trying to delete the file that is already gone.
We tried
changing the printer protocol from LPR to RAW
printing directly to the printer instead of through the print server
sharing the printer from the client machine and printing to that
turning on the EMF Spool option
updating the drivers on the client machine and the print server
Our users upgraded from Windows 7 to 10.
When they try to print using a custom print driver they get this error
The document Print Document, owned by User, failed to print on printer TEST-PRINT. Try to print the document again, or restart the print spooler.
Data type: NT EMF 1.008. Size of the spool file in bytes: 628788. Number of bytes printed: 12900. Total number of pages in the document: 6. Number of pages printed: 0.
Client computer: Devcomp. Win32 error code returned by the print processor: 2147500037. Unspecified error
Some of my observations: Internally we cannot reproduce this error internally. I have a windows 10 surface and also tried on a windows 8 machine. Our support tried it here too.
The customer can reproduce the issue without. The issue happens for some documents on some workstations. The PDF is generated from a 3rd party application for tellers. The customer saves the pdf from this signature desktop application to a PDF and uses our print driver to print to the our application.
Our print driver converts the file to PCL and sends it to the subscriber for further processing.
I can provide more info if needed regarding print driver. First of is it a problem with the print driver?
All the users who upgraded from windows 7 to a windows 10 laptop can see the issue happening. There are some windows 10 workstations that print just fine. Could it be something with the group policy or some registry settings. If I were to compare the registry or policies on the workstation that prints and the one that fails what would be the settings I need to look for? The customer's IT says that there is no difference between the two workstations except that it’s the production workstation that fails. Typical response nothing different but it doesn't work.
We also tried to disable “render print jobs on the client workstation” but this didn’t seem to make difference. I am happy to try any suggestions you’ll have.
I am looking for ideas of what kind of research and where should I start troubleshooting.
I won't be troubled if anyone chooses to vote the question down that I didn't do any research since I really don't know where to start. I am a .NET developer not a windows driver expert or systems admin.
Process Monitor Good File. The file gets created.
Create file success, create file name not found and finally create file succcess
Bad File: Create file success, create file name not found. The last create file is not called by the print.exe driver.
This solved my problem. Thanks Papercut!.
https://www.papercut.com/kb/Main/FixingPrintSpoolerCrashes
https://www.papercut.com/kb/Main/EnableAdvancedPrintingFeatures
I am working with MC9500 Motorola handhelds, Zebra RW-420 printers, and the VIP Application. When I go to print a test page it reads the error:
Failed to read 1 byte(0 read)
Troubleshooting:
-I have successfully printed from other RW-420 printers
-Sent the printers that had this error back to Zebra(now they can print via Bluetooth but still show that error)
-Made sure I have the correct COM Ports
-Reset the printers multiple times on the Zebra Setup Utilities
-I have updated the firmware on the printer
-Tried changing the printer language but nothing helps
I have tried searching for this error but I haven't seen anything relevant yet. Please let me know if there is anything I am missing.
There was a different way to change the printer language and a few other configuration settings that needed to be changed beforehand.
We have used Google Cloud Print Service for a few years now, very successfully. Periodically we have issues with print jobs failing, where restarting the Cloud Print Service and the Print Spooler will fix it. That is not the case today.
Today, I am able to print directly to the printer, both from my computer and from the server where we host Google Cloud Print Service. When I attempt to print from Google Cloud Print, I see the print job appear in the queue on the server, and then disappear, and in the Cloud Print queue it simply says "error" with no details on what is happening.
I restarted the print service with logging enabled, attempted to print again, and checked the debug log, with no details present. I'm stumped.
EDIT: After finding the correct debug log, I see this:
CP_CONNECTOR: Job failed (spool failed)
Has anyone dealt with this before, or know of a solution?
Things I have already tried:
Re-connecting Cloud Print Service to our Google account
Re sharing all printers
Reinstalling Cloud Print Service
Restarting the server
Reinstalling printers
After doing many many things, and finally getting Google support on the line, we determined it was a glitch in the Cloud Print Service. The work around, which I was unaware of, and the reason I'm posting this answer, was to use the Chrome Connector.
You can get to that by visiting chrome://devices and then sharing the printers through that form, which looks identical to the one that you get with the Cloud Print Service. I recommend clearing your printer list from Cloud Print first, so you don't get confused.
Once you've shared them, you can then share the printer through Cloud Print just as you would have before.
The only caveat, and the reason this is a work around and not a fix, is that you have to maintain an open Chrome session, meaning you have to keep chrome open for the printers to work. That's fine for us, as there is always a chrome tab open on the server anyway, but it may not work for you long-term.
I have installed the Beta version of chrome, and it seems to resolve the issue. I had this issue on 3 of my 11 servers. All where running stable versions. It was odd that only 3 where not allowing google to print. Once I installed the 64bit beta version, I was able to print. As long as the server was running the Version 53, people could print. It did not matter if someone had a version 52 on there computer. Hope this helps.
I have created a Delphi Service which prints TQuickReports. Everything works fine if compiled and run as a Windows Application. But when converted to operate as a service trying to create a form containing a TQuickRep component throws the exception.
This service runs fine on many other boxes but not this one in particular. Here are some details:
Using QuickReport version 4.07
Box is a Windows Server 2008 operating system.
Using Delphi 2007
Printer.Printers.Count is returning a positive value. In fact I can list out all of the printers.
I have tried running the service both using Local System Account and Logged on as an Admin.
Is there a default printer set up in session 0? Remember that under Vista / Server 2008 / Windows 7, services run in a separate session. Whether or not the logged-in user has a default printer set is not relevant - it's a per-session setting and doesn't affect session 0.
Can you rewrite the code to gracefully handle that exception and pick a printer to use?
You can solve this problem by creating a new dword UserSelectedDefault with the value: 1 in
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\SessionDefaultDevices\Session_ID
Make sure you have a local printer selected.
You might give the user a way to select the printer for the service. The Windows service probably does not have a default printer set.
Set TQuickRep.PrinterSettings.PrinterIndex to set the printer number. Then, TQuickRep.Print to print the report.
A colleague ended up finding the solution. I should have added these are "network" printers and not Local printers (at the time I didn't think this was related to the problem). So the service needed to be installed with "NetworkService" as the user account under the logon tab. From the Windows Help:
To specify that the service uses the Network Service account, click This account, and
then type NT AUTHORITY\NetworkService
We had a simular problem here. Using TS servers, Citrix and Powerfuse 9.
Powerfuse had all printers capitalized, however they were shared in a mixed case.
This combination caused Delphi/QReport to crash
When all printers are from printserver to powerfuse in the same case (not important upper or lower or even mixed), the problem was gone
Actually it is a Delphi(5) problem. The comparison of the available printers and the default printer is case sensitive (Printers.pas):
if TPrinterDevice(Objects[I]).Device = Device then
begin
with TPrinterDevice(Objects[I]) do
SetPrinter(PChar(Device), PChar(Driver), PChar(Port), 0);
Exit;
end;
Changing the comparison to:
if lowercase(TPrinterDevice(Objects[I]).Device) = lowercase(Device)
solves the problem.
If using terminal services 2008, same user for multiple sessions, you should look into the:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\SessionDefaultDevices\Session_ID
instead of
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\
I solved a similar problem: If a Delphi application (or service) uses QuickReport, it runs before the system loads the default printer (or printers).
When QuickReport executes TQRPrinter.Init, the printer.printers.count is zero,
shortly after the system loads, the printer.printers.count is the number of printers,
but tqrprinter.int has already executed, so TQRPrinter.FPrinterOK is false,
you then see this error when you try open a QuickReport.
The solution for me was wait until the printers were loaded before launching the application (in citrix and terminal server). I solved this in two ways, either by overwriting tqrprinter or delay the dpr.