2

I'm trying to set a break point on kernel32!LoadLibraryW or LoadLibraryA. I'm constantly getting:

Couldn't resolve error at 'kernel32!LoadLibraryW'

My symbol path is set to: srv*https://msdl.microsoft.com/download/symbols

Any ideas on how to fix that?

  • That's weird. It works for me in the Visual Studio debugger but not WinDBG. – Adrian McCarthy Feb 14 '17 at 17:18
  • It works for me in WinDbg 10.0.15003.1001 (both x86 and x64) on Windows 7. Which version and OS do you have? Are you sure that the Internet connection works? Try opening https://msdl.microsoft.com/download/symbols/pingme.txt in your browser and use the Network tools to see whether it returns HTTP 200. Try `!sym noisy` and `ld*`. What does the output of `lm m kernel*` show then? Try HTTP only if HTTPS does not work in the symbol path, – Thomas Weller Feb 14 '17 at 21:01
  • 1
    You can find it using x wildcardasteriskhere!load*w and copypaste the symname like bu/bp paste "cond if needed" – blabb Feb 15 '17 at 02:51
  • if you want to trace DLL image loads,use WPR with my profile (http://stackoverflow.com/a/30289933/1466046), it captures stacks of image load events for native and managed code. Open the ETL in WPA, load symbols and drag & drop the Images graph to analyze pane and extend the stack of the process which you want to trace. – magicandre1981 Feb 15 '17 at 17:21

2 Answers2

2

Set your breakpoint in kernelbase.dll instead.

Steve Johnson
  • 2,958
  • 13
  • 15
0

I believe WinDbg uses the symbol name and not the exported function name when resolving the address. This causes issues for some of the functions that are forwarded to ntdll.dll and kernelbase.dll.

Sometimes you can append "Stub" to the function name when setting a breakpoint and sometimes you just have to know that the function is actually implemented in a lower-level .dll and set the breakpoint on the function in that .dll. You can also find it with tab-completion and a name like *!functionname*.

Anders
  • 97,548
  • 12
  • 110
  • 164