Conversation

Seriously... why isn't it much easier to obtain a "good" copy of dbghelp.dll to use with procmon? I have no idea where I've got the copy of dbghelp.dll that was picked up by default under C:\Windows\System32, but it was clearly junk. So many hours wasted on borked call stacks 😠

Quote Tweet

Grzegorz Tworek

@0gtweet

Jun 8, 2022

You will see more if you configure your #SysInternal tools properly.

1. dbghelp.dll from WinDbg 2. symbols path

Show this thread

Marc-André Moreau

@awakecoding

Feb 12

Ok, maybe someone can explain why a copy of dbghelp.dll inside C:\Windows\System32 *with the same version* as the one shipped with Visual Studio has a slightly different size and was code signed on a different date, yet produces *VERY* different results in procmon?

namazso

@namazso

because that's what the documentation says: learn.microsoft.com/en-us/windows/ Maybe the extra few megabytes of code actually mattered at some point..

learn.microsoft.com

DbgHelp Versions - Win32 apps

The DbgHelp library is implemented by DbgHelp.dll.

11:58 PM · Feb 12, 2023

161

Views

So... where can I get the best copy of dbghelp.dll, aside from Visual Studio? The big red warning about using the Debugging tools for Windows is... scary? Also, I have a relatively up to date but broken dbghelp.dll in c:\Windows\System32 and I don't know what installed it

Marc-André Moreau

@awakecoding

Feb 13

In any case, I'm still not convinced that Process Monitor works correctly with either copy of dbghelp.dll on my system (Visual Studio or not). I had a few good stack traces and then it's been random junk for the rest of the day. This stuff is very unreliable