0

I have next workflow:

1) Build dll and pdb files.

2) Share dll to cutomer

3) Analize memory dump from customer.

When I run !analyze -v in WinDbg I got (below part of output)

....
MANAGED_STACK_COMMAND:  _EFN_StackTrace
PRIMARY_PROBLEM_CLASS:  WRONG_SYMBOLS
BUGCHECK_STR:  APPLICATION_FAULT_WRONG_SYMBOLS
// some callstack here
MODULE_NAME: RTPLogic
IMAGE_NAME:  RTPLogic.dll
DEBUG_FLR_IMAGE_TIMESTAMP:  58a43706
STACK_COMMAND:  ~541s; .ecxr ; kb
FAILURE_BUCKET_ID:  WRONG_SYMBOLS_c0000374_RTPLogic.dll!CSRTPStack::Finalize
BUCKET_ID:     X64_APPLICATION_FAULT_WRONG_SYMBOLS_rtplogic!CSRTPStack::Finalize+1da

Looks like we have wrong debug symbol for RTPLogic.dll. I download ChkMatch tool. I get pdb path from windbg

0:541> !lmi RTPlogic.dll
Loaded Module Info: [rtplogic.dll] 
         Module: RTPLogic
.....
            Age: 1, Pdb: D:\Work\path_to_original_pdb\RTPLogic.pdb
     Image Type: MEMORY   - Image read successfully from loaded memory.
    Symbol Type: PDB      - Symbols loaded successfully from image header.
                 C:\ProgramData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb
       Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
    Load Report: private symbols & lines, not source indexed 
                 C:\ProgramData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb

I have logs related to this dump and I see that my changes appears in logs. So customer not forgotten to install my DLL before get the memdump. I run ChkMatch

PS D:\tools> .\ChkMatch.exe -c "D:\Work\path_to_dll\RTPLogic.dll" "C:\Progra
mData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb"
.....
Result: Matched

How it possible that I got wrong debug symbols in such situation?

Stepan Loginov
  • 1,667
  • 4
  • 22
  • 49
  • That's too little information, too vague. Could you post some concrete output, please? What's the exact output of ChkMatch, what's the exact warning text in WinDbg. What's the symbol path? Do both tools really use the same files? Post the output of `lm`, `.symopt` and `.sympath` in WinDbg. Normally WinDbg does not load non-matching symbols at all. If it does, you have already "tweaked" something – Thomas Weller Mar 02 '17 at 14:12
  • Ok, but now it looks like different question – Stepan Loginov Mar 02 '17 at 15:23
  • What you added to the question confirms what I had in mind. I can now answer your question with more confidence. +1 for following up and providing the necessary information – Thomas Weller Mar 02 '17 at 16:08
  • c0000374 = heap corruption, activate appverifier/pageheap to detect the real cause, the corruption happend way before your finalizer tries to free the memory. – magicandre1981 Mar 04 '17 at 17:54
  • yes, you are right. I just want to understand do I have all debug symbols to continue investigation with those flag. I afraid that memory corruption is the reason why I see "wrong debug symbols". – Stepan Loginov Mar 06 '17 at 10:55

1 Answers1

1

The symbols for RTPLogic.dll!CSRTPStack::Finalize are correct, but other symbols that are required to reconstruct the call stack are incorrect. It's likely that you have some operating system methods on the call stack and the symbols for ntdll or similar are missing.

Since with ChkMatch, you're only checking one single PDB file, the result of ChkMatch is as reliable and correct (for one PDB) as that of WinDbg (for many PDBs) and they do not contradict each other.

Your sympath probably contains only a local path to your own DLLs and does not contain any information about Microsoft's symbol server. In the output of .sympath (which you did not post), I expect to see something like

0:000> .sympath
D:\Work\path_to_dll

You should include Microsoft symbols as well, as described in How to set up symbols in WinDbg. To fix the problem, use the following commands:

.symfix+ c:\symbols
.reload /f

The output of .sympath should now look like

0:000> .sympath
D:\Work\path_to_dll;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

This should help WinDbg in reconstructing the complete call stack, resolve OS methods of ntdll and others and thus get rid of the "wrong symbols" message.

Community
  • 1
  • 1
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222