When a program crashes, it usually means that the programmer did something bad. But crashes happen, no matter how good the programmer is. C++ programmers are facing more difficult situations than for example C# or Java programmers when trying to identify and fix the cause of a crash on end users systems. Modern, high level languages are able to report the exact location of crashes and exceptions. After the crash, they usually show the whole stack trace of the problem by default on the screen, which the end user is able to send to the programmer then. C++ programmers are not that lucky, but Windows has a built-in functionality which is able to report the whole crash information and makes it possible to debug a crash after it happened on another PC. And interestingly, not all C++ programmers know about this
Minidump-Feature. Basically, all you need to do is
__try{ // execute your code and maybe crash here}__except(WriteYourCrashFile(GetExceptionInformation())){}
where you only need to implement the WriteYourCrashFile they way you like your program to handle crashes, like sending the info out per email or simply write a .dmp to disk.
This MSDN article gives a nice example on how to do this. Alternatively, if you don't like __try and __execpt, you can also use
SetUnhandledExceptionFilter to install a function to handle the exception instead. The file written by
MiniDumpWriteDump() can then be opened in VisualStudio and shows the debugger as if the crash happend on your local PC (assuming you still have have the correct .exe and .pdb file on your disk).
If this is all to much effort for you, the function
GetExceptionInformation() already gives enough information to indentify bugs, so you might want to use this one instead.
I personally used this technique in a lot of software I wrote and am currently using this in
irrfuscator, where it already helped to identify one mysterious, evil bug which I would never have found otherwise, I think. So I can really recommend it.