A customer who moved a lot of users to GDI printing using Windows network printers via ATE (instead of via a UNIX queue printer) are getting the following ATE error fairly regularly:
Unable to start print job (StartDoc) Err #122 data area passed to a system call is too small
They say they mostly can solve this by changing the windows "default printer" to something else and then back again...
Any thoughts / pointers what the message means?
Thanks and have a great 2020...

If any help, most users look as if they running ATE 6.5.1655.1

Snippet from ashlog.log (emailed full version)

.TYPE SYS:LPT98.INI

The error is a bit mysterious since the function in question, StartDoc(), takes a fixed sized structure argument which has no "data array". The structure starts with a field specifying it's own size (a standard Windows technique for identifying corrupt work areas passed by pointer), which theoretically could have gotten corrupted, but it's hard-coded and hard to see how that could go wrong. And especially how it would be affected by the choice of printer.

Looking for clues about that error on the internet reveals mostly vague suggestions about it being related to specific, out-of-date printer drivers, which provides a good reminder that despite what you might think, it's actually quite common for printers to ship with drivers that have significant problems. So it's highly recommended to start any printer debugging with a driver update.

There are also some suggestions that it may be related to privilege conflicts associated with network printer sharing between different users or something like that.

Your ashlog also contains an interesting error which may or may not be related:



That suggests a minor rough edge in A-Shell/Windows in which it is failing to recognize that there's no way we're going to find a printer init file based on a UNC share name. There's probably no harm there, but it does make clear that the printer selection being made in the printer dialog is a network share name (presumably auto-detected). And that suggests a possible workaround would be to install a local copy of the printer driver on the machine in question, eliminating any complications related to privileges in the communication between A-Shell and the driver.

Thanks for the hint, I'll first get them to check / update the Printer Drivers and go from there....

Feed back from customer:




Anything we can try?

I've done some more Internet browsing on the problem, and it sure seems that for all of the discussions about it (which are all over the map in terms of application environments, printers, etc.), the only common thread is some connection to user privileges, domains, sharing issues, etc. That appears to apply to this case as well, given that the printers in question (at least from what I can determine) have UNC device names (i.e. are printers discovered on the network, rather than printers that have been locally defined).

So it may be that the printer driver update suggestion was off the mark, but I still think my other previous recommendation (to install the driver{s} locally on the PC having the problem) may be helpful. If the printer is a network printer, my preferred way to do this is to select the "add a local printer or network printer with manual settings" option, then create a new standard TCP/IP port using the IP address. The printer will then show up in your list of printers with a local name (e.g. Burton Depot Laserjet), rather than being rerouted through another machine (\\DIPT-FP1\Burton Depot Laserjet). That would eliminate any possible privilege/domain issues between the local PC/user and the owner of the printer.

Thanks, I'll pass that on and give it a try..

I just got another report of this problem from a new user on a Windows Server 2019, leading me to wonder whether reconfiguring the printer device/driver as suggested above had any effect.

Good question and hard to say, as the issue still occurred now and again (I'll forward you an email Jack from the customer with details he tried etc) - It gone quiet for a few weeks and our support tickets have notified them and auto completed so i guess its not a big issue, or dare I email them and ask???!?
They still thought weirdly as it is if they change the default PC printer to something else and back it was ok.. (but not everytime!)... The printers are all maintained and distributed from a windows central server and rolled out to clients (see incoming email) maybe it a failed to validate permission or lack or some windows chattery something...
but to answer you question, no we never really solve it and it lingers and waits to bite our bum just when we think its safe to go in the sea again.

I kind of assumed that was the case, and definitely don't want to agitate the situation if they've adapted to it. But given that it has surfaced in at least one other place, I guess it isn't going away.

Is the other customer distributing the printers from central server to clients? It be one thing in common..

Not sure, but it's a very large W2019 server environment, so it seems highly likely.

Jack maybe your telepathic or on those lines as the customer today phoned with a following saying its still occurs can we help...

A little more detail:

* they distribute all the printers/driver to the clients windows pc clients via a Windows 2012 R2 server..
* they spoke to HP support and have the very latest / recommend 'universal' printer drivers
* from what we know its only occurring on just 3 PC's out of 50+ PC's... (But those 3 users like to call their internal support a lot when they cant print)
* The three PC's have different solutions (or not):
1) Change default printer to something else and back and it then prints ok again
2) One is very infrequent and same as above solves it
3) another is intermittent and what ever they try it does not solve it apart from wait.. and "time it self" solves it.
(Printing from Notepad, Word etc all print fine...)

