想想你为什么要这样做。在我看来，完全没有意义。

如果异常发生在服务器端，则在那里处理并记录它。向用户显示堆栈跟踪绝对没有意义。

如果异常发生在客户端，在厚客户端风格的 Web 应用程序、桌面应用程序、移动应用程序等中，加密它绝对没有意义。任何确定的足够用户都可以反编译或反向工程客户端代码。实际上，您将如何加密数据？加密意味着一个加密密钥，这个密钥必须存储在某个地方。

我还质疑显示堆栈跟踪时普通用户可以做什么。如果崩溃数据是重要信息，请实现某种诊断报告功能。

堆栈跟踪很少包含任何涉及安全问题的信息。当然，它可能会显示源文件的名称、行号和函数名称，但我几乎无法想象在任何情况下这些都是有价值的信息。特别是考虑到此信息存储在用户机器上运行的程序的可执行文件中。用户可以在需要时手动从应用程序中提取该信息。

人们可能会从用户体验的角度争论此信息是否对用户有用。这可能有助于他们自我诊断问题。他们可以将堆栈跟踪输入搜索引擎，并可能找到遇到相同问题并以某种方式解决的人。一个特别精通技术的用户甚至可以使用这些信息自己诊断问题（例如，当堆栈跟踪位于图形 API 的函数中时，问题可能是我的显卡驱动程序）。然而，不太精通技术的用户可能会被过于冗长的错误消息弄糊涂。但正如我所说，这完全是用户体验问题，与安全无关。

我猜这不是一个 Web 应用程序（您可以在服务器上记录堆栈跟踪），而是一个桌面应用程序之类的东西？

举个例子：我在本地运行程序，它崩溃了。我收到一条消息，我可以将问题报告给开发人员。我想看看发送了什么。然后我看到一些加密信息。我想知道它是什么，我想知道这些程序是否会向开发人员发送一些私人信息。那么隐私呢？你如何保证不发送个人信息？

如果您正在处理 .Net 应用程序，则没有太多理由对其进行加密，除非您使用的是非常好的混淆器。.Net 可以很容易地反编译，并且在王国的密钥已经出来打开之后加密堆栈转储并不是那么有帮助。

如果他们在本地运行它，那么他们就有能力直接更改和分析代码，包括附加调试器和简单地自己捕获堆栈。如果它在服务器上运行，那么您可以记录它而不是向用户显示它。

普通用户将无法使用调用堆栈，任何可以使用的用户都已经了解反射器等工具以及如何使用调试器来捕获信息。

如果您实际上正在使用混淆，那么是的，加密堆栈跟踪可能有助于使提交给您的数据更有可能保持不变，并保护有关调用堆栈的信息免受将使用的攻击者它试图找出混淆，尽管经过适当的混淆，大多数调用堆栈无论如何都会被打乱，因为用无用的名称替换有意义的名称是混淆器首先要做的事情之一。

我可以看到加密您的崩溃报告的主要原因是减少有人篡改崩溃报告的可能性，并保护报告中包含的任何用户数据。我真的没有看到用户可以收集的有关调用堆栈的信息是一个主要问题，至少对于 .Net 应用程序来说不是。