这是Linux核心转储吗？如果是这样的话，你可以用gdb来检查它。你需要在一个具有相同操作系统和Python版本的系统上运行，包括第三方库。运行gdb -c /path/to/core/file。一旦gdb加载完毕，命令bt将列出主线程的堆栈跟踪，而thread apply all bt将列出所有线程的堆栈跟踪。
这有多有用取决于Python的版本是否包含完整的符号表（即Python的调试版本）-如果没有，那么你将只看到地址作为到主要C入口点的偏移量。然而，这仍然可以在诊断哪里出了问题时有所帮助。
如果是其他不支持gdb的操作系统，那么你就只能靠自己了--大概这个操作系统会有自己的调试工具。

编辑：

Python wiki上有一个页面描述了how to get a python stack trace with gdb。
然而，快速浏览一下问题中的链接会发现操作系统是Windows，所以gdb没有用。Windows转储中的信息很少，所以我认为你运气不好。
我唯一的建议是：
1.试图在内部重现坠机过程
1.让用户重现错误，同时运行一个工具，该工具将捕获崩溃并进行适当的内存转储。自从我进行认真的Windows调试以来，大约有十年了，所以我不知道现在有什么工具可用-曾经有一个叫做Dr.沃森的工具，但它可能已经过时了。
如果用户不能重现崩溃，那么你就不走运了，另一方面，如果它永远不会再次发生，那就不是一个大问题。

更新：

谷歌告诉我，沃森博士仍然是Windows XP的默认崩溃处理程序（以及其他版本的Windows）-问题中链接的堆栈转储可能来自它。然而，沃森博士保存的默认数据相当少，但您可以将其配置为保存更多-参见this article。简而言之，如果你运行drwtsn32 -i它会弹出一个对话框让你设置选项.

Python源代码树中有一个名为gdbinit的文件（在Misc/gdbinit中），它为gdb提供了一组宏，以便显示当前的解释器上下文。只需在gdb中键入source gdbinit，然后就可以执行诸如pystack之类的宏。可用宏的列表可以通过阅读文件的源代码来获得。（你可以直接在这里找到：http://svn.python.org/view/python/trunk/Misc/gdbinit?view=log）。
当然，如果崩溃严重到破坏了解释器的内部结构，宏可能会失败或崩溃。另外，最好在调试模式下编译解释器，否则gdb可能无法定位所需的符号和变量。

不确定它是否有帮助，但如果可以捕获异常，可以使用http://github.com/gooli/pydump存储转储并稍后在Python调试器中加载它。

你的应用程序会生成日志吗？如果是，你可以让日志生成一个内存中的日志，你可以在核心转储中找到它。此外，你可以让他们发送日志文件本身 * 而不是核心转储。

你没有提到你使用的Python版本。从Python 3.3开始，你可以使用faulthandler，每当发生核心转储时，它都会打印一个回溯。你可以设置环境变量

$ export PYTHONFAULTHANDLER=1

字符串
或者在代码中手动启用：

import faulthandler
faulthandler.enable()

型
这里已经有一个关于faulthandler潜在缺点的问题python: Is there a downside to using faulthandler?