How to read a Dr Watson dump?
Bruce Chastain
the customer, which I can not duplicate. I have the customer's Dr Watson
dump, but I can't figure out how to make sense of it. The addresses and
ordinal numbers make no sense to me. Can anyone shed some light on how to
read this? Here's a trimmed version of the dump.
Thanks!
Bruce.
Application exception occurred:
App: (pid=2872)
When: 5/30/2001 @ 03:00:30.773
Exception number: c0000005 (access violation)
*----> Task List <----*
2872 Pcqetix.exe
State Dump for Thread Id 0xb3c
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00152f70
edi=00000000
eip=6c386eec esp=0012fbe8 ebp=0012fbf4 iopl=0 nv up ei pl zr na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00000246
function: Ordinal2465
6c386ece 7549 jnz Ordinal4334+0x52 (6c396e19)
6c386ed0 ff7508 push dword ptr [ebp+0x8]
ss:0094d1c6=????????
6c386ed3 8d4e30 lea ecx,[esi+0x30]
ds:00970542=????????
6c386ed6 e887d6feff call Ordinal5628 (6c374562)
6c386edb 395e3c cmp [esi+0x3c],ebx
ds:00970542=????????
6c386ede 7532 jnz Ordinal4334+0x4b (6c396e12)
6c386ee0 ff762c push dword ptr [esi+0x2c]
ds:00970542=????????
6c386ee3 e89ba4feff call Ordinal2867 (6c371383)
6c386ee8 8bf8 mov edi,eax
6c386eea 8bcf mov ecx,edi
FAULT ->6c386eec 8b07 mov eax,[edi]
ds:00000000=????????
6c386eee ff5060 call dword ptr [eax+0x60]
ds:0081d5d2=????????
6c386ef1 3bfb cmp edi,ebx
6c386ef3 7409 jz Ordinal6637+0x2b (6c38f9fe)
6c386ef5 8b07 mov eax,[edi]
ds:00000000=????????
6c386ef7 6a01 push 0x1
6c386ef9 8bcf mov ecx,edi
6c386efb ff5004 call dword ptr [eax+0x4]
ds:0081d5d2=????????
6c386efe 8d4e4c lea ecx,[esi+0x4c]
ds:00970542=????????
6c386f01 895e2c mov [esi+0x2c],ebx
ds:00970542=????????
6c386f04 e8ababfeff call Ordinal5596 (6c371ab4)
6c386f09 395e74 cmp [esi+0x74],ebx
ds:00970542=????????
*----> Stack Back Trace <----*
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0012FBF4 6C387299 00000290 00000000 0030B1C8 6C38727A !Ordinal2465
77E99FAD A2840F00 FF0001F7 FF082474 FF082474 E813D415 !Ordinal4128
04247C83 00000000 00000000 00000000 00000000 00000000 <nosymbols>
Andre Vachon
Get the .dmp file from the customer, and you can load that into a debugger
like windbg or VC.
-Andre
"Bruce Chastain" <bcha...@XNOSPAMXhyperfeed.com> wrote in message
news:ONbty2e6AHA.1644@tkmsftngp05...
Bruce Chastain
news:eoSXegf6AHA.1652@tkmsftngp05...
> This is not the dump file. This is the log file which is of limited use.
> Get the .dmp file from the customer, and you can load that into a debugger
> like windbg or VC.
Sorry, I used the wrong word. I didn't know about the dmp file. Assuming
the customer has one, what do I do with it when I get it?
Bruce.
Slava M. Usov
news:ONbty2e6AHA.1644@tkmsftngp05...
to
> the customer, which I can not duplicate. I have the customer's Dr Watson
> dump, but I can't figure out how to make sense of it. The addresses and
> ordinal numbers make no sense to me. Can anyone shed some light on how to
> read this? Here's a trimmed version of the dump.
[...]
> 6c386ee3 e89ba4feff call Ordinal2867 (6c371383)
> 6c386ee8 8bf8 mov edi,eax
> 6c386eea 8bcf mov ecx,edi
> FAULT ->6c386eec 8b07 mov eax,[edi]
> ds:00000000=????????
> 6c386eee ff5060 call dword ptr [eax+0x60]
> ds:0081d5d2=????????
> 6c386ef1 3bfb cmp edi,ebx
> 6c386ef3 7409 jz Ordinal6637+0x2b (6c38f9fe)
[...]
This can be rewritten in C++:
some_class *object = Ordinal2876();
object->virtual_func_2b(); // this is where it faults
if( object != 0 )
{
// ....
}
The problem is obvious, isn't it?
Judging from that "ordinal" thing, I'd say there is some DLL that exports a
class and a static function of that class is called. The faulting address
0x6c386eec should lead you to the DLL in question: run your program under a
debugger and see which DLL has the range of addresses including that one. If
that is your DLL, then recompile it [in the same built configuration, which
is likely "release"] enabling map-file generation, then see what function
that address corresponds to.
Slava
Bruce Chastain
news:evIbjlg6AHA.612@tkmsftngp03...
> This can be rewritten in C++:
>
> some_class *object = Ordinal2876();
> object->virtual_func_2b(); // this is where it faults
> if( object != 0 )
> {
> // ....
> }
>
> The problem is obvious, isn't it?
Hmmm, not so far. :-(
> Judging from that "ordinal" thing, I'd say there is some DLL that exports
a
> class and a static function of that class is called. The faulting address
> 0x6c386eec should lead you to the DLL in question: run your program under
a
> debugger and see which DLL has the range of addresses including that one.
If
> that is your DLL, then recompile it [in the same built configuration,
which
> is likely "release"] enabling map-file generation, then see what function
> that address corresponds to.
When I load the program in the debugger, I see nothing at that address.
6C386EEA ???
6C386EEB ???
6C386EEC ???
6C386EED ???
6C386EEE ???
6C386EEF ???
6C386EF0 ???
6C386EF1 ???
6C386EF2 ???
I can find no dll that even comes close to that address, nor a similar
ordinal number. Any other ideas?
Bruce.
Andre Vachon
-Andre
"Bruce Chastain" <bcha...@XNOSPAMXhyperfeed.com> wrote in message
news:u5l79Bg6AHA.1504@tkmsftngp04...
Richard Musil
> 6c386ee3 e89ba4feff call Ordinal2867 (6c371383)
> 6c386ee8 8bf8 mov edi,eax
> 6c386eea 8bcf mov ecx,edi
> FAULT ->6c386eec 8b07 mov eax,[edi]
> ds:00000000=????????
> 6c386eee ff5060 call dword ptr [eax+0x60]
> ds:0081d5d2=????????
> 6c386ef1 3bfb cmp edi,ebx
> 6c386ef3 7409 jz Ordinal6637+0x2b (6c38f9fe)
> 6c386ef5 8b07 mov eax,[edi]
> ds:00000000=????????
> 6c386ef7 6a01 push 0x1
> 6c386ef9 8bcf mov ecx,edi
> 6c386efb ff5004 call dword ptr [eax+0x4]
CPossiblyClass * ptr = Ordinal2867();
ptr->offset_0x60();
if( ptr )
{
ptr->offset_0x04( 1 );
....
If you have source codes, you can look for this pattern.
Additionaly, you can instruct linker to create map file for the release
build using /map option and adding /MAPINFO:EXPORTS and /MAPINFO:LINES
directives to linker options in VC projects settings. Then find the crash
address in the map file (for more information you can look into "Debugging
applications" from John Robbins), you need however basic knowledge of how
DLL are loaded and used.
There could be few reasons why you do not see any code at those addresses
when debugging application:
1) code in debug build is at different address than in release build
2) when debugging, DLL is loaded at different base address because of some
conflict
3) DLL is not loaded at all.
--
Richard Musil
Slava M. Usov
> "Slava M. Usov" <stripit...@usa.net> wrote in message
> news:evIbjlg6AHA.612@tkmsftngp03...
> > This can be rewritten in C++:
> >
> > some_class *object = Ordinal2876();
> > object->virtual_func_2b(); // this is where it faults
> > if( object != 0 )
> > {
> > // ....
> > }
> >
> > The problem is obvious, isn't it?
>
> Hmmm, not so far. :-(
Ordinal2876() returns an object pointer, and a virtual function of that
object is immediately called. *THEN* the object pointer is checked for zero.
It should be checked before calling the virtual function...
> When I load the program in the debugger, I see nothing at that address.
Then use the stack trace and look for a return address that is in the
address range of your executable. Does you program reference any DLLs
written by you? If not, then it's hardly your problem, but you may still
want to find the faulting DLL and contact the vendor. It may be a COM DLL,
by the way.
Slava
Bruce Chastain
> > Hmmm, not so far. :-(
>
> Ordinal2876() returns an object pointer, and a virtual function of that
> object is immediately called. *THEN* the object pointer is checked for
zero.
> It should be checked before calling the virtual function...
Sorry, I meant that how to find that code isn't obvious to me yet. I can't
find anything in any of the I have the resembles that C code and I've done a
DumpBin on our few libraries and can't find a ordinal even remotely close to
2876.
> Then use the stack trace and look for a return address that is in the
> address range of your executable. Does you program reference any DLLs
> written by you? If not, then it's hardly your problem, but you may still
> want to find the faulting DLL and contact the vendor.
It does reference a couple of our DLLs, but none of the map files for those
libraries seem to help either.
Bruce.
Bruce Chastain
news:ODvBO5o6AHA.1420@tkmsftngp05...
> If you have source codes, you can look for this pattern.
I haven't been able to find anything in our code that resembles that.
> Additionaly, you can instruct linker to create map file for the release
> build using /map option and adding /MAPINFO:EXPORTS and /MAPINFO:LINES
> directives to linker options in VC projects settings. Then find the crash
> address in the map file (for more information you can look into "Debugging
> applications" from John Robbins), you need however basic knowledge of how
> DLL are loaded and used.
Thanks for the linker options, but I still can't find any addresses or
ordinals that are remotely close to what was in the Dr Watson log.
> There could be few reasons why you do not see any code at those addresses
> when debugging application:
> 1) code in debug build is at different address than in release build
> 2) when debugging, DLL is loaded at different base address because of some
> conflict
> 3) DLL is not loaded at all.
The executable does load a DLL using LoadLibary, but I was careful to step
over that before checking for code loaded at that address.
This has really got me stumped!
Thanks,
Bruce.
Bruce Chastain
this (just an extract):
ordinal hint RVA name
<snip>
2464 00084F80 [NONAME]
2465 00083AD1 [NONAME]
2466 0007CBFA [NONAME]
<snip>
4127 000458E0 [NONAME]
4128 00045487 [NONAME]
4129 00044CB0 [NONAME]
So it seems that the ordinal numbers from the Dr Watson call stack
(Ordinal2465, Ordinal4128) do exist in the MFC DLL. So my next problem is,
how do I tell what MFC functions those ordinals represent? [NONAME] isn't
very helpful.
Thanks,
Bruce.
Owen Wengerd
> how do I tell what MFC functions those ordinals represent?
Look at MFC42.def included with the MFC source code (in the MFC\SRC\Intel
folder in my VC6 installation). :)
--
Owen Wengerd
President, ManuSoft ==> http://www.manusoft.com
VP Americas, CADLock, Inc. ==> http://www.cadlock.com
Bruce Chastain
news:e7PHdWr6AHA.1400@tkmsftngp04...
> > how do I tell what MFC functions those ordinals represent?
>
> Look at MFC42.def included with the MFC source code (in the
MFC\SRC\Intel
> folder in my VC6 installation). :)
Cool, that helped a lot! That gives me these functions that match the call
stack:
?FromHandlePermanent@CWnd@@SGPAV1@PAUHWND__@@@Z @ 2867 NONAME
?DetachHandle@CAsyncSocket@@SGXIH@Z @ 2465 NONAME
?KillSocket@CAsyncSocket@@SGXIPAV1@@Z @ 4128 NONAME
So now I have to figure out why DetachHandle blew up. This code:
6c386ee3 e89ba4feff call Ordinal2867 (6c371383)
6c386ee8 8bf8 mov edi,eax
6c386eea 8bcf mov ecx,edi
FAULT ->6c386eec 8b07 mov eax,[edi]
looks like this code from CAsyncSocket::DetachHandle() in sockcore.cpp:
ASSERT(CAsyncSocket::LookupHandle(hSocket, bDead) != NULL);
_AFX_SOCK_THREAD_STATE* pState = _afxSockThreadState;
if (!bDead)
{
pState->m_pmapSocketHandle->RemoveKey((void*)hSocket);
if (pState->m_pmapSocketHandle->IsEmpty())
{
ASSERT(pState->m_hSocketWindow != NULL);
CWnd* pWnd =
CWnd::FromHandlePermanent(pState->m_hSocketWindow); <--(ordinal 2867)
ASSERT_VALID(pWnd);
pWnd->DestroyWindow(); <-------- This line.
delete pWnd;
pState->m_hSocketWindow = NULL;
pState->m_pmapDeadSockets->RemoveAll();
while (!pState->m_plistSocketNotifications->IsEmpty())
delete pState->m_plistSocketNotifications->RemoveHead();
}
}
This is making sense because one of our DLLs does create a CAsyncSocket
class (loaded via LoadLibrary), and this code looks like it would be called
at shutdown, which is when the crash occurs. So now, why would the pWnd be
invalid, and only intermittantly (30% of the time according to the
customer)?
But now that I see that code, why the heck would CAsyncSocket be calling
DestroyWindow at all?
Bizzare.
Bruce.
Joel Jacob
To do some serious work with sockets, DO NOT USE CAsyncSocket.
In the narrow windows-centric approach of Microsoft, everything is related
to windows and when there are no windows to attach to... they are lost...
So you can design a very simple class to handle sockets, really it is a
simple wrapper around the BSD API (and there a lot of these wrappers on the
net, and a special mention to the very serious work of Sam Blackburn
_www.samblackburn.com_). Then, when you get intro trouble, you will know why
and when !
Joel Jacob
Azur Soft
"Bruce Chastain" <bcha...@XNOSPAMXhyperfeed.com> a écrit dans le message
news: uACqcmr6AHA.1888@tkmsftngp07...
Magnus Bäck
"Joel Jacob" <jo...@azursoft.com.nospam> wrote:
> To do some serious work with sockets, DO NOT USE CAsyncSocket.
>
> In the narrow windows-centric approach of Microsoft, everything is related
> to windows and when there are no windows to attach to... they are lost...
No, they're not. Each thread has its own message queue so as long as
you have a thread with a message pump you can use the asynchronous
sockets. Although I agree that they're a dog sometimes.
[...]
--
Magnus Bäck | CS/CE student, Lund Institute of Technology
ba...@swipnet.se | http://www.jpldata.net/~magnus/english.html