For an application written on C++ and compiled/built on mingw, I am facing issues in core file analysis. I have my application built/run on XP machine.
How do we save core file generated in the test bed of Windows XP? The application is delivered to user/test engineer and if the "users" gets the crash - how to save the crash file and send it across?
Can you suggest the best available debugger for this kind of set-up? I did go through Windbg32, coredumper.exe etc - but these depends on specific VC generated symbol file. And mingw used application cannot be used in lieu with Wingdb32.
Is there any specific compilation flag I need to use on mingw during application building - so that I can read all symbols from the core file - during the analysis.
Thanks in advance for advice. Any link on these material also would help a lot.
Related
I have a C++ gradle app set up in Visual Studio 2019 Community Edition targeting Android. I'm using NDK 20 (the latest version in Microsoft's android sdk repo).
This app is composed of several .so libraries (SDL2, SDL2_image, SDL2_ttf, WolfSSL, MyGameCode, MyGameLibrary, MiscellaneousExternalDependencies.a) and all seems to compile and run properly. The issue I have is in attaching a breakpoint and seeing GDB trying to load the symbols for the associated .so (in this case, my game code specifically).
I have done some testing and found that if I strip out all my game code I can get breakpoints to hit with just my library and all other dependencies. I've also tested and found that including most of my game files still runs. However I have about 10 files that if I remove them everything seems to load just fine. It takes about 42 seconds to load symbols when I have a stripped down version of my project which allows for breakpoints to be hit.
It seems to be total symbols in the project rather than any specific code running during the application's lifetime since I have a main finction in C++ specified which does not load any of my game code and just runs a simple SDL2 test and simply by changing the number of files included in the project I can reproduce the GDB crash or eliminate it.
I should note that my project seems to run just fine without the debugger attached, and I can see output from the C++ modules I'm trying to set breakpoints in. The issue I have is limited to when I try to connect GDB and access a breakpoint through Visual Studio. At that point I am getting what appears to be a stack overflow (or possibly a timeout?) during the symbol loading process.
My question here has a few bullet points:
does GDB have some kind of symbol limit?
If so, is there a way to strip unused symbols from the final ".so" during the build process from within Visual Studio? I want to keep my build process simple to execute.
If not, can I break my project up in some kind of way with .so or .a files to get around this? It doesn't seem that it makes a difference currently if I do that so more advice would be appreciated!
Does Visual Studio's wrapper of GDB and the Android Emulator allow me to increase the timeout if there is a timeout? If I could specify it at like 200 seconds that would definitely be more than enough time to load my project's .so symbols.
Are there any other possible explanations for crashing on loading symbols in this way that have plausible work-arounds?
Essentially I don't know why it's crashing during loading symbols for my .so file
I have provided additional details here including a link to my project and exact testing methodology, but the full thrust of this question is present in this post.
https://developercommunity.visualstudio.com/content/problem/898890/gdb-exited-unexpectedly-with-exit-code-1073741571.html
It turns out replacing the gdb.exe and gdb-orig.exe files from my Microsoft Hosted NDK version 20.0.5594570 with the ones I got from downloading NDK 21 available here solved the problem (r21 at the time of writing): https://developer.android.com/ndk/downloads
There must be a defect which has been recently resolved in GDB itself and which had issues with my project size and/or composition. The NDK r21 bundled version of GDB works perfectly, however.
I am using a already developed C++ dll in my asp.net code to make compression/decompression of the data. It works well on my developer machine and some other machines too. I have a client machine which is fresh(No fancy installation of various tools) and When it tries to call that dll it generates an exception.
Exception:Could not load file or assembly 'dllcode, Version=1.0.5754.25819, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I would like to know that which dependencies are missing on Client fresh machine?
Note: I am trying to call C++ dll in a windows service which is having asp.net 4.0 framework. This call is executing perfectly on my developer machine but generates above exception on my client machine.I do not have deep knowledge about c++ library and it's dll. From basic troubleshooting I tried to install various combinations of "microsoft visual c++ 2010 runtime" but it did not help.
Update: Somehow I find source code of this C++ dll and now I am trying to check if I can build this dll any version specific.
I got this resolved. What I did is, I had to create separate setups(32-Bit & 64-Bit). Also VC++ run time was needed on server. So I installed them and it worked.
Hope this help to any one if he faces the same issue.
I have a cross platform desktop C++ app for Mac OSX and Windows, for which I'd like to collect debug info when a crash happens on a user's computer, so I can find out what the problem is and fix my code. On Windows I'm using visual studio express 2010 and on Mac I'm using Xcode 3 as IDE. I remember an online service where you could sign up and link your code with a library, so the app would upload crash info to the service, which you could then use to fix the app, but I can't find it anymore after googling for 10 minutes. Can anyone help?
Thanks!
B
Please see here for the google-breakpad project. I think this is what you need. I was going to use it for a project so I researched about it but then the project ended so I didn't have a chance to. You link your program with it and when the program crashes, it generates a crash dump that is not compatible with any of the platform-specific crash dump formats but has its own one. You can then analyse them with a program that is part of the breakpad project. As far as I remember, there is also a service that you can install, where the crash dumps can be uploaded. The service then can analyse and group them by reason etc.
Hope that helps.
I'm having a MFC application (VS 2008) which is going to be deployed on Windows 7 machine. I need to distribute my application with debugging information, so that a debugable core will be generated in case of application crash event.
Can somebody please let me know how can I achieve this purpose ? I have read about minidump utility, just would like to whether there is a better way of generating coredump on windows 7 machine
Thank you
By default, both Debug and Release MSVC builds contain debug information. You don't need to distribute the program with .pdb files, but it is necessary to keep .pdb files for every released version. They are necessary to debug minidump files. Program itself must generate dump files when it crashes. Generally, working with minidumps looks like this:
Program crashes on a client site and produces minidump file.
minidump is sent to developer.
Developer restores the source code and .pdb files according to the program version, and debugs minidump file.
Finally, short introdunction to post-mortem debugging: http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
AFAIK, this is the same for all Windows versions.
I installed XP on a virtual machine, updated it to SP3 and then tested a small program compiled with Visual C++ 2008 on my real computer - however it didn't start but outputted only an error saying that a problem had been detected and that a reinstall of the application (mine is 10KB in size and doesn't even have an installation) could fix the problem.
What is required to run programs compiled with MSVC 9?
Can I just include some dlls for it to work everywhere?
Either link statially against the runtime library (select multithreaded instead of multithreaded-dll) or follow tommieb75's advice and install the MSVC9 runtime redistributable (copying to system32 or to the application's folder works as well, but is not the way to go, afaik). For small applications with no need for an installer, I'd prefer the first option. Deploying runtime installers is annoying.
You could be missing the MCVC9 runtime library, try copying that over to the Windows System32 folder...
It may depend against which DLLs your project is linked. Inspect the assemblies manifest and check if those DLLs are installed on your VM.
What does your program contains? Dependencies on dynamic C/C++ runtime? Then you need to either include the C++ redistributable runtime DLLs in your app, or change the program to use the static C++ runtime. Similarly, do you use ATL? MFC? Custom 3rd party libraries? They all add dependencies to your executable and Win32 will refuse to load your application.
One easy step is to check with Dependency Walker what dependencies your application has.
It could be a dll you application links against. The depends tool is a must have in every programmers toolbox for debugging dll dependency issues.
If you have the commercial rather than express msvc edition, what you really should do is copy the msvcmon redist components to your VM, run the remote debug monitor there, and attach to it from your desktop dev environment. This page explains the basic principal. Because it sounds like your app is causing an exception on XP.
If you can't remote debug and if dependency checker does not indicate a dll issue, then you could look in the systems application event log to see if there is any more information there. Or try install Dr Watson as a post mortem debugger. Open a command prompt and enter
drwtsn32 -i
to install Dr Watson as the post mortem debugger, and
drwtsn32
to get a config screen allowing you to browse for the location of crash dumps. You can load crash dump files directly with Dev Studio 2005 and later. (I don't think Dr Watson ships with Vista and Windows 7 anymore).