And the hits just keep on comin...

Multiple users are experiencing this same anamoly...

First time into the system they try to preview something, and get the following set of errors below. Oddly it seems to fix itself later on its own. I thought about forcing a printer spec into the ATE config but that wont allow them to select other network printers.

TIA

The "data area passed to a system call is too small" error has been reported now by two other A-Shell sites, but it remains a complete mystery. (See this thread, coincidentally called "data area passed to a system call is too small" for details.) It seems somewhat related to particular printer drivers, but is either intermittent, or impossible to reproduce, casting some doubt as to exactly what the issue is. There also many discussions about it on the Internet, but I've yet to find one that offered a coherent diagnosis or solution.

The other error messages are new to the problem, as far as I know.

This is the first time the error has been reported with a driver that doesn't make sense to request across the network. (Microsoft Print to PDF driver is on every Windows PC, so what is the "(REDIRECT 2)" referencing? And how does RDP even fit into it? Normally clients use either ATE or RDP; it's somewhat unusual for both to be in use. Are they using RDP to connect to a Windows server, and then ATE from there to a Linux server? In that case, are they trying to select the Microsoft Print To PDF driver on the remote client, or on the RDP server?

When you say multiple users are experiencing it, do they have anything in common? Same network, server, printer driver, ...? Does it print anyway? Or does it just go away on a subsequent print request? (That kind of thing sounds a lot more environment related than something that can just be fixed in the program.)

Sorry to fire so many questions at you, but it's difficult to get a handle on this, given the impossibility (so-far) of reproducing it in an environment where either I could work on it, or escalate it to Microsoft to work on. So any additional clues might be helpful. A trace (LP, XDEBUG) would be a good start, if possible.

It seems that, those RDP clients have the "connect local printer" option set and that "redirect 2" refers to the "Microsoft Print to PDF" printer in the computer connect in the RDP session #2 .
From my experience, unless it's absolutely needed, I don't recommend to connect local printers in RDP sessions, particularly in crowded systems.
The list of possible problems is huge adding those not listed.

Once we are talking about A-Shell-Linux and ATE, that I don't know absolutely nothing about, I'll not add anything more just leaving my two cents above.
But, be my guest to ask whatever needed.

Good luck

Thanks for that explanation about the "REDIRECT 2", which confirms what I suspected. It's still unclear to me how that got to be the selected printer. (Did the user deliberately select the Print-To-Pdf driver from the remote PC rather than from the RDP server? Why?) Partly this kind of confusion is inherent in the way network printer sharing appears to the user, but as a general rule, it's always better to use the instance of the printer driver resident on the same machine that the application is on. If there are network problems, that printer driver may still have trouble communicating with the printer, but in that case, it will just remain in the print queue. In contrast, when the application has to communicate with a remote printer driver over the network, all kinds of complexities creep into the picture, opening the door to mysterious errors like this.

As an aside, I don't think ATE really has any impact on the situation; in fact, I'm not even sure this is an ATE and A-Shell/Linux environment at all. But it could be associated with APEX, which complicates the overall printing environment by offering many paths through to various output devices. So I think we need to start by nailing down the environment and sequence of events.

Thanks for the replies. I am in the process of holding conf calls to get more details.

To answer questions: These are ATE / LINUX users. My understanding of the topography is
CLIENT -> RDP WINDOWS SERVER -> ATE -> LINUX SERVER.

They use RDP to connect to a central windows server at which time ATE is launched. We are not having issue with simple CLIENT -> SERVER connections.

All i know at this point is effects "some" users on the RDP connection but not all. Hard to diagnose the difference in these users or connections.

Precisely, the "not all" means that who has problems are those that:
1. connect local printers
2. have problematic local printers

No?

Thanks for the insight On it...

Thanks for the suggestions...

I am testing turning off the "connect local printers" option to see if that has any effect.

I do have a f/up question tho: what happens if you do indeed need to print locally?

Now you opened a myriad of scenarios

When possible I prefer to setup all the printers as network printers and don't use connected printers, but this means:
1. have a vpn configured between the local network and the remote server
2. only use network printers

But, even on the perfect scenario above, there could be one computer using an USB printer.
Worst if that printer is an HP domestic line (all those all-in-one) that don't provide drivers for Windows Server.
But that's the opposite problem, when you want to connect the local printer and cannot because of the driver.
So, when you set the RDP session to connect local printers, you will have all those annoying virtual printers (OneNote, print-to-pdf, etc...) as well as the duplicates of the network printers configured in the local computer and on the remote server (if using the vpn scenario above).

To avoid confusions, what you should do is to configure the "connect only default printer" in Group Policy (gpedit,msc)
Computer/administrative templates/remote desktop sessions/Host sessions
(I don't know if that is the exact translation in English but should be close)

Anyway, this doesn't close the possibilities that can come up around this subject, hope this can be helpful in some way.
Feel free to keep asking.