我有一个客户正在获得100%可重现的崩溃,我无法在我在Visual Studio 2005中编译的程序中复制.我向他们发送了我的程序的调试版本,并保留了所有PDB和DLL文件.他们发给我minidump文件,但当我打开它时,我得到:
"MiniDump.dmp中0x00000000处的未处理异常:0xC0000005:访问冲突读取位置0x00000000."
然后调用堆栈只显示"0x00000000()",反汇编显示内存转储为0x0.我已经设置了符号服务器,加载了我的PDB符号等.但是我看不出有什么方法可以知道哪些DLL实际上导致跳转为null.这是一个包含许多依赖项的大型项目,其中一些是我没有源代码或PDB的二进制文件,因为我使用API作为第三方.
那么这个minidump究竟有用吗？如何查看导致崩溃的DLL？我以前从来没有真正使用minidump进行调试,但我读过的所有教程似乎至少都显示了一个函数名或其他能给你一个调用堆栈线索的东西.我只得到一行指向null.
我也尝试使用"Depends"来查看是否存在一些未解析的DLL依赖项; 但是在我使用各种Windows操作系统的三台测试机器上,我似乎得到了三套不同的OS DLL依赖项(但却无法复制崩溃); 因此,对于诊断问题,这似乎不是一种特别可靠的方法.
有哪些其他方法可用于确定此问题的原因？有没有办法退回一条指令,看看哪个DLL跳转到null？
我有一个用符号构建的本机发行版dll.有一个修改dll的post构建步骤.post构建步骤会进行一些压缩,并可能附加一些数据.pdb文件仍然有效,但是在构建后步骤之后,WinDbg和Visual Studio 2008都不会加载dll的符号.我们需要修改pdb文件或dll中的哪些位以使WinDbg或Visual Studio在加载引用我们的版本dll的转储时加载符号？
文件大小是否重要？校验和或哈希？时间戳？
修改转储？还是修改pdb？在发货前修改dll？
(我们知道pdb是有效的,因为我们可以使用它来手动获取引用已发布的dll的转储调用堆栈中的地址的符号名称.这只是*ss中的一个完全痛苦,对于调用堆栈中的每个地址都可以手动执行所有线程.)
我感兴趣的是开发人员在可以嵌入minidump的用户流数据结构中添加了什么有用的东西.MSDN描述了MiniDumpWriteDump的参数:
PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam
并由此描述参数:
UserStreamParam [in]指向MINIDUMP_USER_STREAM_INFORMATION结构数组的指针.如果此参数的值为NULL,则minidump文件中不包含用户定义的信息.
我正在考虑在用户流中嵌入我的程序的最后n个日志行,因为测试人员往往不会一直发送包含所有错误的格式正确的日志.
此外,我可以在该部分中放置硬件规格(内存,CPU,视频等).
人们还使用了哪些用户流段？
我想使用MiniDumpWriteDump()API从另一个进程A.我这样做是因为转储崩溃的进程B MSDN这样说:
如果可能的话,应该从单独的进程调用MiniDumpWriteDump,而不是从被转储的目标进程中调用.
MiniDumpWriteDump()定义如下:
BOOL WINAPI MiniDumpWriteDump(
__in HANDLE hProcess,
__in DWORD ProcessId,
__in HANDLE hFile,
__in MINIDUMP_TYPE DumpType,
__in PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
__in PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
__in PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);
特别是,ExceptionParam的类型为PMINIDUMP_EXCEPTION_INFORMATION,其定义如下:
typedef struct _MINIDUMP_EXCEPTION_INFORMATION {
DWORD ThreadId;
PEXCEPTION_POINTERS ExceptionPointers;
BOOL ClientPointers;
} MINIDUMP_EXCEPTION_INFORMATION, *PMINIDUMP_EXCEPTION_INFORMATION;
现在我想知道如何准备以下2个参数:
ThreadId 抛出异常的线程的标识符.
ExceptionPointers 一个指向EXCEPTION_POINTERS结构指明该异常的计算机独立描述,并在异常时的处理器的上下文.
在进程A中运行时,如何在进程B中获取错误的线程id和异常指针？
谢谢.
我有一个使用WPF的混合模式C++/CLI应用程序.我们客户的崩溃报告为我们自己的服务器的小型转储.
当我尝试使用windbg sos-extension中的!pe或!clrstack命令调查minidump时,我经常从WPF程序集中获取不完整的堆栈帧信息,例如
SP IP Function
0013E370 564618E3 PresentationFramework_ni!Unknown+0x1bf
0013E3A4 56461258 PresentationFramework_ni!Unknown+0x58
0013E3CC 5634C6D8 PresentationFramework_ni!Unknown+0x18
0013E3D8 55C04AA2 PresentationFramework_ni!Unknown+0x502
...
在这种情况下,堆栈跟踪解码也变得非常慢.
使用!sym noisy显示了以下的大量消息
SYMSRV: C:\Symbols\PresentationFramework.ni.dll\488F142Edab000\PresentationFramework.ni.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/PresentationFramework.ni.dll/488F142Edab000/PresentationFramework.ni.dll not found
DBGHELP: C:\Program Files (x86)\Debugging Tools for Windows (x86)\PresentationFramework.ni.dll - file not found
DBGHELP: PresentationFramework.ni.dll not found in c:\Windows\System32
SYMSRV: C:\Symbols\PresentationFramework.ni.dll\488F142Edab000\PresentationFramework.ni.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/PresentationFramework.ni.dll/488F142Edab000/PresentationFramework.ni.dll not found
DBGENG: C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\PresentationFramewo#\9519494798a88867406b5755e1dbded6\PresentationFramework.ni.dll - Couldn't map image from disk.
SYMSRV: C:\Symbols\PresentationFramework.dll\488F142E50e000\PresentationFramework.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/PresentationFramework.dll/488F142E50e000/PresentationFramework.dll not found
DBGHELP: C:\Program Files (x86)\Debugging Tools for Windows (x86)\PresentationFramework.dll …我已经被MS Connect主持人要求为我在Visual Studio中遇到的问题提供一个小型转储文件.
我的业务稍微关心转储文件中可能包含的内容(大小约为半个gig).
通过"温和关注",我只是意味着他们已经让我知道是否会包含任何专有代码(如果是,那么多少).
转储文件由Visual Studio通过执行以下操作创建:
我认为StackOverflow的可爱人们可以提供帮助.所以我的问题是:
为了追踪一些难以重现的崩溃,我已经配置了UnhandledExceptionFilter如下所述创建迷你转储文件:调试自定义过滤器以处理未处理的异常和有效的小型转储
转储正在成功捕获,但我没有太多运气解释堆栈信息.希望其他人能够体验到类似的东西,我将在下面提供尽可能多的细节.对不起,如果这个问题结果有点冗长.
Visual Studio提供以下转储摘要:
Dump Summary
------------
Dump File: MiniDump.dmp
Last Write Time: 15/08/2012 22:07:22
Process Name: Server.exe : C:\Project\Server.exe
Process Architecture: x86
Exception Code: 0xC0000005
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Heap Information: Not Present
System Information
------------------
OS Version: 6.1.7601
CLR Version(s):
Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
Server.exe C:\Project\Server.exe …我有一个用(Visual)C++编写的Windows服务,它具有非常详细的日志记录功能,经常帮助我找到客户有时遇到的错误原因.基本上我检查每个返回值并记录发生了什么以及错误来自哪里.
理想情况下,我希望对异常具有相同级别的详细可见性(例如,数组超出范围,除以零等).换句话说:我想知道异常的来源.出于可读性和实用性的原因,我不想将每几行代码包装到单独的try/catch块中.
我今天拥有的是一个通用的捕获所有捕获所有内容并在关闭程序之前记录错误.从用户的角度来看这很好 - 干净关闭而不是应用程序崩溃 - 但对我来说不好,因为我只从异常中获取一般信息(例如"数组超出范围"),但不知道它来自何处.
是不是更好的删除catch-all并让程序崩溃？我可以直接客户有Windows创建一个应用程序崩溃转储(如描述在这里).使用转储文件,WinDbg会指向我到代码中抛出异常的位置.
我有这个Java类,我试图使用Eclipse Mars.1 IDE运行.
这是代码:
import com.xuggle.mediatool.IMediaReader;
import com.xuggle.mediatool.IMediaWriter;
import com.xuggle.mediatool.ToolFactory;
import com.xuggle.xuggler.ICodec;
public class VideoToAudio {
public void convertVideoToAudio(){
IMediaReader reader = ToolFactory.makeReader("C:/Users/hbxd78/Desktop/test.mp4");
IMediaWriter writer = ToolFactory.makeWriter("C:/Users/hbxd78/Desktop/agf.mp3", reader);
int sampleRate = 44100;
int channels = 1;
writer.setMaskLateStreamExceptions(true);
writer.addAudioStream(1, 0, ICodec.ID.CODEC_ID_MP3, channels, sampleRate);
reader.addListener(writer);
while (reader.readPacket() == null) ;
}
public static void main(String [] args){
VideoToAudio vta = new VideoToAudio();
try{
vta.convertVideoToAudio();
}
catch(Exception e){
System.out.println("Could not open video file");
e.printStackTrace();
}
}
}
尝试运行以下代码时,我在Eclipse控制台中显示以下错误:
#
# A fatal …