目录

简介

先决条件

要求

使用的组件

规则

可能的原因

故障排除

配置过程

TFTP 服务器主机配置过程

建立 TAC 服务请求时要收集的信息

相关信息

简介

本文档解释了软件强制崩溃的最常见原因，并介绍了为排除故障必须收集的信息。如果您对软件强制崩溃开立 TAC 服务请求，则要求您收集的信息对解决问题非常重要。

先决条件

要求

本文档的读者应掌握以下这些主题的相关知识：

- 如何排除路由器崩溃故障。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

规则

有关文件规则的更多信息请参见“ Cisco技术提示规则”。

当路由器检测到严重的不可恢复错误，并且重新加载自身以便不传送损坏的数据时，则表明出现了软件强制崩溃。绝大多数软件强制崩溃是由Cisco IOS®软件错误引起的，但某些平台（如旧版Cisco 4000）可能会将硬件问题报告为软件强制崩溃。

如果未重新启动或手动重新加载路由器，则 show version 命令的输出会显示以下内容：

Router uptime is 2 days, 21 hours, 30 minutes

System restarted by error - Software-forced crash, PC 0x316EF90 at 20:22:37 edt

System image file is "flash:c2500-is-l.112-15a.bin", booted via flash

如果您从Cisco设备获得show version命令的输出，则可以使用Cisco CLI Analyzer(仅限注册客户)来显示潜在问题和解决方法。

可能的原因

下表解释了软件强制崩溃的可能原因：

原因

解释

监视器超时

处理器使用计时器来避免出现无限循环，导致路由器停止响应。在正常操作情况下，CPU 会定期重置这些计时器。如果不这样做，将会导致系统重新加载。报告为软件强制崩溃的监视器超时与软件有关。有关其他类型的监视器超时的信息，请参阅监视器超时故障排除。系统在重新加载前阻塞在一条环路中。因此，堆栈跟踪并不一定是相关的。您可以在以下控制台日志行中识别此类型的软件强制崩溃：
%SYS-2-WATCHDOG: Process aborted on watchdog timeout, process = Exec

and

*** System received a Software forced crash ***

signal = 0x17, code = 0x24, context= 0x60ceca60

内存不足

当路由器的运行内存过低时，它可能会最终重新加载自身并将其报告为软件强制崩溃。在这种情况下，控制台日志中会显示内存分配失败错误消息：
%SYS-2-MALLOCFAIL: Memory allocation of 734 bytes failed from 0x6015EC84,

pool Processor, alignment 0

软件镜像损坏

在启动时，路由器可能会检测到 Cisco IOS 软件镜像已损坏、返回 compressed image checksum is incorrect 消息并尝试重新加载。在这种情况下，该事件将报告为软件强制崩溃。
Error : compressed image checksum is incorrect 0x54B2C70A

Expected a checksum of 0x04B2C70A

*** System received a Software forced crash ***

signal= 0x17, code= 0x5, context= 0x0

PC = 0x800080d4, Cause = 0x20, Status Reg = 0x3041f003

这可能是由于 Cisco IOS 软件镜像在传输到路由器期间已实际损坏所致。在这种情况下，您可以将新镜像加载到路由器上以解决问题。[有关适用于您的平台的 ROMMON 恢复方法，请参阅 Cisco 7200、7300、7400、7500、RSP7000、Catalyst 5500 RSM、uBR7100、uBR7200、uBR10000 和 12000 系列路由器的 ROMmon 恢复过程。]此外，也可能是由于内存硬件故障或软件 Bug 所致。

其他故障

处理器硬件经常会检测到导致崩溃的错误，该硬件将自动调用 ROM Monitor 中的特殊错误处理代码。ROM 监视器可以识别错误，打印消息，保存故障信息并重新启动系统。有些崩溃中什么都不会发生（请参阅监视器超时），而有些崩溃中软件会检测到问题并调用故障转储功能。这是实际的“软件强制”崩溃。在 Power PC 平台上，“software-forced crash”并非调用故障转储功能时列显的重新启动原因 - 至少到目前为止如此。在这些平台上（Cisco IOS 软件版本 12.2(12.7) 之前），这些称为“SIGTRAP”例外。在所有其他方面，SIGTRAP 和 SFC 是相同的。

故障排除

软件强制崩溃通常是由 Cisco IOS 软件 Bug 引起的。如果日志中显示了内存分配失败错误消息，请参阅内存问题故障排除。

如果您没有看到内存分配故障错误消息，并且在软件强制崩溃后未手动重新加载或重新通电路由器，则可以使用的最佳工具是Cisco CLI Analyzer(仅注册客户)，以搜索已知的匹配Bug ID。此工具加入了旧版堆栈解码器工具的功能。

示例：

1. 从路由器收集 show stack 的输出。

2. 转至Cisco CLI Analyzer(仅限注册客户)工具。

3. 从下拉菜单中选择 show stack。

4. 粘贴您收集的输出。

5. 单击 submit。

