标签: crash-dumps

从Windows Vista开始,现在可以从任务管理器生成进程转储.通常我通过使用Adplus或从Windbg直接生成进程转储.如果我使用其中一个选项,我必须使用我的命令提供一些开关,以描述生成了什么类型的转储.鉴于当我从任务管理器生成进程转储时隐藏了所有这些细节,是否有人知道它是什么类型的转储以及它包含的内容？我记得在任何地方读取从任务管理器生成的进程转储不包含句柄表的详细信息.有关于此的任何想法吗？

在Windows环境(XP和Win 7)中:

• 当进程在系统上崩溃时自动生成崩溃转储的最佳方法是什么？
• 安装程序(MSI)包可以执行此操作吗？

我在生产服务器上有一个奇怪的情况.asp.net的连接排队,但CPU只有40%.此外,数据库在30%CPU下运行良好.

评论中要求的更多历史记录:

• 在高峰时段,这些网站每小时可以获得大约20,000名访客.
• 该站点是一个带有大量AJAX/POST的asp.net webforms应用程序
• 该网站使用了大量用户生成的内容
• 我们使用测试页来衡量站点的性能,该测试页确实击中了数据库和站点使用的Web服务.此页面在正常负载下一秒钟内即可获得服务.当请求超过4秒时,将应用程序定义为慢速.
• 从测量结果我们可以看出连接时间很快,但处理时间很长.
• 我们无法确定单个请求的响应速度慢,网站在正常时间运行正常但在高峰时段运行缓慢
• 我们遇到了一个问题,即网站受CPU限制(也就是100%运行),我们修复了这个问题
• 我们也遇到了appdomain重启的例外问题,我们修复了这个问题
• 在高峰时段,我看看asp.net性能计数器.我们可以看到我们有600个当前连接和500个排队连接的行为.
• 在高峰时段,CPU约为40%(这让我认为它不受CPU限制)
• 物理内存约占60%
• 在高峰时间,DatabaseServer CPU大约是30%(这让我认为它不是数据库绑定的)

我的结论是,其他东西阻止服务器更快地处理请求.可能的嫌疑人

• 死锁(!syncblk只提供一个锁)
• 磁盘I/O(通过sysinternals procesexplorer检查:3.5 mB/s)
• 垃圾收集(峰值期间10~15%)
• 网络I/O(连接时间仍然很低)

为了找出进程正在做什么,我创建了minidumps.

我设法创造了两个相隔20秒的MemoryDumps.这是第一个的输出:

!threadpool
CPU utilization 6%
Worker Thread: Total: 95 Running: 72 Idle: 23 MaxLimit: 200 MinLimit: 100
Work Request in Queue: 1
--------------------------------------
Number of Timers: 64

和第二个的输出:

!threadpool
CPU utilization 9%
Worker Thread: Total: 111 Running: 111 Idle: 0 MaxLimit: 200 MinLimit: 100
Work Request in Queue: 1589

正如您所看到的,队列中有很多请求.

问题1:队列中有1589个请求是什么意思.这是否意味着阻止了什么？

!threadpool列表主要包含以下条目:未知函数:6a2aa293上下文:01cd1558 AsyncTimerCallbackCompletion TimerInfo @ …

如何在Java中重现EXCEPTION_STACK_OVERFLOW错误.

PS:我不是在谈论优雅地关闭JVM的Java中的StackOverflowError错误.我在讨论error.log中的EXCEPTION_STACK_OVERFLOW,这会导致JVM崩溃.

假设我的二进制文件在我无法core dump使用ulimit -c. 工程师如何segmentation faults在如此真实的场景中调试？是否有任何其他方法可以在不core dumps生成的情况下调试或识别崩溃。

我有一个从.NET应用程序崩溃的minidump.有没有办法知道使用Windbg或其他工具的故障机器(生成故障转储)的CLR版本(例如mscorwks.dll的版本)？

当我的应用程序崩溃并关闭时,请告诉我需要遵循的步骤,显示包含"不发送"和"发送错误报告"按钮的对话框.

除了查看事件查看器以解决此问题,我还能做些什么？

谢谢

我正在使用32位应用程序,有时会导致某个64位Windows 7计算机崩溃.我使用Sysinternals的ProcDump实用程序生成了崩溃的转储文件.(我使用命令"procdump -ma -h MyApplication.exe".)现在,当我用WinDbg打开转储文件时,我收到此错误:

"打开转储文件'MyDumpFile.dmp'时失败,HRESULT 0x80004005.它可能已损坏或调试器无法理解的格式."

在32位Windows XP计算机上运行WinDbg X86以及在64位Windows 7计算机上运行WinDbg AMD64时都会发生这种情况.你能解释一下吗？

编辑 - 附加信息:在文件上运行dumpchk时,它说:

"Minidump没有系统信息.无法打开转储文件[MyDumpFile.dmp],HRESULT 0x80004005'未指定错误'".

也许转储文件只是腐败？

我正在使用以下代码从我的iOS应用程序中获取崩溃报告:

void *frames[128];
int i,len = backtrace(frames, 128);
char **symbols = backtrace_symbols(frames,len);

NSMutableString *buffer = [[NSMutableString alloc] initWithCapacity:4096];

NSBundle *bundle = [NSBundle mainBundle];
[buffer appendFormat:@"PComp version %@ build %@\n\n",
    [bundle objectForInfoDictionaryKey:@"CFBundleVersion"],
    [bundle objectForInfoDictionaryKey:@"CIMBuildNumber"]];
[buffer appendString:@"Uncaught C++ Exception\n"];
[buffer appendString:@"Stack trace:\n\n"];
for (i = 0; i < len; ++i) {
    [buffer appendFormat:@"%4d - %s\n",i,symbols[i]];
}

这只会提供有关当前线程的信息吗？我怎么能得到所有线程的堆栈跟踪？

我们有一个部署了启用apport的Ubuntu服务器,如图所示.

~$ cat /proc/sys/kernel/core_pattern 
|/usr/share/apport/apport %p %s %c

不幸的是,apport处理非打包应用程序崩溃的行为并不完全符合我们的喜好.apport在这些场景中的工作目录中生成"核心"文件(假设ulimit -c已正确设置).例如,从apport日志中,

ERROR: apport (pid 10117) Tue Jan  8 08:56:25 2013: executable: /home/jess/a.out (command line "./a.out")
ERROR: apport (pid 10117) Tue Jan  8 08:56:25 2013: executable does not belong to a package, ignoring
ERROR: apport (pid 10117) Tue Jan  8 08:56:25 2013: writing core dump to /home/jess/core (limit: 18889465931478580853760)

令人沮丧的是,一旦核心文件存在,它就不会被覆盖.因此,例如,如果我们正在测试应用程序并忘记从工作目录中清除旧的核心文件,那么应用程序在测试期间崩溃,我们将看不到新的核心文件.即使它被覆盖了,这可能也不理想,因为我们失去了旧核心.

理想情况下,我们希望能够通过参数告诉apport,对于非打包的应用程序,生成一个核心文件,其文件名根据指定的模式进行格式化(根据core_pattern文件规范). ..有没有办法做到这一点,或等同的东西？