Home

Decrypting the Crash: The Definitive Guide to FortiGate Crash Logs in the CLI

.

Navigating the Command Line Interface (CLI) of a Fortinet firewall can often feel like deciphering an ancient script, particularly when the network is down and a device has just crashed. Unlike Cisco’s ubiquitous show command, FortiOS presents a fragmented trio of get, diagnose, and execute.

When a FortiGate process dies, it leaves behind a digital fingerprint. Retrieving that fingerprint is the most critical step in root cause analysis. However, a long-standing point of confusion in the Fortinet community revolves around why two very similar commands exist—and why one of them often appears hidden.

Based on community posts, official documentation, and expert cheat sheets, this article consolidates everything you need to know about checking crash logs via CLI, ensuring you send the right data to TAC (Technical Assistance Center) the first time.

The Great Debate: diag debug crashlog get vs read

The most frequently asked question regarding FortiGate crash logs is not about where they are, but how to read them. According to a long-running thread on the Fortinet Community Forum, there is a distinct technical difference between the two primary commands:

  • diag debug crashlog get : This command outputs the crash log in an encrypted or raw binary format. While it confirms a crash occurred, it is generally not human-readable and is often ignored by support engineers when provided via copy-paste.
  • diag debug crashlog read : This command outputs the same data in a deciphered, human-readable text format. It displays the register dumps, backtraces, and signal errors (such as Segmentation fault) necessary for troubleshooting.

Critical Insight: As confirmed by multiple users in the forum discussion, the read option is frequently "hidden." Even if diag debug crashlog ? does not list read as an available option, the command will work if crash logs exist.

Standard CLI Syntax & Interpretation

While FortiWeb appliances utilize the syntax diagnose debug crashlog show, the standard for FortiGate (FortiOS) is unified around the read command.

The Primary Command:

diagnose debug crashlog read

Understanding the Output

When a crash occurs, the output is not random garbage; it is a structured dump. Using the example from the FortiWeb documentation (which is structurally identical to FortiGate dumps):

2011-02-08 06:20:46 <18632> *** signal 11 (Segmentation fault) received *** 2011-02-08 06:20:46 <18632> Register dump: 2011-02-08 06:20:46 <18632> RAX: 00000000 RBX: 00000001 RCX: 00000001 2011-02-08 06:20:46 <18632> Backtrace: 2011-02-08 06:20:46 <18632> [0x008d8660] => /bin/xmlproxy (g_proxy+0x00000000)
  • Signal 11: Indicates a segmentation fault—the process tried to access a memory location it wasn't allowed to access.
  • Backtrace: Shows the last function the process was executing before dying (e.g., xmlproxy).
  • Status Code: The status of "0" in the crashlog usually indicates a normal close of a process, whereas other codes indicate true faults.

The "No Logs" Scenario: Complementary Diagnostics

If diag debug crashlog read returns nothing, it does not always mean the device is healthy. As noted in a Reddit discussion regarding a FortiSwitch crash, the absence of a log often necessitates hardware-level checks.

If the crashlog is empty, escalate to the following hardware diagnostic commands:

  1. Check Power and Environmentals:

    execute sensor list

    Checks for power supply failures or overheating.

  2. Interface Hardware Stats:

    diagnose hardware deviceinfo nic <port> # or fnsysctl ifconfig <port>

    These "hidden" commands often reveal physical layer errors not shown in the GUI.

Best Practices for Crash Log Management

Based on the aggregation of community expertise, the following workflow is recommended for any crash investigation:

Step 1: Attempt to Read (Even if Hidden) Do not rely on tab-completion. Type the full command: diagnose debug crashlog read

Step 2: Differentiate Application vs. Kernel If the log mentions kernel, the issue is likely driver or hardware related. If it mentions specific binaries like xmlproxy, httpsd, or sslvpnd, the issue is application-specific.

Step 3: Provide Context to TAC When submitting logs to Fortinet Support, do not use get. Use read. Additionally, include the output of get system status and diagnose sys top to correlate the crash time with CPU/memory spikes.

Step 4: Clear the Log After capturing the data, clear the log to ensure future crashes are easily identifiable: (Note: Clear syntax varies; usually diagnose debug crashlog clear)

Summary: CLI Quick Reference

Objective Command Source Insight
Read Crash Log diag debug crashlog read Works even if hidden from auto-complete.
Raw/Encrypted Log diag debug crashlog get Not human-readable; avoid for TAC.
FortiWeb Syntax diagnose debug crashlog show Specific to FortiWeb platforms.
Hardware Health execute sensor list Use when crashlog is empty.
Interface Errors fnsysctl ifconfig Reveals physical/nic errors.

Frequently Asked Questions (FAQ)

Why does diag debug crashlog read not appear when I press ??

This is a common CLI quirk in FortiOS. The command is often present in the binary but missing from the help text. Type the command manually and execute it; it will likely work.

I ran diag debug crashlog get and saw hieroglyphics. Is my FortiGate broken?

No. You are viewing encrypted or raw binary data. Use read instead of get to decode it.

Can I view crash logs from the GUI?

Generally, detailed kernel/application crash logs with backtraces are only available via the diagnose CLI commands. The GUI primarily shows event logs, not process core dumps.

My switch crashed, but the FortiGate shows nothing. Where do I look?

Connect directly to the FortiSwitch via its own console/IP and run diagnose debug crashlog read. Crash logs are device-specific and not automatically aggregated to the parent FortiGate.

What is a normal crashlog?

A log showing a status of 0 or a clean exit of a process due to a service restart is normal. Logs showing signal 11 (SEGV), signal 6 (ABRT), or memory register dumps indicate abnormal termination.