Can't print from an endpoint

Issue

This article helps troubleshoot scenarios where the ThreatDown Endpoint Agent causes the printer to appear offline, prevents print jobs from being sent, or blocks communication with network and local printers. Common symptoms include the printer showing as offline in Windows/Mac print queues, even though it's powered on, connected, and pingable.

ThreatDown's protection layers, such as Web Protection and Exploit Protection can sometimes interfere with printer protocols (e.g., SNMP status checks on network printers or print spooler communications). Layer testing is typically required to identify the responsible component.

Important Note: Printer issues with security software like ThreatDown are not uncommon, especially with network printers using TCP/IP ports where features like SNMP can trigger false positives in protection modules.

Before starting:

• Ensure you have admin rights on the affected machine.
• Confirm the printer is powered on, connected (USB/network), drivers are up to date, and try printing a test page directly from the printer or another non-protected device if possible.

Troubleshooting

Work through the following tasks in order until the issue is identified.

Task 1: Identify the problematic Protection layer 

To pinpoint which ThreatDown protection layer is causing the issue, perform systematic layer testing.

1. Enable Debug Logging on the endpoint to get detailed logging for troubleshooting.
2. Start Layer Testing
3. As soon as printing works, note down the problematic protection layer.
4. Confirm the Layer:
   1. Re-enable all other layers, but leave only the suspected problematic layer enabled.
   2. Attempt to print again. If the issue reproduces (printer goes offline/unable to print), this confirms the layer.
   3. This step is crucial for accurate log collection and support escalation.

Task 2: Collect Logs While Reproducing the Issue

Once the problematic layer is identified, keep it enabled, then reproduce the printing failure and gather logs while the issue is occurring.

• Required logs based on layer:
  • Web Protection issues → Debug logs
  • Malware layer → Debug logs & Procmon (Process Monitor)
  • Exploit layer → Debug logs
  • Behavior protection → Debug logs & Procmon
  • EDR (critical - collect twice!):
    1. With RTP disabled + EDR Enabled → Reproduce issue → Collect Debug logs, Procmon, Xperf logs & note exact timestamp.
    2. With RTP disabled + EDR Disabled → Reproduce (it should work) → Collect the same logs & timestamp for comparison.
• How to collect:
  • Debug logs: Already enabled; Collect diagnostic logs
  • Procmon: Download Sysinternals Process Monitor, run it during reproduction, filter for printer-related processes (e.g., spoolsv.exe), save capture.
  • Xperf (for EDR): Use Windows Performance Recorder or xperf commands to capture traces during the test.

Once you have the appropriate logs, contact Support.

Task 3: Resolution and Next Steps

• Temporary workarounds while awaiting Support:
  • If access to the printer is required, keep specific endpoints in the test group and policy with only the problematic layer disabled. For other endpoints, keep them in their original policies and groups for maximum protection.
  • For network printers: In printer port properties (Devices and Printers > Printer > Printer Properties > Ports > Configure Port), disable SNMP Status Enabled. 
  • Restart Print Spooler service: Go to services.msc > Print Spooler > Restart.