WinDbg not showing useful information

13,276

Solution 1

If you believe the PDB should be in your symbol path, you should run something like this:

!sym noisy
.reload MyApp.dll
kp

!sym noisy causes the debugger to give out more detailed information on why it couldn't load symbols - no MyApp.pdb found, found but does not match, etc. This will help you find out why it is not loading symbols. !sym noisy again turns off the verbose symbol output.

Solution 2

When you set the path for symbols, did you reload them?

.reload

I'm not sure your adding

srv*c:\symcache*C:\dev\Customer\MyAppSln\MyApp\Debug

to the symbol path has the desired effect. I usually list all local paths in the .sympath first, and as the last step, I do .symfix+ to configure the public symbols using the microsoft symbol server:

.sympath C:\dev\Customer\MyAppSln\MyApp\Debug
.symfix+ c:\symcache

the rationale behind listing local paths first being that the debugger would not have to check the remote server for pdbs (that are not there anyways) as opposed to simply retrieving them locally.

Anyways, your problem is that the symbols for MyApp are not loaded therefore stack walking does not quite work. Debugger walks the stack backwards, starting from the top, that's why you're seeing MyApp - this is where the access violation occurred. Now, since debugger does not have the symbols at this point, it can only guess what invocation chain has led to the function on top. And it guesses wrong by following a misleading path.

Share:
13,276
Michael Bray
Author by

Michael Bray

Programmer of almost 30 years (OMG!), currently focused on C# development.

Updated on June 04, 2022

Comments

  • Michael Bray
    Michael Bray almost 2 years

    First let me say I am a total WinDbg noob, so this might be an easy question...

    I have an application ("MyApp" - name changed to protect the innocent!) that I am trying to debug because it is throwing an exception. This only happens on user machines - I have not been able to reproduce it on my development machine. So I set up DebugDiag on the users machine and captured a Full Dump. Then I loaded the dump in WinDbg and did an analyze -v and a kp to try to figure out what was going on... but neither of these seem to give me the information that I'm looking for - the function (and hopefully the line number) of the line that is causing the problem... I think I have the symbol file loaded by specifying the path to 'MyApp.pdb' in the Symbol File Path:

    srv*c:\symcache*http://msdl.microsoft.com/download/symbols;srv*c:\symcache*C:\dev\Customer\MyAppSln\MyApp\Debug
    

    First, here's the output from kp:

    0:004> kp
    ChildEBP RetAddr  
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0502f474 7c347966 MyApp!DllMain+0x3e8a6
    0502f4bc 7c3a2448 msvcr71!_nh_malloc(unsigned int size = <Memory access error>, int nhFlag = <Memory access error>)+0x24 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c @ 117]
    0502f57c 7c3416b3 msvcp71!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::_Tidy(bool _Built = <Memory access error>, unsigned int _Newsize = <Memory access error>)+0x45 [f:\vs70builds\3077\vc\crtbld\crt\src\xstring @ 1520]
    0502f610 7c3a32de msvcr71!_heap_alloc(unsigned int size = <Memory access error>)+0xe0 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c @ 212]
    0502f620 7c3b3f63 msvcp71!wmemcpy(wchar_t * _S1 = 0x04e463b9 "Ҹ???", wchar_t * _S2 = 0xffffffff "--- memory read error at address 0xffffffff ---", unsigned int _N = 0x4e25212)+0x14 [f:\vs70builds\3077\vc\crtbld\crt\src\wchar.h @ 843]
    0502f640 04e463b9 msvcp71!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::assign(class std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * _Right = 0xffffffff, unsigned int _Roff = 0x4e25212, unsigned int _Count = 2)+0x7c [f:\vs70builds\3077\vc\crtbld\crt\src\xstring @ 601]
    0502f770 04df1077 MyApp!DllMain+0x65329
    0502f824 04e01b35 MyApp!DllMain+0xffe7
    0502ff08 04dfe034 MyApp!DllMain+0x20aa5
    0502ff48 04dfde4f MyApp!DllMain+0x1cfa4
    0502ff88 7648d0e9 MyApp!DllMain+0x1cdbf
    0502ffc4 773499f9 kernel32!BaseThreadInitThunk+0xe
    0502ffd4 7738198e ntdll!RtlQueryInformationAcl+0x8b
    0502ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
    

    the line I'm specifically trying to decode is the 'MyApp!DllMain+0x65329' as this is the last line that seems to be executing, and the error is occurring within the malloc call, which is apparently where the exception is being thrown from. What am I doing wrong that makes it only display the module and offset instead of source file and line number?

    I'm also not sure why the line above the malloc call is back in MyApp again - maybe someone can explain that too.

    Just in case, here's the output from 'analyze -v':

    0:004> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************
    
    *** WARNING: Unable to verify checksum for MyApp.exe
    *** ERROR: Module load completed but symbols could not be loaded for MyApp.exe
    *** WARNING: Unable to verify checksum for ThirdPartyDll.dll
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for ThirdPartyDll.dll - 
    *** WARNING: Unable to verify checksum for mdnsNSP.dll
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for mdnsNSP.dll - 
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for SLC.dll - 
    
    FAULTING_IP: 
    MyApp!DllMain+3e8a6
    04e1f936 8b16            mov     edx,dword ptr [esi]
    
    EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
    ExceptionAddress: 04e1f936 (MyApp!DllMain+0x0003e8a6)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 00000000
       Parameter[1]: 00000000
    Attempt to read from address 00000000
    
    PROCESS_NAME:  MyApp.exe
    
    ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
    
    EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
    
    EXCEPTION_PARAMETER1:  00000000
    
    EXCEPTION_PARAMETER2:  00000000
    
    READ_ADDRESS:  00000000 
    
    FOLLOWUP_IP: 
    msvcr71!_heap_alloc+e0 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c @ 212]
    7c3416b3 e88e0c0000      call    msvcr71!__SEH_epilog (7c342346)
    
    NTGLOBALFLAG:  0
    
    APPLICATION_VERIFIER_FLAGS:  0
    
    LAST_CONTROL_TRANSFER:  from 00000000 to 773bbb33
    
    FAULTING_THREAD:  ffffffff
    
    BUGCHECK_STR:  APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_NULL_POINTER_READ_SHUTDOWN
    
    PRIMARY_PROBLEM_CLASS:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN
    
    DEFAULT_BUCKET_ID:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN
    
    STACK_TEXT:  
    773bbb33 ntdll!RtlpAllocateHeap+0x7ad
    773a6e0c ntdll!RtlAllocateHeap+0x1e3
    7c3416b3 msvcr71!_heap_alloc+0xe0
    
    
    FAULTING_SOURCE_CODE:  
    No source found for 'f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c'
    
    
    SYMBOL_STACK_INDEX:  2
    
    SYMBOL_NAME:  msvcr71!_heap_alloc+e0
    
    FOLLOWUP_NAME:  MachineOwner
    
    MODULE_NAME: msvcr71
    
    IMAGE_NAME:  msvcr71.dll
    
    DEBUG_FLR_IMAGE_TIMESTAMP:  3e561eac
    
    STACK_COMMAND:  dds 7740c078 ; kb
    
    FAILURE_BUCKET_ID:  ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN_c0000005_msvcr71.dll!_heap_alloc
    
    BUCKET_ID:  APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_NULL_POINTER_READ_SHUTDOWN_msvcr71!_heap_alloc+e0