DYMO Label Web Service Printing Slow

Question

I am noticing a delay of 5 to 15 seconds when printing using the DYMO Label Web Service starting this morning, 4/23/2018. This happens on multiple PCs on all browsers. On a Mac it works fine.

The log at %LocalAppData%\DYMO\DLS8\DLSWebService.log seems to show the delay. I don't see any errors in the Console beyond the usual Synchronous XMLHttpRequest on the main thread is deprecated warning.

DYMO.DLS.Printing.Host.exe Information: 0 : PrintLabel: DYMO LabelWriter 450 Turbo
    DateTime=2018-04-23T17:08:34.9541652Z
DYMO.DLS.Printing.Host.exe Information: 0 : Loading barcode lib from C:\Program Files (x86)\DYMO\DYMO Label Software\MDYMOBarcode.dll
    DateTime=2018-04-23T17:08:50.1456872Z
DYMO.DLS.Printing.Host.exe Information: 0 : Utils.CreateLabelPrintParams(): printParams == null, creating default printParams based on printer type
    DateTime=2018-04-23T17:08:50.1547276Z
Status for job sent to printer DYMO LabelWriter 450 Turbo i False
DYMO.DLS.Printing.Host.exe Information: 0 : CheckServiceStatus
    DateTime=2018-04-23T17:08:51.3098746Z
DYMO.DLS.Printing.Host.exe Information: 0 : GetPrinters
    DateTime=2018-04-23T17:08:51.3269198Z

I tried updating to DLS8Setup.8.7.exe but this did not help.

Answer 1

I broke out Procmon and got to the bottom of this.

It appears to be due to the Dymo Label Service querying 128.30.52.100 (hans-moleman.w3.org) every time it was fed a label to validate its schema. We were not being rate limited by this service until today.

Setting an outbound firewall rule against this IP address for the DLS service executable fixed the issue.

Answer 2

We just ran into this as well. Apparently the Dymo print service is trying to validate the generated xml against an xsd file. That file is not cached, so the print service is hitting w3.org to download it. Some time recently w3.org stopped responding to this request, making the xml validation slow as the request times out. So this is unrelated to any Windows update, update to the Dymo print service, or update to any browser.

If you run this command in Windows power shell as an administrator (and the path to your service is the same as ours), it will block the call to w3.org, causing it to fail fast instead of slow and move on to printing.

New-NetFirewallRule -DisplayName "dymo-xsd-exclude" -Direction Outbound -Action Block -Program "C:\Program Files (x86)\Dymo\DYMO Label Software\DYMO.DLS.Printing.Host.exe" -RemoteAddress 128.30.52.100

This is a short term solution. The correct solution is for Dymo to update their print service to include the xsd instead of calling across the internet for it.