Use this article to determine the action to take if you encounter a compatibility problem between a Trellix product and third-party software.
We work with all third parties to understand the root cause of the problem, and where needed address it with a product fix or workaround. But, we might require that the customer open a ticket with the third-party vendor if investigation determines that the cause of the problem
isn't our product
. In addition, all parties might need to attend a conference call to work toward a resolution.
Perform the following steps:
- Check whether there’s a known issue between the third-party software and our product. When we are aware of a compatibility problem, we document the problem in our Knowledge Base. The Knowledge Base article is updated with any known workaround or product fix when available. If the cause of the problem is the third-party software, we document the workaround or solution provided by the vendor of the third-party software.
- Perform troubleshooting to investigate the cause of the problem:
- If our investigation determines that the cause of the problem is our product, Technical Support will open a defect against that product. We will provide a workaround or product fix.
- If our investigation determines that the cause of the problem isn’t our product, continue to step 3.
- Contact the vendor of the third-party software and open a ticket.
The first responder in a software compatibility problem must be the vendor whose software behaves unexpectedly. The first responder debugs the unexpected behavior of their software. One of the following events occurs:
Important information about third-party and proprietary software: The previous procedures are a technical necessity because in proprietary closed-source software, the private symbols needed to debug applications are intellectual property restricted by the vendors. If these private symbols were publicly disclosed, the software could be reverse engineered. We don’t own or have access to these proprietary symbols or source code.
Glossary:
- Debugging Software (or "debugger"): The software that a developer uses that helps determine a failure point by using symbols or source code.
- Closed-Source Code: The original code that comprises the process or driver; privately secured and publicly unavailable.
- Open-Source Code: The original code that comprises the process or driver; publicly available.
- Private Symbols: Files used by a debugger to show function names and source code file names; privately secured and publicly unavailable.
- Public Symbols: Files used by a debugger to show only function names; publicly available.
Companies such as Red Hat are open source, and release their source code and private symbols. Other companies, such as Microsoft and Trellix, are closed source and release public symbols at the most. Closed-source code and private symbols exist to protect a vendor’s intellectual property from being publicly available, and allow software sales to remain a part of their income portfolio.
Microsoft code is almost always closed source. Microsoft sometimes releases public symbols so that third-party vendors can view all Microsoft function names that are invoked when debugging their third-party software. But, function names are all that third-party vendors can determine about Microsoft code. Microsoft must use its closed-source code and private symbols to determine why its code behaved in the manner it did. This fact is a limitation in the world of closed-source software interoperability.