Analysis the CrashDump for Windows

guess you are looking for "WinDbg"
http://www.windbg.org/[^]
http://msdn.microsoft.com/en-us/library/windows/hardware/hh406283(v=vs.85).aspx[^]

OR 'DebugDiag'
http://blogs.msdn.com/b/debugdiag/[^]

You need to open the dump files with these tools and both these tools will do what you ask for , but to see the exact line of code causing the trouble you need to have the correct symbol paths and source paths configured .
hope this helps!

Generated a mini dumpfile using helpdbg API "MiniDumpWriteDump".

sourceFile;

//added for CrashDump Analysis
typedef BOOL (__stdcall *tMDWD)( 
    IN HANDLE hProcess, 
    IN DWORD ProcessId, 
    IN HANDLE hFile, 
    IN MINIDUMP_TYPE DumpType, 
    IN CONST PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam, OPTIONAL 
    IN CONST PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam, OPTIONAL 
    IN CONST PMINIDUMP_CALLBACK_INFORMATION CallbackParam OPTIONAL 
    ); 

static tMDWD s_pMDWD; 
static HMODULE s_hDbgHelpMod; 
static MINIDUMP_TYPE s_dumpTyp = MiniDumpNormal; 

static LONG __stdcall MyCrashHandlerExceptionFilter(EXCEPTION_POINTERS* pEx) 
{   
//#ifdef _M_IX86 
    if (pEx->ExceptionRecord->ExceptionCode == EXCEPTION_STACK_OVERFLOW || ( pEx->ExceptionRecord->ExceptionCode == EXCEPTION_ARRAY_BOUNDS_EXCEEDED) 
        || ( pEx->ExceptionRecord->ExceptionCode == EXCEPTION_ACCESS_VIOLATION) || (pEx->ExceptionRecord->ExceptionCode == EXCEPTION_DATATYPE_MISALIGNMENT)
        || ( pEx->ExceptionRecord->ExceptionCode == EXCEPTION_FLT_STACK_CHECK) || (pEx->ExceptionRecord->ExceptionCode == EXCEPTION_ILLEGAL_INSTRUCTION)
        || ( pEx->ExceptionRecord->ExceptionCode == EXCEPTION_INT_OVERFLOW) || (pEx->ExceptionRecord->ExceptionCode == EXCEPTION_INVALID_HANDLE) 
        || ( pEx->ExceptionRecord->ExceptionCode == STATUS_UNWIND_CONSOLIDATE ))   
    { 
        // be sure that we have enought space... 
        static char MyStack[1024*128];   
        // it assumes that DS and SS are the same!!! (this is the case for Win32) 
        // change the stack only if the selectors are the same (this is the case for Win32) 
        //__asm push offset MyStack[1024*128]; 
        //__asm pop esp; 
        __asm mov eax,offset MyStack[1024*128]; 
        __asm mov esp,eax; 
    } 
//#endif 
    bool bFailed = true; 
    HANDLE hFile; 
    time_t tNow = time( NULL );
    struct tm *pTm = localtime( &tNow );
    CString strDumpFileName;
    strDumpFileName.Format(_T("IML_CRASHDUMP_%d%d%d_%02d%02d%02d.dmp"),pTm->tm_mday,
           pTm->tm_mon,
           pTm->tm_year,
           pTm->tm_hour, 
           pTm->tm_min, 
           pTm->tm_sec );

    hFile = CreateFile(strDumpFileName, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); 
    if (hFile != INVALID_HANDLE_VALUE) 
    { 
        MINIDUMP_EXCEPTION_INFORMATION stMDEI; 
        stMDEI.ThreadId = GetCurrentThreadId(); 
        stMDEI.ExceptionPointers = pEx; 
        stMDEI.ClientPointers = TRUE; 

        // try to create an miniDump: 
        if (s_pMDWD( 
            GetCurrentProcess(), 
            GetCurrentProcessId(), 
            hFile, 
            s_dumpTyp, 
            &stMDEI, 
            NULL, 
            NULL 
            )) 
        { 
            bFailed = false;  // suceeded 
        } 
        CloseHandle(hFile); 
    } 

    if (bFailed) 
    { 
        return EXCEPTION_CONTINUE_SEARCH; 
    } 

    // Optional display an error message 
    FatalAppExit(-1, _T("Application failed!")); 


    // or return one of the following: 
    // - EXCEPTION_CONTINUE_SEARCH 
    // - EXCEPTION_CONTINUE_EXECUTION 
    // - EXCEPTION_EXECUTE_HANDLER 
    return EXCEPTION_CONTINUE_SEARCH;  // this will trigger the "normal" OS error-dialog 
} 
void InitMiniDumpWriter() 
{ 
    if (s_hDbgHelpMod != NULL) 
        return; 

    // Initialize the member, so we do not load the dll after the exception has occured 
    // which might be not possible anymore... 
    s_hDbgHelpMod = LoadLibrary(_T("dbghelp.dll")); 
    if (s_hDbgHelpMod != NULL) 
        s_pMDWD = (tMDWD) GetProcAddress(s_hDbgHelpMod, "MiniDumpWriteDump"); 

    // Register Unhandled Exception-Filter: 
    SetUnhandledExceptionFilter(MyCrashHandlerExceptionFilter); 

    //_set_invalid_parameter_handler(MyCrashHandlerExceptionFilter);
    // Additional call "PreventSetUnhandledExceptionFilter"... 
    // See also: "SetUnhandledExceptionFilter" and VC8 (and later) 
    // http://blog.kalmbachnet.de/?postid=75 
}

Once Dump File has been generated . Open the DumpFile using VS2010.

Click the "Native Debug only" link and start debugging and it will show the line number.

There is no automatic tool, as far as I know.

Windbg has the command "!analyze -v" which automates some things.
You can probably make a script that runs it and generates a report for you.
But it is far from accurate. Sometimes, one has to do some manual digging.

Windbg is installed from the Windows Development Kit http://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx
But once installed it is enough to copy the folder where windbg is to another computer.

You can analyse both debug build and release builds,
With native code it is very important to have the pdb files.
These can be generated for release builds as well.

The pdb files must come from same build of the program you are analysing.
If you don't have the symbol files, you cannot get the line numbers.
That is the reason you cannot just run the analyser.
One has to setup the symbol paths correctly too.

The second thing that you need is the pdb files for the windows libraries.
You don't have them, but they are publicly available
http://support.microsoft.com/kb/311503
Configure the symbol path in the debugger and they will be downloaded at demand.

The debugger I use is Windbg.
Visual Studio can not handle well this type of debugging.

Here are some free video tutorials from Dmitry Vostokov. He is debugging demigod.
http://www.debugging.tv