Understand Crash Dump from Visual C ++ App

Question

UPDATE

Thanks to the feedback, I was able to return to the ADPlus.vbs website, which is part of the debugging tools for Windows.

Remember to configure _NT_SYMBOL_PATH before starting.

Using this, we were able to see much more clearly in the application with much greater clarity than we ever used ordinary dumps created through Windows when the application crashed.

Many thanks to all for the answers.

ORIGINAL QUESTION

We have a server application written in Visual C ++ that crashes on client sites several times (relatively rarely). We were not able to understand why this is happening, based on viewing our own log files, so the next step is to start searching for crash dumps.

We just purposefully put an error in our application (null pointer) so that we can create an emergency dump and make sure that the dumps made are valuable, but so far I can’t make the head or tail of what I see.

I think my first question is: is WinDbg configured correctly (another developer loads the dump in Visual Studio 2010 and sees the same errors, so I assume this is good, or we are both wrong :)), and then the following question: how I understand that this tells me.

The main confusion is that the dump seems to be telling me that it has reached the breaking point, which seems strange to me since no debugger was connected.

The application was launched on Windows Server 2003 when it crashed. I believe that I pointed WinDbg to the PDB file for DLL and EXE correctly.

FAULTING_IP: ntdll!DbgBreakPoint+0 7c81a3e1 cc int 3 EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 7c81a3e1 (ntdll!DbgBreakPoint) ExceptionCode: 80000003 (Break instruction exception) ExceptionFlags: 00000000 NumberParameters: 3 Parameter[0]: 00000000 Parameter[1]: 8779fdb0 Parameter[2]: 00000003 DEFAULT_BUCKET_ID: STATUS_BREAKPOINT PROCESS_NAME: CallPlusServerLauncher.exe ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached. EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: 8779fdb0 EXCEPTION_PARAMETER3: 00000003 NTGLOBALFLAG: 0 APPLICATION_VERIFIER_FLAGS: 0 ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[ffffffff] FAULTING_THREAD: ffffffff PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT STACK_TEXT: 1bd0ffc8 7c83fe08 00000005 00000004 00000001 ntdll!DbgBreakPoint 1bd0fff4 00000000 00000000 00000000 00000000 ntdll!DbgUiRemoteBreakin+0x36 FOLLOWUP_IP: ntdll!DbgBreakPoint+0 7c81a3e1 cc int 3 SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: ntdll!DbgBreakPoint+0 FOLLOWUP_NAME: MachineOwner MODULE_NAME: ntdll IMAGE_NAME: ntdll.dll DEBUG_FLR_IMAGE_TIMESTAMP: 49900d60 STACK_COMMAND: ddS 1bd10000 1bd0c000 ; dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~439s; .ecxr ; kb BUCKET_ID: MANUAL_BREAKIN FAILURE_BUCKET_ID: STATUS_BREAKPOINT_80000003_ntdll.dll!DbgBreakPoint WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/CallPlusServerLauncher_exe/0_0_0_0/4df87414/ntdll_dll/5_2_3790_4455/49900d60/80000003/0001a3e1.htm?Retriage=1 Followup: MachineOwner 

Answer 1

DbgBreakPoint - Looks like you broke execution using the remote debugger.

If you didn’t do this, I found that DbgBreakPoint appears when you have the code pages (Edit: I meant page heap ) turned on (you should know if you did), and invalid memory access was detected.

Answer 2

Assessors can also trigger a breakpoint exception. For example, I (too often) saw them exit the heap, checking for deletion when the heap is damaged by double deletion or overflow. But just with the debug time, which I thought was what you deployed?