derekbruening
commented
9 years ago From bruen...@google.com on January 18, 2012 06:49:44
to update w/ more info: trying to load symsrv.dll in Dr. Memory via _NT_SYMBOL_PATH w/ "srv" w/o private libs results in: ASSERT win32/callback.c:5396 get_thread_private_dcontext()->whereami == WHERE_FCACHE
w/ private libs, looks like dbghelp calls LoadLibraryW and perhaps other routines that aren't redirected and thus are failing. I believe everything else worked fine (this is based on old notes) which is why I never documented this in drmem docs or forcefully removed "srv"
From bruen...@google.com on May 06, 2011 13:13:59
looks like SymInitialize can take an explicit path, or it will use the _NT_SYMBOL_PATH env var. but, looks like will ignore src* paths: need to use symsrv.dll for those to work. symsrv.dll is NOT in the DDK. symsrv.dll is listed in redist.txt just like dbghelp.dll.
to get dbghelp.dll symbol store support working in-process with the private loader, need to hook priv kernel32's GetModuleFileName. note that the symsrv dll goes and loads over 45 libraries so maybe we don't really want it in-process for most clients: xref sideline options ( issue #446 ).
drsyms today supports _NT_SYMBOL_PATH pointing at a local directory of cached files retrieved earlier (via windbg, e.g.)
there are also some issues with a license agreement when connecting to Microsoft's symbol server: symsrv pops up a dialog box and then stores a symserv.yes file to avoid it in the future.
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=450