So hope yours as confused as us. I will try to remote desktop next time ones stops and look myself..

I keep looking for clues about this, but the people reporting it on the Internet are all over the map in terms of applications, environments, Windows versions, etc. And most of them share the same vague symptoms (intermittent, may go away with rebooting, logging in as a different user, rolling back some version of something, etc.) There are a lot of complaints of this type on HP forums, but the suggestions are all sort of generic along the lines of the ones I've made (update the drivers, Windows patches, etc.) I'm fairly confident that it is a Microsoft bug because of the fact that the function triggering the error - StartDoc() - takes only two relatively simple parameters, but internally almost certainly invokes byzantine layers of device driver calls which all have printer-dependent work areas. It's easy to see how one of them could have this problem; it's harder to see why it's intermittent. I'd be willing to open up a ticket with Microsoft support ($$$), but from experience I know it's going to be next to impossible to get anywhere without some kind of reproducibility.

Comparing to Notepad, Word, etc., one likely difference there is that those always bring up the printer selection dialog. Yet your mention of changing the default printer suggests that you are not typically using the interactive dialog. I wonder if the problem only occurs when printing directly to a printer by name vs from the dialog, and if so, whether that's a workaround, at least for the short term?

I do believe it still happens when they choose from a "printer dialog" as everyone is using one ashell printer of LPT98.INI and thats set to something like: DEVICE=PROMPT:+GDI

im also not sure Microsoft support ($$$) is worth it either as yet... Is there any specific ATE logging i should have that "may" help? or does StartDoc() telling all ...

You could activate the LP trace, which might help at least provide some context.

OK, I'll ask them to add TRACE=LP to C:\ATE\miame.ini (and watch) - Thanks.

Getting same error message running AShell 6.5.1663c when using small peer-to-peer configurations without ATE. Have seen it when using servers running different Windows server versions. So far the workstations have all been running Windows 10. Usually occurs in the middle of a series of print sequences. Does not interfere with any actual printing. If you click on OK it continues to print everything.

I didn't realize that it didn't actually abort the print out. That's even stranger, but is perhaps consistent with it being some kind of problem in a low level call that the high-level function (StartDoc, i.e. the one called by A-Shell) doesn't even realize has happened. (Otherwise it would seem that the StartDoc call would abort and you wouldn't get a printout.)

Note that I don't see any reason to associate it with ATE vs A-Shell/Windows P2P, as they both use the identical printing logic.

Not sure if this is related, but also having the entire AShell session abort when attempting to spool to a windows printer that is on a USB connection and being shared on the network by the workstation it is connected too. Put some stop lines in the code and it is getting aborted when trying to making the xcall to the spooler to this specific printer. Going to any other printer connected directly to the network seems to work fine. Happens going peer-to-peer or using ATE. This is the same printer that randomly gives the data area to small error.

Not sure if that's related either, but it does sound reproducible, which is a step forward. Now we just need to capture more detailed traces.

Can you try using SET TRACE LP ON and then PRINT <printer>=<some test file> (where printer is the name of that printer)? That should generate a lot of traces in the debug message window.

If the crash prevents you from capturing those messages (using right-click, select all, copy), then plan B would be repeat the test via ATE and use the ATE capture trace mechanism to hopefully capture those messages to a file. (Settings > Connection Properties > Misc)