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.
Related
There is a bug that I would like to fix that only occurs on Windows Server without a GUI running. I have set up a Windows Server 2019 machine on Google Compute Engine that reproduces the bug, and would like to debug it.
Ideally, I would like to use gdb, but seeing as the program was built with Visual Studio 2019, gdb can't read the debugging symbols.
I don't have a Windows machine, so using Visual Studio will be difficult. I could set up a VM, but if there's an in-terminal way to do this that would be preferred.
I did a pretty thorough Google search, but it didn't turn up anything. Is there really no Windows solution for debugging C++ code headlessly?
MS has 2 console debuggers called CDB and NTSD so you don't actually need Visual Studio GUI to do the debugging. In fact there are a lot of debugging environments in Windows from MS beside the usual Visual Studio. Just install them in your Windows Server and control them remotely from your terminal
You can also debug MSVC-compiled code with LLDB since the PDB format has been published long time ago and LLVM on Windows does support it. No idea about current LLDB on Linux though
And since you have the source code, sometimes the old-school printf debugger is the best way to analyze the issue
If you can get a Windows VM it'll be much better to do remote debugging. In fact almost all debuggers support that feature including GDB or LLDB, so even if you don't have the source code you can still run any Windows debugger and step through the instructions instead of high-level code lines from a remote machine
An alternative way is to take a memory dump and debug later. After getting the dump file, just drag it into your VS solution or any debugging tool like WinDbg and then select "Start Debugging". Now you can step through instructions/code lines and examine variables' values, or jump to an arbitrary function's stack frame just as if you're really running the malfunctioning app
There are many ways to dump a process' memory. You can set Windows to automatically save a dump file when your app crashes, or just capture memory snapshots manually during runtime. Comparing 2 snapshots is also useful for detecting leaked memory. For more information on how to do that read
Collecting User-Mode Dumps
Steps to Catch a Simple “Crash Dump” of a Crashing Process
There's also an easy way to take a dump of a live process using task manager (or any other similar tools)
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.
I have a Visual Basic 6 application that I've recently changed to use a couple of C++ DLLs I've written in Visual Studio 2008. The application works fine on my PC, but when we install it on one of our test PCs it tends to crash during shutdown - we see the Win 7 message "Your application has failed" or whatever it is.
I know Win 7 stores data that can be used to analyse the crash. I've got the source code and .PDB files from the build so I should be able to use that, but I can't figure out where Win 7 stores the data from the crash. The Event Viewer shows the crash but doesn't have any data and the directory C:\Windows\Minidump doesn't exist.
Where do the crash files get put?
Microsoft has documentation here which works back to Vista Service Pack 1:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx
There is a registry key with 4 sub-values that control generic crashes:
# HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
DumpType # 1 = mini-dump, 2 = full dump, 0 = custom dump
DumpCount # Maximum number of dump files to keep before purging
DumpFolder # Full path to folder to store dump files (no trailing slash)
DumpFlags # Usually 0, flags only used if DumpType is 0
Once these registry values are in place crash files should be immediately written no matter what happens to whatever dialog might be displayed.
Note: Registry sub-keys with executable name can be used to control crash behavior for only one specified process.
Get minidump for crash
Get WDK , Using Debugging Tools for Windows
Use Windbg to open crash dump
use command !analyze
The !analyze extension displays information about the current exception or bug check.
Read more about window debugging
Creating Dump:
You can configure windbg as defaut debugging tool by giving command "windbg -I" in run.
Also Dr. Watson tool can do this for you.
You can even use a carsh reporting mechanism and get the locally saved dump file, then debug it using Visual Studio. There are pretty much freely available resources in Visual C++, but not much in VB.
Why don't you make your program save minidump wherever you want when the crash happens? I'm not familiar with VB, but try to use SetUnhandledExceptionFilter() and MiniDumpWriteDump().
i have strange problem , my application (exe) is working fine in debug mode in windows 7
but stop to work with exception when compiling in release mode .
how can i debug the program to find what is causing the exception this is application with more then 300,000 lines of code ..
Compile in Release mode but create the .pdb files: How to generate PDB’s for .net managed projects in release mode?
Deploy the .pdb files to same folder as the .exe.
Then attach to process.
Check the projects settings which are different for debug and release modes, maybe you will find an answer there.
Compile release mode with debug information and turn off optimization. You will have debug version compiled with release defines. If it fails the debugger will show you bad place.
Just turn off optimization. Once upon a time that was an issue for me. In this case it will be really hard to find out the cause.
Create PDBs, it can be done for native C++ too.
I'm trying to generate a release build for a C++ application that I've written. The application runs fine (debug & release) when you run it from within VS2008; but when you run the executable it crashes nearly every single time.
Now, is there a hack so I can run this application as a standalone application without having to run through all of the code and finding the bug that is causing it?
Thanks in advance.
In short, no.
you will have to find the bug, if it works within VS, then I'd hazard a guess that it is a timing issue, possibly you're overwriting shared thread data, this would be less likely (though still possible to see) inside VS as its being run in a debug environment which slows it down a bit.
If you want help finding your bug, then tell us more. Otherwise, build your release with debug symbols (pdbs), install DrWatson as the system debugger and run it standalone. When it crashes DrWatson will create a minidump file, load this into WinDbg (my favourite) and you'll be able to see exactly where your bug is (it'll even tell you that the dump contains an exception and show you it by default. You need to add your source code path and path to your symbols in WinDbg to get it to do this correctly).
Then you will also know how to diagnose crashes when the app is run on-site too.
Are you loading external resources? If you are check that your relative paths are correct in the C++ program.
One possibility is that your program uses uninitialized heap data. Launching a program from the debugger enables the NT debug heap, which causes the heap allocator to fill new memory blocks with a fill pattern, and also enables some heap checking. Launching the same program from outside the debugger leaves the NT debug heap disabled, but if the program was linked against the debug version of the C runtime, then the CRT debug heap will still be enabled.
A much less likely possibility is that your program requires SeDebugPrivilege to be set in its process token. The debugger enables this privilege in its process token, which has the side effect that all programs launched from the debugger inherit this privilege. If your program tries to use OpenProcess()/ReadProcessMemory()/WriteProcessMemory() and doesn't handle errors correctly, it's conceivable that it could crash.
There are a few possibilities. Besides what has already been mentioned, running an app from Visual Studio will execute in the same security context as the Visual Studio instance. So if, for instance, you are working on Vista, you might be hitting an unhandled security violation if you're trying to access protected files, or the registry.
What if you build a debug version and run it standalone? Does it crash? If so, you can usually break into the debugger from there and get a call stack to see what the malfunction is.
From the details you've given, it sounds like there may be a library issue. Are you running the program on the same computer? If not then you'll also have to deploy the appropriate libraries for your application. If you are running on the same computer but outside of the dev environment, ensure that your application can see the appropriate libraries.
Best way i have found to debug in release is to create a crash dump when an crash happens and the dump then allows me to load debug symbols on my dev computer and find out whats going on. More info here: http://www.debuginfo.com/articles/effminidumps.html
You can also go to file => open in Visual Studio and open the .exe, so you are not starting it under the debugger per se. Not sure if it will help.
http://blogs.msdn.com/saraford/archive/2008/08/21/did-you-know-you-can-debug-an-executable-that-isn-t-a-part-of-a-visual-studio-project-without-using-tools-attach-to-process-296.aspx