Problems with printings

Question

Problems with printings

Anonymous

Hi,

I have a problem with printing using your tools.

At the beginning I would like to bring you closer to understand my solution.

Customer has about 17 Domino printers (model M230i-F100 RH (300 dpi))
Operating system: Windows Server 2019 Datacenter.
All of printers are installed on Windows with driver: M-DRIVERUNI in version 4.0.9.0 downloaded from domino's website.
Our printing service is using DevExpress Reporting Tools in version 23.1 as well as print content is being prepared with same package.
System prints production lot number related labels, which is being changed each hour.
According to previous point system sends new print job to printers each hour automatically – without user interface using default print preferences for user, which credential are used to run service.
Auxiliary end user is allowed to trigger this UI-less print on demand to enable reprint when error occurred.

Unfortunately, despite mostly trouble-free operation the customer still has some repeatable problems with printers and so on. Please help me to investigate problems listed below.

Print buffer crashes when some of labels are printed (this is most important thing , because it stops entire print buffer, and there is no printers available).
Sometimes when some kind of labels are sending to the driver print buffer crashes with error (event viewer):
„Nazwa aplikacji powodującej błąd: spoolsv.exe, wersja: 10.0.17763.4644, sygnatura czasowa: 0xacbcf874
Nazwa modułu powodującego błąd: ntdll.dll, wersja: 10.0.17763.5933, sygnatura czasowa: 0x28f68183
Kod wyjątku: 0xc000041d
Przesunięcie błędu: 0x0000000000010633
Identyfikator procesu powodującego błąd: 0x388
Godzina uruchomienia aplikacji powodującej błąd: 0x01dad68ef68d6eb2
Ścieżka aplikacji powodującej błąd: C:\Windows\System32\spoolsv.exe
Ścieżka modułu powodującego błąd: C:\Windows\SYSTEM32\ntdll.dll
Identyfikator raportu: 82f36e2f-2f4b-4164-a28d-654b71f7b666
Pełna nazwa pakietu powodującego błąd:
Identyfikator aplikacji względem pakietu powodującego błąd:”
Google translated: "Faulting application name: spoolsv.exe, version: 10.0.17763.4644, time stamp: 0xacbcf874Faulting module name: ntdll.dll, version: 10.0.17763.5933, time stamp: 0x28f68183Exception code: 0xc000041dFault offset: 0x0000000000010633Faulting process id: 0x388Faulting application start time: 0x01dad68ef68d6eb2Faulting application path: C:\Windows\System32\spoolsv.exeFaulting module path: C:\Windows\SYSTEM32\ntdll.dllReport ID: 82f36e2f-2f4b-4164-a28d-654b71f7b666Faulting Package Full Name:Faulting Package Relative Application ID:"
Current state: No solution. When it takes place, I have to find trouble causing label and disable this prints, after what i have to restart print buffer and return to production.
Additional Info: I know one of problem causing this crash, and know how to fix it (point 1.1 below), and one, which I know but not resolve it yet (point 1.2).
1.1 When label frame touches paper edge (panel with frame). To resolve this I've moved all elements few pixels to make a spacing between frame and paper edge.
1.2 When label contains a specific field in model. Customer change the dynamic field to static field in label template and everything works…, but it's not a solution. When I print it via Send to onenote or similar - there is no problem with print.
Print spooler takes too much ports.
During working print spooler is taking a lot of ports in BOUND state. As far as I know there is prepared port to establish a connection but no connection is being made. If we left it as is, the port counts is rising until there is no more resources and entire communication crashes. I just checked that now in 3 hours there is 875 ports taken by spooler service.
Current state: I had added a job which restart print spooler daily morning.
Sometimes empty label is printed.
Sometimes (randomly), when the printings is automatically triggered, an empty label is being printed until end user repeat printing.
Current state: Operators trigger prints one more time after empty label reveals.
Sometimes nothing is changed.
Sometimes (randomly), previous label is being still printed despite new label has been sent to device.
Current state: Operators trigger prints one more time after situation occured.

Thank you in advance for your help.

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question. To protect privacy, user profiles for migrated questions are anonymized.

2 answers

Answer 1

Hello,

Thank you for posting in the Microsoft community forum.

Regarding print buffer crashes, please check that all printer drivers and firmware are up to date. Verify that 4.0.9.0 is the latest version on the Domino website. You mentioned that the crash occurs when there are specific fields in the tag, but converting dynamic fields to static fields is a temporary fix, and it is recommended that you check whether the encoding formats of these fields are compatible.

I understand the issue of Print spooler taking up too many ports. You mentioned that you have added the task of restarting the print daemon every morning, and you can shorten the restart interval depending on the production environment. At the same time, check and optimize the port usage policy of the print server. For example, set an appropriate number of concurrent print jobs to process only a certain number of jobs at a time. Also, look at the system and application logs to see if there are specific patterns or anomalies that cause a large number of ports to be occupied.

The problem of randomly printing empty labels can be caused by data loss in the print queue or by the device not responding for a while. First, check whether the network connection is stable to avoid packet loss during data transmission or empty labels caused by network delay. Ensure that the print job has accurate and complete data before it is queued. Also, clean the print daemon cache regularly to avoid old data residue.

I hope this helps.

Best regards

Jacen

Answer 2

Well, please find below my answers.

Regarding print buffer crashes, please check that all printer drivers and firmware are up to date. Verify that 4.0.9.0 is the latest version on the Domino website.

I asked customers IT department to review driver version but it seems to be a problems with driver, and it's been reported to provider. On the other hand i'm still curious why entire print spooler "explodes" instead of one printer ?! Shouldn't it be handled and reported but still provide service on other printers?

You mentioned that the crash occurs when there are specific fields in the tag, but converting dynamic fields to static fields is a temporary fix, and it is recommended that you check whether the encoding formats of these fields are compatible.

Those were the exactly same fields differs only data inside (provided by DB or hardcoded).

I understand the issue of Print spooler taking up too many ports. You mentioned that you have added the task of restarting the print daemon every morning, and you can shorten the restart interval depending on the production environment. At the same time, check and optimize the port usage policy of the print server. For example, set an appropriate number of concurrent print jobs to process only a certain number of jobs at a time. Also, look at the system and application logs to see if there are specific patterns or anomalies that cause a large number of ports to be occupied.

I already did something like this - there is only one print job processed at one time in my application, with delay between, but it is only for inserting it into a queue. Did you mean something like that or other windows configuration ? Can you provide me some guide how to do it (or documentation)? Auxilitary, together with customers IT department we start to check a "print directly to the printer" checkbox - we will see if it'll help us.

The problem of randomly printing empty labels can be caused by data loss in the print queue or by the device not responding for a while. First, check whether the network connection is stable to avoid packet loss during data transmission or empty labels caused by network delay. Ensure that the print job has accurate and complete data before it is queued. Also, clean the print daemon cache regularly to avoid old data residue.

Well, print buffer is being clean as well, but we believe that it will be a temporary solution. As i mention before we're using 3rd party libraries for printing and I hope that everything is ok. I also asked IT department to monitor network load in next days. Then i'm wondering one more time, if there is some problems with communication as you assume - how can i check logs or something like that ? I can not find a trace that can help me what goes wrong.

Share via

Problems with printings

2 answers