Bartender integration....stopped working? Printer stalled?

Hi all,

Something completely abrupt happened last night - all 3 of our integrations just stopped working. The only error message that I get is that the printer stalled after bartender waits for about 30 minutes, I get the below message:

Failed to run action ‘Print Command Script’. Details: The print job for document ‘\<>\BARTENDER\LabelDesigns\Receipt_Label\ReceiptLabel.btw’ and printer ‘\<>\<>’ has stalled. A restart will be attempted. If the problem persists verify that the printer is online, able to process the print job, and the network connection (if present) is valid. If the print job is known to take a significant amount of time to print consider increasing the print scheduler’s unresponsive job timeout. See Seagull’s online knowledge base at support.seagullscientific.com for more details.

We didn’t change anything but all of the integrations stopped working! We just installed Sophos endpoint agent on all of the servers, but that shouldn’t have impacted anything, because from the server where the integration file is hosted and running, i tried to a) ping the print server and it worked b) install the label printer directly on that server using the UNC and again it worked c) do a test print via the print server as well as the server hosting bartender and it worked d) opened bartender label designer and sent the print command to the same printer via the UNC and it worked!

Let’s summarize the facts:

:white_check_mark: Label opens manually.

:white_check_mark: Label prints manually.

:white_check_mark: Data file is valid, all text within the data file is valid and how it was supposed to be .

:white_check_mark: Printer works.

:white_check_mark: Printer queue never receives a job from the integration.

:white_check_mark: Integration detects the file.

:white_check_mark: Integration renames the file.

:white_check_mark: Integration executes the Print Command Script.

:white_check_mark: All 3 integrations stopped working at the same time.

:white_check_mark: Started overnight with no intentional changes.

:white_check_mark: I have tried restarting all the services listed under Windows Services (Bartender system services, integration services, printer scheduler, windows print spooler)

:white_check_mark: I have tried changing the logon account in bartender integration service - changed it from local account to my account that was able to print on the label printer

Screenshot here

I’m at a loss. What do I do to fix this?

Have you tried a different .btw file? have you tried with firewall off?

The 3 most important facts in your list are:
integration detects the file
integration renames the file
integration executes the print command script

if by renaming the file, you mean that the file extenstion changes from (for example) .btw to .btp, then essentially bartender is doing what it’s supposed to.

Bartender doesn’t exactly “connect” to kinetic or epicor. it just looks, listens, observes, your shared location for files with an expected extension, and then reads them, and then moves them to a new file that indicates the file has been processed.

the way that you are describing everything, it’s suggesting that somehow, something changed a directive in the btw file somehow. perhaps one of the attributes in the header of the print object isn’t directing the printer to print. maybe the count is 0? It doesn’t sound like anything is broken or you should get an error file. it just sounds like something is telling it either not to print or to print something the printer doesn’t understand. Perhaps something in the data is breaking the markup in a way that looks valid but still can’t be processed

I have had issues to with the integration just stops and I found an error in the event logs on the server showing bt. exe (IIRC) crashing if I recall, restarting the print sheduler fixed the problem. At least until it failed again. We are the latest - 1 version of bartender. I ended up creating a scheduled task that runs to restart the service when the error turns up in the logs

It seems that something happened, at least for us by a window update or some other update. (. net or c ++ runtime) although we have done a repair on the latter with no perceived improvement.

My suggestion is check your sophos exclusions as well as testing with a different BTW fule as suggested previously just to confirm.

You didn’t mention if you saw anything in the history explorer, which I find is a useful tool.

Thank you to everyone who contributed to this post. Turns out, this was an internal error, our MSP (external IT) told us that a junior changed the DNS settings on the print server without understanding the consequences and the remote server wasn’t able to talk to the printer.

I thought that the test print went through from the remote server but apparently it had not.

This issue has been fixed.