如果 show stack 命令的解码输出与已知的软件 Bug 匹配，您将会收到最可能导致软件强制崩溃的软件 Bug 的 Bug ID。

6. 单击 Bug ID 超链接查看来自 Cisco Bug 工具包（仅限注册用户）的更多 Bug 详细信息（可以帮助您确定正确的 Bug ID 匹配）。

当您确定了与错误匹配的 Bug ID 后，请参阅“fixed in”字段以确定包含该 Bug 修补程序的第一个 Cisco IOS 软件版本。

如果您不确定该 Bug ID 或不确定包含问题修补程序的 Cisco IOS 软件版本，请将 Cisco IOS 软件升级到版本系列中的最新版本。由于最新版本包含大量 Bug 的修补程序，因此这将会很有帮助。即使这不能解决问题，当您拥有最新版本的软件后，Bug 报告和解决过程也会更简洁快速。

如果在使用Cisco CLI Analyzer后，您怀疑或确实识别出未解决的Bug，我们建议您打开TAC服务请求，以提供其他信息来帮助解决Bug，并在Bug最终解决时更快地通知。

配置过程

如果问题被确定为新的软件 Bug，Cisco TAC 工程师可能会请求您将路由器配置为收集核心转储。有时，需要使用核心转储来确定可以执行哪些操作来修复软件 Bug。

要收集核心转储中更有用的信息，建议您使用隐藏的 debug sanity 命令。这样将会导致在分配缓冲区以及释放缓冲区时，对系统中使用的每个缓冲区进行健全性检查。必须在特权 EXEC 模式（启用模式）下发出 debug sanity 命令，该命令涉及某个 CPU，但不会严重影响路由器的功能。如果要禁用健全性检查，请使用 undebug sanity 特权 EXEC 命令。

对于主内存为 16 MB 或以下的路由器，可以使用简单文件传输协议 (TFTP) 收集核心转储。如果路由器的主内存超过 16MB，建议您使用文件传输协议 (FTP)。请使用此部分中的配置过程，或者参阅创建核心转储。

完成以下步骤配置您的路由器：

1. 使用 configure terminal 命令配置路由器。

2. 键入 exception dump n.n.n.n，其中 n.n.n.n 为远程简单文件传输协议 (TFTP) 服务器主机的 IP 地址。

3. 退出配置模式。

TFTP 服务器主机配置过程

完成以下步骤配置 TFTP 服务器主机：

1. 借助所选择的编辑器在远程主机的 /tftpboot 目录下创建一个文件。文件名为 Cisco 路由器 hostname-core。

2. 在 UNIX 系统上，将“hostname-core”文件的权限模式更改为全局兼容 (666)。 您可以通过 copy running-config tftp 命令检查该文件中的 TFTP 设置。

3. 确保 /tftpboot 下的可用磁盘空间超过 16 MB。

如果系统崩溃，exception dump 命令将会在上述文件中创建输出。如果路由器的主内存超过 16 MB，请使用文件传输协议 (FTP) 或远程复制协议 (RCP) 获取核心转储。在路由器上，配置以下项目：

exception protocol ftp

exception dump n.n.n.n

ip ftp username

ip ftp password

ip ftp source-interface

exception core-file

当您收集核心转储后，请将其上载到 ftp://ftp-sj.cisco.com/incoming（在 UNIX 中，依次键入 pftp ftp-sj.cisco.com 和 cd incoming），然后通知案例所有者并包括文件名。

建立 TAC 服务请求时要收集的信息

如果您在进行以上故障排除步骤之后还需要帮助，并开立一个Cisco TAC案例，请确保包括以下信息：

- show technical-support 输出 – show technical-support 命令的输出提供有关路由器当前状态的信息，以及提供路由器在崩溃之前存储的重要信息。

- 控制台日志 – 控制台日志通常保存在 Syslog 服务器上，可提供有关在崩溃之前发生在路由器上的事件的有用信息。这些线索通常是您能够收集的最重要信息。

- crashinfo 文件（若有）– Cisco 建议您使用支持 crashinfo 功能的 Cisco IOS 软件版本，以便顺利进行故障排除。为此，该版本必须满足您的网络的其他需要。请参阅从 Crashinfo 文件检索信息，或使用 Software Advisor（仅限注册用户）工具查找支持 crashinfo 功能的 Cisco IOS 软件版本。潜在的好处是，如果您有早期版本的 Cisco IOS 软件，则支持此功能的更新版本 IOS 软件可能已将 Bug 修复。

要在您的服务请求中附加信息，请通过 TAC 服务请求工具（仅限注册用户）上载它。 如果您无法访问 TAC 服务请求工具，则可向 attach@cisco.com 发送一个电子邮件，在该邮件的附件中提供此信息，并在邮件的主题行中注明案例号。
注意：如果可能，在收集上述信息之前，请不要手动重新加载或重新通电路由器，因为这可能会导致丢失确定问题根本原因所需的重要信息。

相关信息

- 路由器崩溃故障排除

- 从崩溃信息文件中检索信息

- 创建Core Dump

- 排除内存问题

- 技术支持 - Cisco Systems