Reputation: 14548
If I get a stack trace by using new StackFrame()
or new StackTrace()
, I can pass in 'true' to fNeedFileInfo
to get file and location info. This requires a PDB file to work.
My question is: how does the CLR look for the PDB file?
Our end users don't have PDB's locally, but they are available on a network share. Is it possible to tell the CLR where they are when it does the stack trace?
Upvotes: 3
Views: 595
Reputation: 29496
The CLR uses the DIA (Debug Interface Access) API to resolve source and line information. DIA respects the _NT_SYMBOL_PATH
environment variable when resolving symbols. You can specify multiple folders (local or network) or symbol servers. See here for the specific syntax.
Given this, you can use Environment.SetEnvironmentVariable
to set the symbol path for your process. For example...
Environment.SetEnvironmentVariable(
"_NT_SYMBOL_PATH",
@"\\local\symbol\share;srv*http://msdl.microsoft.com/download/symbols"
);
...specifies that you want to look for symbols in both your local network share as well as the public Microsoft symbol server. Note that looking for symbols over the network can really slow things down. This is probably not an issue if you're using StackTrace
, though.
Upvotes: 1
Reputation: 941635
The CLR uses a COM component to read .pdb files, diasymreader.dll, stored in the framework directory. Only the programmatic interface for this component is documented (ISymUnmanagedReader). Nothing in the MSDN library about any kind of configuration option. Nor does the CLR provide it with any.
Not promising. I do however see a registry key in the binary dump of the DLL. Looks like HKLM\Software\Microsoft\VisualStudio\MSPDB with a value named SymbolSearchPath. Sounds like a great match, give it a shot by adding this key and value with Regedit.exe. Make it a string, containing the name of the directory with the .pdb files.
Upvotes: 1