SUPD for Windows 11 ARM64 not working with HP LaserJet E786 printer

[DC5421245]

Hi,

We purchased a few of the new Microsoft Surface Pro 11's. They run on a Snapdragon X 10-core X1P64100 processor (ARM-based processors), so they are running Windows 11-ARM64. We also have an HP Color LaserJet MFP E786 printer. I looked for a compatible driver to use for this printer for a TCP/IP connection over the network, and the only choice seems to be the Smart Universal Print Driver- as it is the only driver software that HP has distributed thus far that is ARM64 compatible (they provide a driver setup package for ARM64 specifically on the SUPD webpage). So I install the SUPD successfully, and every time I print anything it will send it to the queue on the computer, there it will say it is spooling, then printing, then disappear from the queue as any other print job would.

However, nothing actually prints. In fact, looking at the printer's job log, the printer outright does not receive any job from the ARM64 machine. I've tried from multiple of the new ARM64 surface pros AND to multiple E786 printers (we have multiple) and the same results yield. It's like the printer is refusing to acknowledge the computer's existence. I've rooted out the obvious- made sure it had the right IP, made sure it wasn't the printer being stupid, etc. Our regular intel laptops print fine to it (albeit they use the regular UPD- the PCL6 version was much more reliable than the SUPD). When we used the SUPD with the Intel laptops they also worked with the printer.

Another thing to note- I tried using a job storage approach where the computer would- instead of outright printing- send to job storage on the printer. This worked with the Intel machines using the SUPD, and the job showed up in the job storage area on the control panel and printed fine. However, with the ARM64 based devices, the printer never received the job. It's as if there isn't any successful communication between the ARM64 based device and the printer in terms of print functionality. Pings and access to the EWS between the two worked of course. 

I tried to use the HP Print and Scan doctor utility. It resulted in a "Port Match" error that it "fixed" although the problem persisted even after the "fix" occurred. Test pages failed. It then wanted me to initiate an "internal" test page from the print and scan doctor application, and that also failed. It had me restart the printer and try both again and failures once more. So with that being said, it couldn't communicate with the printer to tell it to print an "internal" test page, let alone have Windows print a test page- so maybe it really is a porting error. I checked the port information in the printer properties and it is using Raw port 9100. This is also the case for the Intel machines. 

There is no UPD available for ARM64 as of current speaking, only the Smart UPD or SUPD. Is there a basic UPD in the works for ARM64? I doubt it but it'd sure be a welcome surprise. Any guidance appreciated greatly. Thank you!

[Bill_Bailey]

I have the exact same problem. I spent 4-5 hours in an online chat with a HP tech who was sure he could fix the problem. He failed. I have been waiting for some kind of update to HP's ARM64 driver but the date on the website here is still reporting May 2024. The PC indicates the print job went to the printer, but nothing ever comes out. HP still says the SUPD driver works on ARM64 but it does not work with CoPilot+ PC's. They need to get their act together.

[Repairatrooper]

Word is next update to SUPD will be late November. To both the posters here, how are you configuring the port on the driver? By TCP/IP number or hostname or are you using WSD?

[Bill_Bailey]

I am using the TCP/IP address of the printer on my local network. 

[DC5421245]

I've got it configured to TCP/IP. Default port (Raw, 9100) used. 

[JR478]

I might have the same problem as you do, with my Snapdragon X CPU: No obvious error in the printing queue, but the printer simply does not print.

In my case, I can see a crash of printfilterpipelinesvc.exe in the Windows EventViewer for every printing attempt. Could you check, if you see the same? 

I am hoping for a new driver that fixes that problem. My workaround was, using the "Microsoft PCL6 Class Driver" for the printer. Unfortunately, this driver does not allow me to specify many printing options, like printing black/white instead of printing in color.

[DC5421245]

Yup been there. I went on call support and the software tech didn't even know what ARM64 was and I had to explain it to him. And then he tried saying they didn't support it. Then why did they make an ARM64 driver. Why does it specifically say it supports this printer. Fun! He said he'd take my email and send me any findings he has and I said "can you send me a test email to ensure you have the right one" and he hung up and I never got anything from him. Not sure what I was expecting honestly. 

[Bill_Bailey]

Yes, I get the same error that you described: "Faulting application name: printfilterpipelinesvc.exe".

I use the "Microsoft IPP Class Driver" as it allows me to use duplex and color printing features that I don't believe are available with the driver you are using. However, there are bugs in this driver as well, as I get very frequent "Paper Out" error messages when in fact the printer has plenty of paper. 

[DC5421245]

JR, I checked EventViewer and I'm seeing the same crash when I try to print. printfilterpipelinesvc.exe immediately crashes:

One second later, I get a printing error. Win32 returns Error 1726. "The remote procedure call failed". I saw some things online about checking that an "RPC" service is running and set to automatic, and mine is, so that isn't the issue. I think that's due to the pipeline svc crashing.

It shoves the Microsoft IPP class driver down our throats as a default option when the regular drivers are non-operational, but it's a no-go for us. Not very customizable and when it tries to handle an image on a page, it will print it in text form, so 77 pages of gibberish later we have a lot of waste haha. But I understand that it's not meant to work specifically with any printer, just an interim option to have base print functionality.

[Repairatrooper]

I have escalated this post to my contacts on the Enterprise side of the business who likely do not see threads like this. I will post back with any updates I receive from that side.