我遇到了我们客户的崩溃转储，他们遇到了我们无法复制的问题，他们也不能，但是当他们向最终用户发布产品时，它通常会崩溃。因为这很难破译正在发生的事情，我们从他们那里得到了一个崩溃转储，让我说我还在学习WinDbg和崩溃转储分析。它是一个.net应用程序，可以在我们的非托管dll中进行操作。我没有看到我们的模块在崩溃时列在线程的任何调用堆栈上，所以乍一看它似乎不是我们的错。此外，客户不能共享实际应用程序，也不能发送一个合理的样本，模仿他们因安全限制而正在做的事情。
但是最终用户最近才升级到更新版本后才开始体验这个问题，所以虽然它不能证明我们有问题但似乎很有可能。
所以我不期待对我的问题有一个神奇的答案，我或多或少都在寻找技术或者只使用转储导致这种崩溃的方法。
我怀疑它是堆损坏，因此实际发生了损坏，但直到很久之后才会导致进程崩溃。可疑线程的调用堆栈不会给我们带来太大的影响，看起来像是不会被释放的东西，并且报告了访问冲突。
需要注意的是，异常上下文记录（.ecxr命令）似乎已被删除。所以esp = 0和ebp = 0，这让我想知道我是否能从这个崩溃转储中获得任何有价值的东西，因为根据我的经验，直到这一点我通常可以从.ecxr获得一个有效的调用堆栈。但是，如果我查看可疑线程的调用堆栈，我会得到一个有效的调用堆栈。调试器的启发式（！analyze）除了释放一些不应该被释放的内存之外，不会给我太多的洞察力。
一个好主意是让客户在GFlags.exe中启用Page Heap，以便在发生损坏时尽快发现损坏，但由于客户的设置可能不会发生。所以我必须假设这个崩溃转储是我从他们那里得到的全部，我必须单独解决这个问题。
我发现自己正在转动这个问题，想想如果我读到一些非常困难的崩溃转储分析的故事可以与我分享它可以给我一条新的尝试路径。我可以阅读一些装配，但在这个领域的专家看来，在诉诸这个之前，他们有很多技巧，我希望他们可以与我分享一些。