Update: I got your code to compile and it produces the same problem. After
the corrupt full memory dump has been opened, your function
GetStackFromDumps returns FALSE and the corresponding output is:
GetContextState failed, 0x80070026
Unable to get program counter
GetContextState failed, 0x80070026
GetContextState failed, 0x80070026
stackdump failed for c:\windows\minidump\011512-6957-01.dmp
etc.
Without analyzing the corrupt dump first, it properly displays the stack for
all dump files. I really hoped I had overlooked something in my code but I
can only conclude that dbgeng is broken. The engine gets in a corrupt state
after a corrupt full memory dump has been analyzed. I have been trying with
a list of different versions of dbgeng.dll and dbghelp.dll, all show the
same problem.
//Daniel
wrote in message news:xxxxx@windbg…
> Either GetStackTrace or kb via an output callback won’t work after the
> corrupt full memory dump file has been analyzed.
>
> Can you please rerun this test with a corrupt full memory dump file as
> first file to be processed ? The problem only comes with corrupt full
> memory dump files and not with corrupt minidump files. After this file has
> been analyzed, the engine appears in a broken state.
>
> For your convenience I put a a truncated full memory dump file here
> http://www.resplendence.com/download/TruncatedFullMemoryDump.zip
>
> Thanks,
>
> //Daniel
>
>
>
>
>
> “raj_r” wrote in message news:xxxxx@windbg…
>>i am not sure if GetStackTrace and windbg kb return same data
>> but when i needed to get look at several dump files stack i used this
>> code below
>>
>> it parsed all the files that had .dmp extension and didn’t fail
>>
>> see if anything in this helps you
>>
>> i used a bat file to run the compiled binary
>>
>>
>> dir /b .dmp > dumpfiles.txt
>> for /F %%I in (dumpfiles.txt) do .\exectest\GetStackFromDumps.exe %%I
>>>> result.txt
>>
>> code as follows
>>
>> #include <stdio.h>
>> #include <engextcpp.hpp>
>> int __cdecl InitDebugInterfaces(void);
>> int__cdecl GetStackFromDumps(char * DumpFileName);
>> IDebugClient g_Client;
>> IDebugControl* g_Control;
>> HRESULT status;
>> #ifndef OUT_HPP
>> #define OUT_HPP
>> class StdioOutputCallbacks : public IDebugOutputCallbacks
>> {
>> public:
>> STDMETHOD(QueryInterface)( THIS_ IN REFIID InterfaceId, OUT PVOID*
>> Interface );
>> STDMETHOD_(ULONG, AddRef)( THIS );
>> STDMETHOD_(ULONG, Release)( THIS );
>> STDMETHOD(Output)( THIS_ IN ULONG Mask, IN PCSTR Text );
>> };
>> #endif
>> STDMETHODIMP
>> StdioOutputCallbacks::QueryInterface( THIS_ IN REFIID InterfaceId,
>> OUT PVOID* Interface ) {
>> Interface = NULL;
>> if (IsEqualIID(InterfaceId, _uuidof(IUnknown)) ||
>> IsEqualIID(InterfaceId,uuidof(IDebugOutputCallbacks))) {
>> *Interface = (IDebugOutputCallbacks *)this;
>> AddRef();
>> return S_OK;
>> } else {
>> return E_NOINTERFACE;
>> }
>> }
>> STDMETHODIMP(ULONG)
>> StdioOutputCallbacks::AddRef( THIS ) {
>> return 1;
>> }
>> STDMETHODIMP(ULONG)
>> StdioOutputCallbacks::Release( THIS ) {
>> return 0;
>> }
>> STDMETHODIMP
>> StdioOutputCallbacks::Output( THIS IN ULONG Mask, IN PCSTR Text) {
>> UNREFERENCED_PARAMETER(Mask);
>> fputs(Text, stdout);
>> return S_OK;
>> }
>> StdioOutputCallbacks g_Callback;
>> int __cdecl InitDebugInterfaces(void) {
>>
>> if(
>> (DebugCreate(__uuidof(IDebugClient), (void*)&g_Client ) ||
>> g_Client->QueryInterface( __uuidof(IDebugControl), (void**)&g_Control) ||
>> g_Client->SetOutputCallbacks( &g_Callback)) != S_OK
>> )
>> return FALSE;
>> return TRUE;
>> }
>> int__cdecl GetStackFromDumps(char * DumpFileName){
>>
>> if ((g_Client->OpenDumpFile( DumpFileName) ||
>> g_Control->WaitForEvent( 0, INFINITE ) ||
>> g_Control->Execute( DEBUG_OUTCTL_THIS_CLIENT, “kb”,
>> DEBUG_EXECUTE_DEFAULT)
>> ) != S_OK)
>> return FALSE;
>> return TRUE;
>> }
>> int __cdecl main (int argc, char* argv) {
>>
>> if (( InitDebugInterfaces() ) == FALSE) {
>> printf (" InitDebugInterfaces Failed \n");
>> return NULL;
>> }
>> for (int i=1; i< argc ; i++)
>> {
>>
>> if (( GetStackFromDumps(argv[i]) ) == FALSE ) {
>> printf(" stackdump failed for %s\n" , argv[i]);
>> }
>> }
>> g_Control->Release();
>> g_Client->Release();
>> return 1;
>> }
>>
>>
>> and i got results like
>>
>>
>>
>>
>>
>>
>>
>> Loading Dump File [F:\opendump\corrupt_dump\1.dmp]
>> User Mini Dump File: Only registers, stack and portions of memory are
>> available
>>
>> cut ----------------------------------------
>> ChildEBP RetAddr Args to Child
>> 00f1bcac 7c90df4a 7c809590 00000002 00f1bcd8 ntdll!KiFastSystemCallRet
>> 00f1bcb0 7c809590 00000002 00f1bcd8 00000001
>> ntdll!ZwWaitForMultipleObjects+0xc
>> cut -----------------------------------------------
>>
>> Loading Dump File [F:\opendump\corrupt_dump\2.dmp]
>> Could not open dump file [2.dmp], NTSTATUS 0xC000011E
>> “An attempt was made to map a file of size zero with the maximum
>> size specified as zero.”
>> stackdump failed for 2.dmp
>>
>> cut -------------------------------------------------
>>
>> Loading Dump File [F:\opendump\corrupt_dump\3.dmp]
>> User Mini Dump File: Only registers, stack and portions of memory are
>> available
>> cut ----------------------------------------------------------------
>> 00f1ff94 0041fc1d 00000000 00000017 00000009 windbg+0x1e4e7
>> 00f1ffb4 7c80b729 00000000 00000017 00000009 windbg+0x1fc1d
>> 00f1ffec 00000000 0041f87c 00000000 00000000
>> kernel32!BaseThreadStart+0x37
>>
>> cut -------------------------------------------------------------------
>> Loading Dump File [F:\opendump\corrupt_dump\4.dmp]
>> Could not match Dump File signature - invalid file format
>> Could not open dump file [4.dmp], Win32 error 0n87
>> “The parameter is incorrect.”
>> stackdump failed for 4.dmp
>>
>>
>> On 9/11/12, xxxxx@resplendence.com wrote:
>>> Thanks for your reply. You are right about that, I overlooked Stop
>>> Debugging
>>>
>>> after that you can open a new crash dump file. How can I select stop
>>> debugging from my code ?
>>>
>>> If I feed a list of crash dumps to this routine one by one, everything
>>> runs
>>>
>>> fine. But only until I open a corrupt dump file, after that it returns
>>> the
>>> same error for every next valid dump file.
>>>
>>>
>>> HRESULT GetCrashDumpInfo(char *crashDumpFile)
>>> {
>>> HRESULT hr = E_FAIL;
>>> DEBUG_STACK_FRAME stackFrames[4096] = {0};
>>> IDebugClient client = NULL;
>>> IDebugControl2 control2 = NULL;
>>>
>>> UUONG numFrames;
>>>
>>> // Create the base IDebugClient object
>>> hr = DebugCreate(__uuidof(IDebugClient), (LPVOID)&client);
>>> if(FAILED(hr))
>>> goto cleanup;
>>>
>>> // from the base, create the Control and Symbols objects
>>> hr = client->QueryInterface(__uuidof(IDebugControl2),
>>> (LPVOID)&control2);
>>> if(FAILED(hr))
>>> goto cleanup;
>>>
>>> control2->WaitForEvent(DEBUG_WAIT_DEFAULT, INFINITE);
>>>
>>> hr = client->OpenDumpFile(crashDumpFile);
>>>
>>> if(FAILED(hr))
>>> goto cleanup;
>>>
>>> control2->WaitForEvent(DEBUG_WAIT_DEFAULT, INFINITE);
>>>
>>> //
>>> hr=control2->ReadBugCheckData(&info->bugCheckCode,&info->parm1,&info->parm2,&info->parm3,&info->parm4);
>>>
>>> // Now get the stack trace
>>> numFrames=RSPMAXFRAMES-1;
>>>
>>> hr = control2->GetStackTrace(0, 0, 0, &stackFrames[0], numFrames,
>>> &numFrames);
>>>
>>> if(FAILED(hr))
>>> {
>>> numFrames=0;
>>> goto cleanup;
>>> }
>>>
>>> control2->WaitForEvent(DEBUG_WAIT_DEFAULT, INFINITE);
>>>
>>> cleanup:
>>>
>>> // cleanup and destroy the objects
>>> if(control2)
>>> control2->Release();
>>>
>>> if(client)
>>> client->Release();
>>>
>>>
>>> return hr;
>>> }
>>>
>>>
>>> Thanks,
>>>
>>> //Daniel
>>>
>>>
>>>
>>>
>>>
>>> “Timothy Misiak” wrote in message
>>> news:xxxxx@windbg…
>>> Can you include a code sample that shows the problem? What are you doing
>>> after OpenDumpFile?
>>>
>>> I have no problems opening a crash dump, closing the crash dump, then
>>> opening a new crash dump in WinDbg. Are you using the Debug->Stop
>>> Debugging
>>>
>>> menu item?
>>>
>>> -Tim
>>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com] On Behalf Of
>>> xxxxx@resplendence.com
>>> Sent: Sunday, September 9, 2012 4:00 AM
>>> To: Kernel Debugging Interest List
>>> Subject: [windbg] bug in DBGENG ?
>>>
>>> I have a problem with dbgeng.dll. I have a crash analyzer swoftware and
>>> there is a problem with the debug engine after I tried to analyze a
>>> corrupt
>>>
>>> full memory dump file.
>>>
>>> When I call IDebugControl::GetStackTrace on the corrupt dump file, it
>>> returns 0x80070026 (Reached the end of file). After that happened it
>>> returns
>>>
>>> that same error for any subsequent valid dump file that I wish to
>>> analyze. I
>>>
>>> am creating a new IDebugControl and new IDebugClient object for every
>>> file
>>> that I open. Functions like OpenDumpFile and ReadBugCheckData all
>>> return
>>> success. but the same problem comes when I try to execute some debugger
>>> command on the file, after the corrupt file has been opened the output
>>> is
>>> always:
>>>
>>>>GetContextState failed, 0x80070026
>>>
>>> I am suspecting there is a bug which corrupts the internal state of
>>> DBGENG
>>> and I tried to debug it to see what’s going on but I did not get very
>>> far.
>>>
>>> I also suspect that MS is aware of the problem. Because if you run
>>> WinDbg
>>> and select File->Open Crash Dump, then close the crash dump file, the
>>> Open
>>> Crash Dump option remains greyed out so that you would never bump in
>>> this
>>> problem. You need to open a fresh copy of WinDbg for every crash dump
>>> file
>>> you wish to analyze.
>>>
>>> Did anyone else come across this problem ? Can anyone confirm this is a
>>> bug
>>>
>>> ? Does anyone know of a possible solution, for instance to magically
>>> reset
>>> the debug engine to its initial state. Or any other way to work around
>>> the
>>> problem other than unloading and reloading DBGENG.DLL ?
>>>
>>> Thanks,
>>>
>>> //Daniel
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> —
>>> WINDBG is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>>
>>>
>>>
>>>
>>> —
>>> WINDBG is sponsored by OSR
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>
>
>
></engextcpp.hpp></stdio.h>