0

This is something like the question WinDbg: Version mismatch of dbghelp.dll when trying to attach to a process However, I can't post to that question and the marked answer isn't really an answer and doesn't work for me.

I have a machine which I used to use for debugging crash dumps, but suddenly it fails to open any dumps, always reporting

dbghelp.dll has a version mismatch with the debugger

Microsoft (R) Windows Debugger Version 10.0.14321.1024 X86
Copyright (c) Microsoft Corporation. All rights reserved.

command line: '"C:\Program Files (x86)\Windows Kits\Debuggers\x86\windbg.exe" -c ".cmdtree c:\cmdtree.txt"
dbgeng:  image 10.0.14321.1024, built Sat Jul 16 09:31:09 2016
[path: C:\Program Files (x86)\Windows Kits\Debuggers\x86\dbgeng.dll]
dbghelp: image 10.0.14321.1024, built Sat Jul 16 09:29:50 2016
[path: C:\Program Files (x86)\Windows Kits\Debuggers\x86\dbghelp.dll]
DIA version: 40116

So it's complaining of a mismatch, but there is no apparent mismatch.

The version of dbghelp and dbgeng in System32 and SysWOW64 is 6.1.7601.17514. But note that:

a) According to Microsoft page on DbgHelp, the version in Windows and WinDbg does not need to be (and probably shouldn't be) synced

b) I have another machine where I have installed 10.0.14321.1024 version of WinDbg, and it also has version 6.1.7601.17514 of dbghelp and dbgeng in Windows folders, and everything's working fine on that machine.

Any assistance appreciated. This machine is basically bricked as far as analyzing crash dumps is concerned. I've tried reinstalling windbg, and installing different versions, still the same error occurs.

Community
  • 1
  • 1
Mijin
  • 125
  • 1
  • 9
  • Could be windbg is reading dbghelp.dll from PATH environment variable. Can you check if anything suspicious in PATH environment variable value? And can you search for more copies of dbghelp.dll in your pc? – Rahul Sundar Sep 27 '16 at 09:17
  • It was a good idea, but I just tried moving winDbg folder to start of my path and then launch WinDbg and still have same issue. As for other copies of dbghelp.dll; actually many apps have their own local copy of dbghelp.dll, or at least a DLL called that. dbgeng is rarer but my winsxs folder for example has a bunch of versions – Mijin Sep 27 '16 at 10:43
  • 2
    Use [process monitor](https://technet.microsoft.com/de-de/sysinternals/processmonitor.aspx) to find out where it really loads dbghelp.dll from – Thomas Weller Sep 27 '16 at 11:55
  • @Thomas suggestion is good. Launch windbg and process monitor and check dbghelp.dll path used by windbg – Rahul Sundar Sep 27 '16 at 12:16
  • 1
    Another good suggestion. Looking at the processmonitor output, windbg.exe makes a lot of calls to the registry, it will take a long time to analyze for anything suspicious. But anyway, the only direct mention of dbghelp.dll is during startup and it's the same folder as windbg (c:\program files (x86)\Windows Kits\Debuggers\x86\dbghelp.dll) Same is true for dbgeng.dll – Mijin Sep 28 '16 at 06:46
  • Just as an update, debugging all the processMonitor output I still didn't find anything helpful. As previously mentioned, the only references to dbgHelp and dbgEng are using the correct files from the same folder as windbg. So I can no longer use this PC for debugging memory dumps :( – Mijin Oct 07 '16 at 12:10
  • Update: Well nothing anyone suggested managed to "un-brick" my install of WinDbg. However, I installed the latest WinDbg 10.0.15063.137 to a fresh folder (indeed a different disk drive), and it just worked. I am not going to load my old workspace, as I have previously seen that that could put WinDbg in the same (permanent) broken state. – Mijin Jun 01 '17 at 06:44

0 Answers0