I generate a map file with all my projects (exe and dlls). When my app crashes I know what map file to check and how to read the map file to find the problem in my code. I don't know how to use them with a pdb to find the exact line, but I can find the function from the mapfile which is usually good enough. My project is dynamically linked to the runtime (not an option to change it due to dependence on some 3rd party libs). So my question is how do I trace back to the faulting function in my exe? I currently have a crash coming from mscvr80.dll and the offset is ( 0x00008aa0 ) which I think is dereferencing an invalid iterator. This time I lucked out since it was easily reproducible for me.

In this case, you'd want to look at the stack at the point of the crash. In the debugger, it should show up automatically when debugging. If it doesn't, Ctrl-7 will bring up the call stack on recent versions of MSVC.

Unfortunately that isn't an option. It is a release build and the person using is 10000km away.

Guess it might not be possible, was looking for a way to trace back with the offset somehow I think DrWatson logs more information where the dll is loaded, but not sure if there is enough there to figure it out, I will need to dig deeper. Thanks anyways!

Depending on the operating system and installed software that exists on the client computer, the system may automatically generate a crash dump or minidump when the program dies. They typically end with a .dmp and can be opened in Visual Studio by using Open Project and selecting the .dmp file. If the system doesn't generate a dump automatically, you can have your program generate a dump using MiniDumpWriteDump(). This generally involves writing a SEH filter to catch otherwise unhandled SEH exceptions and invoking MiniDumpWriteDump() the filter expression which will create a dump containing the stack at the time of the unhandled exception. Alternately, you can use StackWalk64() to perform a stack walk in the exception filter instead of generating the crash dump. This would contain less information than a full dump, but often has the advantage of being more human readable without needing to load up the debugger. An example of the latter is in the source code at the end of my article here.