search

VerySleepy / verysleepy

Very Sleepy, a sampling CPU profiler for Windows
http://www.codersnotes.com/sleepy
GNU General Public License v2.0
1.05k stars 103 forks source link

Late symbol resolution doesn't work with SymSrv store #91

Open birdy-spb opened 2 years ago

birdy-spb commented 2 years ago

I tried to "Load symbols from minidump" for saved capture and got message in log: DBGHELP: symsrv.dll load failure I found with Procmon that sleepy.exe loads C:\Windows\System32\dbghelp.dll and tried to load C:\Windows\System32\symsrv.dll, but my system doesn't has it in C:\Windows\System32. According to https://docs.microsoft.com/en-us/windows/win32/debug/calling-the-dbghelp-library:

When using DbgHelp, the best strategy is to install a copy of the library from the Debugging Tools For Windows package in the application directory logically adjacent to the software that calls it. If Symbol Server and Source Server are also needed, then both SymSrv.dll and SrcSrv.dll must be installed in the same directory as DbgHelp.dll, as DbgHelp will only call these DLLs if they share the same directory with it. (Note that DbgHelp will not call these two DLLs from the standard search path.) This helps prevent the usage of mismatched DLLs; likewise, it also improves security overall.

It looks like I need to copy that dlls to "C:\Program Files\Very Sleepy", but SymSrv.dll is already there and some dlls like dbghelp*.dll. I tried to copy all that libraries from Windows SDK distributive with overwriting symsrv.dll and it solved the problem. But I'm not sure that's the right way.

CyberShadow commented 2 years ago

The minidump (and consequently symbols) are loaded via DbgEng, which probably loads DbgHelp in its own way. I don't know if we have any control over that.

birdy-spb commented 2 years ago

As I said - copying dbghelp to "C:\Program Files\Very Sleepy" solved the problem. I'm sure you can reproduce problem and solving.

CyberShadow commented 2 years ago

As I said - copying dbghelp to "C:\Program Files\Very Sleepy" solved the problem.

OK, but that's not a solution. We can't do that unless the process is running as administrator, nor should it modify the Program Files directory generally.

Maybe what would work is that instead of loading dbghelpms.dll, we first copy it to dbghelp.dll and load that. This will maybe make dbgeng.dll use this copy instead of the copy in system32.

I'm sure you can reproduce problem and solving.

Actually no as I don't use Windows for some time now. This project is in "help yourself" mode: if you can submit a pull request I can review and merge it (and people have been doing so until now), but unfortunately I don't have the capacity to research and fix bugs that are affecting others.