2

Over a year ago I already used WinDbg and DebugDiag to find a memory leak in a JNI native DLL that we use from within Java. Now I am searching for a thread handle leak. I created a memory dump using Process Explorer and tried to analyze it in DebugDiag, but all I get are script errors: Memory dump analysis fails with script errors

I also tried WinDbg, but it is not able to attach to a process anymore. I always get the error message "dbghelp.dll has a version mismatch with the debugger": WinDbg 6.12.0002.633 X86 fails with "Could not attach to process xxx 0x80004005" ("Unbekannter Fehler" means "Unknown error")

I uninstalled DebugDiag and the Windows SDK, then downloaded the newest versions and installed Windows SDK 8 and DebugDiag 1.2 (x86). The problem stays the same. Even after replacing the Windows SDK with Version 7.1 (the latest SDK for Windows 7) nothing changes.

I'm using a machine with Windows 7 (32 Bit).

I assume that the problems in DebugDiag have the same cause as the problems in WinDbg. But I don't understand what version mismatch is meant (and googling didn't help either):

  • WinDbg: 6.12.0002.633
  • dbgeng: 6.12.0002.633
  • dbghelp: 6.12.0002.633

How can I make WinDbg (and hopefully DebugDiag) work again?

Jens Berger
  • 134
  • 2
  • 8
  • This is indeed strange. Can you verify the debugger process has loaded a copy of dbghelp.dll (in process explorer, for instance) or that dbghelp.dll from the debugger's folder is indeed a valid PE file (dumpbin or depends to the rescue)? – deemok Apr 09 '13 at 17:28
  • I checked the DLL. WinDbg really loads the DLL from the Debugging Tools path as shown in the screenshot. Depends reports only that it can't find ieshims.dll as dependency. Besides that it looks like a valid DLL. I copied the ieshims.dll from the Internet Explorer folder to the Debugging Tools folder but that didn't help. – Jens Berger Apr 10 '13 at 09:27
  • Just a wild guess - did you try to check version of dbghelp.dll used by process explorrer? Is it possible that it used a newer version of dbghelp.dll to create the dump? – Jan Aug 01 '14 at 19:54
  • Hmm. I'm quite sure I checked versions with Process Explorer back then. – Jens Berger Aug 19 '14 at 10:32

1 Answers1

0

This is pseudo code of the part of dbgeng that performs this check:

var (
    g_ApiVersion = API_VERSION{1, 0, 12, 0}
    g_DbghelpVersion API_VERSION
    g_EngOptions = Options{...}
)

func ChkDbghlpVersion() uint32 {
    g_DbghlpVersion = dbghelp.ImagehlpVersionEx(g_ApiVersion)
    if g_DbghelpVersion.Revision < g_ApiVersion.Revision {
        DebugOutput("dbghelp.dll has version mismatch with the debugger")
        if !(g_EngOptions.SomeOpt & 1) {
            return E_UNKNOWN
        }
    }
    return S_OK
}

So, you should check what dbghelp.dll from the debugging folder returns from ImagehlpApiVersionEx (and possibly what dbgeng.dll has in its g_ApiVersion) to find out why your debugger is failing.

Possible causes:

  • dbghelp.dll really has an alternate build information.
  • dbgeng.dll is corrupt (?) and contains invalid data in its api version block
deemok
  • 2,735
  • 19
  • 11
  • Ok, I checked dbghelp.dll for different calls of ChkDbghlpVersion: 1. The version from dbgeng.dll seems to be fine: `g_ApiVersion: 6.12.2.633, g_DbghlpVersion: 6.12.2.633`. 2. The version of dbghelp.dll in the windows32 directory gives this: `g_ApiVersion: 6.1.7601.17514, g_DbghlpVersion: 6.1.5.0`. 3. The same for Your example: `g_ApiVersion: 1.0.12.0, g_DbghlpVersion: 6.1.5.0` – Jens Berger Apr 25 '13 at 18:31