> Can anyone refer me to a reference (MS or other) on how to read a DRWTSN32
> log?
>

> Also, to get my VC++ v8.0 program symbols used by DRWTSN32 what file should
> I place where?
>

> - list of modules loaded by the crashed process (for each module, the
> address range
> occupied by it is specified)

"Oleg Starodumov" <com-dot-debuginfo-at-oleg> wrote in message
news:uYn2eEEcHHA.4716@TK2MSFTNGP02.phx.gbl...
>
>> Can anyone refer me to a reference (MS or other) on how to read a
>> DRWTSN32
>> log?
>>
>
> Reading the log should be simple. It usually consists of the following
> parts:
> - appname, time, exception information
> - system information
> - list of processes running at the moment
> - list of modules loaded by the crashed process (for each module, the
> address range
> occupied by it is specified)
> - register values, and disassembly of a number of CPU instructions around
> the place
> where exception occurred; the exact place of the exception is marked with
> "FAULT ->"
> - call stack of the thread that raised the exception (if symbols have been
> found,
> it will show the function names and may be also source line info)
> - raw contents of stack memory
>
> Usually you should start by looking at the call stack. If symbols were
> properly loaded,
> you will see the function names there, and may be also source file/line
> info. If the latter
> is not shown, you can use the approach discussed in your previous post to
> find them
> (using the fault address reported in the disassembly part of the report,
> and return addresses
> in the call stack part).
>
>> Also, to get my VC++ v8.0 program symbols used by DRWTSN32 what file
>> should
>> I place where?
>>
>
> The easiest way is to place the symbols (the application's .pdb file) in
> the same directory
> with the executable. Note that Dr.Watson will be able to read VC8 symbols
> only
> on Windows XP and newer systems.
>
> Note that Dr.Watson will be able to show good call stack only if the crash
> occurred
> in one of your own modules (whose symbols are available). If the crash
> occurred in
> a system dll, the call stack will not be as good, since it will not be
> able to find symbols
> for that dll (at least in the default configuration) (the ultimate quality
> of the call stack
> in this case will depend on the operating system version; on newer OSs it
> still will be
> able to provide some call stack information).
>
> Also note that nowadays it is more effective to use crash dumps than
> Dr.Watson logs
> for crash analysis. With crash dumps, you don't have to have symbols on
> the user's system,
> can get good call stacks etc. even if the crash occurs in a system dll,
> and can get much more
> information about the application's state than Dr.Watson's log was ever
> able to provide.
> You can find an intro here:
> http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
> and lots of additional info on the net, including my site below.
>
> --
> Oleg
> [VC++ MVP http://www.debuginfo.com/]
>
>
>
>

"Andrew Chalk" <achalk@magnacartasoftware.com> wrote in message
news:etG6DNJcHHA.264@TK2MSFTNGP05.phx.gbl...
> Is this:
>> - list of modules loaded by the crashed process (for each module, the
>> address range
>> occupied by it is specified)
>
> *----> Stack Back Trace <----*
>
> FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
>
> 013E43EC 0043A0E1 00ACEB68 00000001 013E453C 013E4720 !<nosymbols>
>
> 013E4420 004383BA 00ACEB68 00000001 013E453C 013E4720 !<nosymbols>
>
> 013E4458 0042781C 00ACEB68 013E4630 013E4720 00ADE690 !<nosymbols>
>
> 013E453C 00427642 00ACEB68 00000050 013E4718 013E4720 !<nosymbols>
>
> 013E4630 0042443F 00000001 00000000 013E4718 013E4720 !<nosymbols>
>
> 013E4718 004235D6 013E4F14 013E4F1C 00ADE690 013E4870 !<nosymbols>
>
> 013E4F10 00422E15 00ADE800 013E5104 013E510C 00ADE690 !<nosymbols>
>
> 013E50F4 003AC0D5 00AE4780 00ADE800 013E0000 013E5A80 !<nosymbols>
>
> 013E5590 003A93B9 00ADE800 00000000 013E5A80 CCCCCCCC
> !MC::CSocketEventSinkImpl::OnRead
>
> 013EFF7C 003C2616 00ADE800 CCCCCCCC CCCCCCCC 00ADE690
> !MC::CSocketEventSinkImpl::OnRead
>
> 013EFFB4 7C57B388 00ADE968 CCCCCCCC CCCCCCCC 00ADE690
> !MC::CSocketEventSinkImpl::OnRead
>
> 013EFFEC 00000000 003C2560 00ADE690 00000000 000000C8 kernel32!lstrcmpiW
>
> =======================================
> It appears that the crash occurs in the C runtime as a result of a bad
> parameter.
>
> - A
>
> The crash occurs inside a module with no symbols (a system library) called
> from my application. But it is ultimately my process in which the crash
> occurs
>
> "Oleg Starodumov" <com-dot-debuginfo-at-oleg> wrote in message
> news:uYn2eEEcHHA.4716@TK2MSFTNGP02.phx.gbl...
>>
>>> Can anyone refer me to a reference (MS or other) on how to read a
>>> DRWTSN32
>>> log?
>>>
>>
>> Reading the log should be simple. It usually consists of the following
>> parts:
>> - appname, time, exception information
>> - system information
>> - list of processes running at the moment
>> - list of modules loaded by the crashed process (for each module, the
>> address range
>> occupied by it is specified)
>> - register values, and disassembly of a number of CPU instructions around
>> the place
>> where exception occurred; the exact place of the exception is marked
>> with "FAULT ->"
>> - call stack of the thread that raised the exception (if symbols have
>> been found,
>> it will show the function names and may be also source line info)
>> - raw contents of stack memory
>>
>> Usually you should start by looking at the call stack. If symbols were
>> properly loaded,
>> you will see the function names there, and may be also source file/line
>> info. If the latter
>> is not shown, you can use the approach discussed in your previous post to
>> find them
>> (using the fault address reported in the disassembly part of the report,
>> and return addresses
>> in the call stack part).
>>
>>> Also, to get my VC++ v8.0 program symbols used by DRWTSN32 what file
>>> should
>>> I place where?
>>>
>>
>> The easiest way is to place the symbols (the application's .pdb file) in
>> the same directory
>> with the executable. Note that Dr.Watson will be able to read VC8 symbols
>> only
>> on Windows XP and newer systems.
>>
>> Note that Dr.Watson will be able to show good call stack only if the
>> crash occurred
>> in one of your own modules (whose symbols are available). If the crash
>> occurred in
>> a system dll, the call stack will not be as good, since it will not be
>> able to find symbols
>> for that dll (at least in the default configuration) (the ultimate
>> quality of the call stack
>> in this case will depend on the operating system version; on newer OSs it
>> still will be
>> able to provide some call stack information).
>>
>> Also note that nowadays it is more effective to use crash dumps than
>> Dr.Watson logs
>> for crash analysis. With crash dumps, you don't have to have symbols on
>> the user's system,
>> can get good call stacks etc. even if the crash occurs in a system dll,
>> and can get much more
>> information about the application's state than Dr.Watson's log was ever
>> able to provide.
>> You can find an intro here:
>> http://www.codeproject.com/debug/postmortemdebug_standalone1.asp
>> and lots of additional info on the net, including my site below.
>>
>> --
>> Oleg
>> [VC++ MVP http://www.debuginfo.com/]
>>
>>
>>
>>
>
>

> Is this:
>> - list of modules loaded by the crashed process (for each module, the address range occupied by it is specified)
>
> *----> Stack Back Trace <----*
>
> FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
>
> 013E43EC 0043A0E1 00ACEB68 00000001 013E453C 013E4720 !<nosymbols>
>
> 013E4420 004383BA 00ACEB68 00000001 013E453C 013E4720 !<nosymbols>
>
> 013E4458 0042781C 00ACEB68 013E4630 013E4720 00ADE690 !<nosymbols>
>
> ...