I am trying to debug a crash minidump.
have the release debug symbols and release binaries same as crash.
While debugging that crash and pointing to symbols still I am getting "No matching binary found" error .
I am using the right symbols, binaries and pointing to right location.
So why this can happen? I can see a slight difference in timestamp of dll loaded in VS(9:03AM) and the release binary(9:04AM)
Can this be the reason for the error?
Any solutions for this , I need to fix the crash and since this crash occuring on client machine , I cannt repro it.
You may try to debug the dump using the windbg/ntsd (from the 'Debugging tools for Windows' package that comes with Windows SDK ). There you may try to load the symbols while ignoring a mismatch in the .pdb file versions '.reload /i' command.
Related
Like the caption says, how do I get old debug symbols.
In recent days I have analyzed some vb6 functionalities, but I found debug symbol vba6.dbg for vab6.dll shipped in vs6 setup CD seems a broken or incorrect file.
Is there anyone can told me how or where to resolve this problem?
I use ndk-build to compile libpng source code in debug mode, then it shows “internal compiler error” in pngrtran.c. But when I compile in release mode, it can success. Is this a bug in libpng? How I can resolve this?
It's not a bug in libpng; anything a program describes as an "internal error" is a bug in the program (libpng does this, but then it shows "libpng: internal error"!) So it's a bug in the compiler.
You should report it to the ndk guys or you could go directly to the compiler vendor (probably GNU) because they would likely to be more responsive.
You can't resolve the problem - it needs a compiler fix (maybe only to output a message that doesn't claim it's an internal error, but at least that.) You can avoid the problem by simply not compiling libpng in debug mode. Since I assume this is for Android so you can (I believe) mix-and-match debug and now debug code (this does NOT work on Windows with at least one compiler!)
You can also try working out which compiler option reveals the problem; compare the options being passed to the compiler in both release and debug, then bisect the differences to see if you can narrow the issue down to one setting.
John Bowler jbowler 2 acm.org
The android team should know about the bug. As Its a resurface of an old one:
http://code.google.com/p/android/issues/detail?id=20862
Is it possible to symbolicate MonoTouch crash dumps and get line numbers out of them? If so, how is it done?
I have configured my project in the following way:
Build in release mode
Checked 'Enable debugging' in Project Options -> Build -> iPhone Build -> General tab
Checked 'Emit debugging information' in Project Options -> Build -> Compiler
Now, when I run symbolicatecrash against a dump, I get my method names in the stack trace but with only an offset against them (eg '+ 268') rather than a line number.
I am using MonoTouch 4.21.
Short answer: I think the issue is with the ahead-of-time (AOT) compiler - but you better email such question to the mono-devel mailing-list to get a definitive answer.
Long answer:
Mono compilers/runtime (and that behavior is inherited by MonoTouch) keeps the debugging information, that includes line numbers, for its assemblies inside mdb files.
XCode works with DWARF (DSYM) files. When XCode symbolicate a crash dump it looks (only) in the (AOT-produced) DWARF symbols to get its information - i.e. the mdb files are not looked up.
Now the Mono debugger (and runtime) can cope with DWARF too (which should fit the bill). However for MonoTouch I'm not sure the AOT compiler (which calls gcc) is producing the final DWARF symbols containing the C# line numbers - resulting in symbols and offsets (both available to gcc) only being available.
which version of xcode are you using?
There was an problem in earlier versions -
check https://github.com/chrispix/symbolicatecrash-fix
I'm trying to profile a C++ project in Embarcadero RAD Studio 2010. To do this I wanted to use AQTime, but I'm running into a bit of a problem.
I can compile and run the application in release mode. But when I compile in debug mode, using the settings mentioned at http://smartbear.com/support/viewarticle/18053/, I get an access violation.
... faulted with message: 'access
violation at 0x062324bd: read of
address 0x62324bd'. Process stopped.
Use Step or Run to continue.
It seems to come when I load a bunch of dll's at the startup. But since it goes well in release mode I can't seem to figure out what could be the cause.
When the access violation occurs I get thrown out into assembly and that isn't one of the languages I'm fluent in ;)
EDIT : When scanning the .exe with Dependency Walker I get a message saying that the following files can't be found
CC32100MT.DLL
INET140.BPL
RTL140.BPL
VCL140.BPL
IESHIMS.DLL
Could this be the problem somehow? Are these debugspecific or is Dependency Walker not giving me correct information? The same files are said to be missing when I try a release compiled version to.
I'm running on Windows 7 x64, if that could be part of the issue. I have had problems before with the symlink-look-alike (user/AppData/Local...) that MS used for some folders. Notably when I ran an apache server and the htdocs folder actually wasn't located where the server thought it was (and where it appeared to be) :)
Have you tried disabling dynamic rtl which can be found in the C++ builder linker options pane?
I have a simple .exe written in C++ (built with Visual Studio 2005) that tests some hardware using a supplied API. It works fine on the Windows 7 machine I built it on, but when I copy it to another (Windows 7) machine and run it (from the command-line) I get:
The application has failed to start
because its side-by-side configuration
is incorrect. Please see the
application event log or use the
command-line sxstrace.exe tool for
more detail.
What is "side-by-side configuration"?
I ran sxstrace.exe and read the usage info. It appears I would need to instrument my exe to generate a log file for sxstrace.exe to be useful?
I imagine the problem is my exe requires DLLs that either don't exist on the other machine, or are the wrong version. How do I find out what DLLs my exe uses, and what versions it links to on my machine (where it works)? Any other advice on copying it to another machine and getting it running? Would more information help?
mfawzymkh's answer to the "application has failed to start because the side by side configauration is incorrect" question (linked to in the question spirulence linked to in his answer to this question) appears to apply to this question also. mfawzymkh writes:
You can resolve this issue by either
one of these 1- Install VC8 Debug CRT
2- Build you app as statically linked
And mfawzymkh's comment on that same answer explains how to build as statically linked:
when you build it in VS, go to
projects->settings->C/C++->Code
Generation and choose Runtime Lib
options to be /MTd instead of /MDd
I did that and the side-by-side configuration message is gone. (And after installing something else for the DLL I was using, my EXE works.)
For what it's worth, I encountered the same issue. In the Event Viewer I had an error message that read:
Activation context generation failed for "C:\\MyExe.exe".Error in manifest or policy file "C:\\MyExe.exe.Config" on line 12. Invalid Xml syntax.
Sure enough, I'd changed a connection string and left out the closing quote. Added that back in and it solved the issue.
"when you build it in VS, go to projects->settings->C/C++->Code Generation and choose Runtime Lib options to be /MTd instead of /MDd" worked for me, although I was interested in the Release version instead of the Debug version.
Microsofto says:
/MT Causes your application to use the multithread, static version of the run-time library. Defines _MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.
/MD
Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR100.DLL, which must be available at run time to applications linked with MSVCRT.lib.
Are you suffering from the same issue as this guy? Side-by-side assemblies, Windows 7, and Visual Studio 2005