This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(204.8, 38%, 29%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EP%3C/text%3E%3C/svg%3E)
According to https://video2.skills-academy.com/en-us/windows/win32/api/dbghelp/nf-dbghelp-symfindfileinpathw
BOOL IMAGEAPI SymFindFileInPathW(
HANDLE hprocess,
PCWSTR SearchPath,
PCWSTR FileName,
PVOID id,
DWORD two,
DWORD three,
DWORD flags,
PWSTR FoundFile,
PFINDFILEINPATHCALLBACKW callback,
PVOID context
);
function should return matched pdb and dll when flag SYMOPT_EXACT_SYMBOLS is set through SymSetOption
I have been trying:
DWORD symOptions = SymGetOptions();
symOptions |= SYMOPT_EXACT_SYMBOLS;
symOptions |= SYMOPT_CASE_INSENSITIVE;
SymSetOptions(symOptions);
and despite of that first found record which comes through callback returns umatched record.
I tried version 6.3.9600.17336 and 6.2.9200.20512 and it still does not work.
Either documentation is incomplete or there is error in that function.
To reproduce problem you need local symbol store which several versions of one file
Hello @p_jaholkowski , I use GUID to find a specific PDB file but failed. I get all two files via callback instead of a specified one with SYMOPT_EXACT_SYMBOLS flag. Maybe the document needs more detailed information. Since you are trying to find a file of the specific version, could you show how do you set this version information for SymFindFileInPath?
It seems that when the local symbol store contains multiple versions that it is up to the callback function to select which of the enumerated PDBs is the correct one. If the callback does not return FALSE to stop the enumeration then SymFindFileInPath fails and sets the error code to 2. The SYMOPT_EXACT_SYMBOLS and SYMOPT_CASE_INSENSITIVE flags did not seem to come into play.
When multiple versions in the local store were present SymFindFileInPath succeeded when called without passing a callback function but the PDB path it returned was the wrong one.
Update-
The behavior of SymFindFileInPath appears to depend on whether it can load symsrv.dll into the process. I tested by searching using a GUID for the same symbol file name as above that has multiple versions in the local store.
When symsrv.dll gets loaded the function finds the correct symbol file in all cases and the callback function only gets called once with the correct path. However, if symsrv.dll is not loaded then the function can return an incorrect path and the callback function enumerates all available versions.
So to obtain accurate results ensure that symsrv.dll can be loaded.
Make sure that dbghelp.dll is able to load symsrv.dll. Possibly copy both Dlls to the application folder or otherwise adjust the dynamic-link-library-search-order to ensure that symsrv.dll can be loaded.