- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
I have been having difficulty finding detailed documentation about the TDERROR mechanism. The closest definition I have found is the following:
'TdError, a Check Point infrastructure for reporting messages and debug information. There is no legal list of topics. It depends on the application or module being debugged. To debug all available topics, use: ALL for the debug topic....A topic is a specific area on which to perform debugging, for example if the topic is LDAP, all traffic between the VPN daemon and the LDAP server are written to the log file. Levels range from 1-5, where 5 means "write all debug messages" (http://dl3.checkpoint.com/paid/c7/c76b823d81bab77e1e40ac086fa81411/CP_R77_versions_CLI_ReferenceGuid... )'.
I'm aware that the said mechanism is typically used when debugging processes and daemons as detailed on sk97638. Most of the time it would take the following form:
fw debug [name-of-daemon/process-goes-here] on TDERROR_ALL_ALL=5
***Replicate issue***
fw debug [name-of-daemon/process-goes-here] off TDERROR_ALL_ALL=0
So my question is, does anybody have a list of the available topics of each possible app/module that the TDERROR mechanism could be fed instead of having to turn on all topics all the time? According to the aforementioned link, "there is no legal list of topics" but I was still wondering if there is anybody who could still provide us with one.
Thanks in advance.
Hi,
1. No
2. Another short answer. Use 5.
You won't find much documentation on the TDERROR debug framework itself.
I would also like to see some.
Don't get frustrated. It is just a Check Point thing.
The Check Point advice is most probably going to be to open a ticket when help is needed and don't get caught up in the details.
My advice is, do what you can to solve technical problems and learn as much as possible but always call for help when it is needed.
If you search tderror on support center then you will see examples of its usage (assuming you have full access to SK levels).
I did a quick study on debug levels and will try to attach the docx but in summary level 3 is the minimum I recommend and level 5 is most commonly used.
I think of APPLICATION in terms of the processes e.g. fwm, and their specific tasks.
For example: AUTH may be used when debugging fwm so that debugging fwm is somewhat limited to only debugging the authentication task/operation which fwm is involved in (during SmartConsole login, for example).
Other references:
https://community.checkpoint.com/t5/General-Topics/TDERROR-Topics/td-p/34428#M7235
You might be interested to read this thread too.
https://community.checkpoint.com/t5/Management/Debug/m-p/50089
In the various ATRG and troubleshooting SKs you will find TDERROR references.
I am unaware of a comprehensive list and, outside of context of a troubleshooting document, I’m not sure such a list would have value.
Well, I believe it would have some value in that we would be able to capture the more interesting information about the topic we are troubleshooting rather than having to capture all of them and try to weed out what's more relevant...
The problem is that you may think a particular topic is irrelevant to an issue when, in fact, it is.
Which is why I say: stick with the official troubleshooting/debugging SKs.
TDERROR is an internal Check Point mechanism to debug certain User Mode processes. The flags are ranged from 0 to 10 concerning amount of output, where level 10 prints out way too much. For all needs and purposes on the field the range between 3 and 5 is advised.
Any chance one of you guys can write an SK on the TDERROR or get someone in R&D to do it?
It would be really useful to have that and close some gaps in the information around debug framework.
It is used in a lot of procedures!
Here is some supporting text from the CCTA training course manual:
NOTE: TDERROR is an internal Check Point mechanism to debug specific user mode processes. With TDERROR, a specific feature in a specific process with a specified level of importance can be debugged using the following syntax:
TDERROR_<Application>_<Topic>=LEVEL
Level is an integer between 1 and 5. It indicates the amount of information desired, where Level 1 provides the least information and Level 5 provides the most information. To debug all available topics, use the syntax ALL as the debug topic.
And this is from the CCTE course:
TDERROR is a general debugging framework that Check Point- developed processes can use for extensive debugging.
With TDERROR, a specific feature in a specific process with a specified level of importance can be debugged using the following syntax:
TDERROR_<Application>_<Topic>=LEVEL
Level is an integer between one and five. The level indicates the amount of information desired. A level of one provides very little information. A level of five provides an extensive amount of information.
To debug a policy installation, run the following commands:
fw debug fwm on TDERROR_ALL_INSTMGR=5
fw debug fwm on TDERROR_ ALL_INSTMGRFN=5
To stop the debug, run the following commands:
fw debug fwm off TDERROR_ ALL_ ALL=0
Use CTRL+C to stop the tail.
As you can see there is an example that uses the Topics INSTMGR and INSTMGRFN.
But there is no more detail on TDERROR and the actual 1 through 5 debug levels or the Topics, even though it is only two of the ?? topics that could possibly be used.
Thanks,
Don
A question that I got about TDERROR is:
Regards.
Hi,
1. No
2. Another short answer. Use 5.
You won't find much documentation on the TDERROR debug framework itself.
I would also like to see some.
Don't get frustrated. It is just a Check Point thing.
The Check Point advice is most probably going to be to open a ticket when help is needed and don't get caught up in the details.
My advice is, do what you can to solve technical problems and learn as much as possible but always call for help when it is needed.
If you search tderror on support center then you will see examples of its usage (assuming you have full access to SK levels).
I did a quick study on debug levels and will try to attach the docx but in summary level 3 is the minimum I recommend and level 5 is most commonly used.
I think of APPLICATION in terms of the processes e.g. fwm, and their specific tasks.
For example: AUTH may be used when debugging fwm so that debugging fwm is somewhat limited to only debugging the authentication task/operation which fwm is involved in (during SmartConsole login, for example).
Other references:
https://community.checkpoint.com/t5/General-Topics/TDERROR-Topics/td-p/34428#M7235
You might be interested to read this thread too.
https://community.checkpoint.com/t5/Management/Debug/m-p/50089
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
12 | |
12 | |
10 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 | |
5 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY