NGEN PDBs end up in symbol cache

[ryanmolden]

We analyze zipped ETL trace files which contain included NGEN pdbs in an automated pipeline. In order to give the location info of those NGEN pdbs to SymbolReader we use the source server style syntax of

SRV*<potential cache path>*<on file root of PDB extraction>

Since the PDBs are stored in the zip in a source server like directory structure, and we maintain that structure when we extract them, TraceEvent can locate them treating our local extraction root as if it were a source server (i.e. the path it would construct to do a source server lookup is the same path it needs to locate them on disk).

This is fine and well except it means it does the following for NGEN PDBs

1. Locates them on disk (good)
2. 'Downloads' them (not great but ok), this seems to mean copying them to some temp file with the extension .new
3. Copies them into our cache (bad)
4. Ultimately loads them from the cache

Step 2 is unnecessary since the PDBs are already on local disk in a loadable location. Step 3 is bad because it means PDBs that only will ever be used for this one analysis, end up in our machine's persistent symbol cache which stores things like OS and CLR dlls, which do make sense to store in a shareable location to be used amongst all analysis runs.

I am not sure the best solution. It seems either:

1. An 'extension' of the SRV syntax, something like LOCALSRV that indicates it uses symbol server style directory layout BUT it exists on local disk so you can skip step 2 and 3 above.

2. An additional argument to symbol reader, so we have the normal symbol server where we get all the global cacheable symbols like the OS and CLR bits, then we have another argument like localNGENPdbPath or something that tells the root to look for on local disk.

Either would seem to work, so it seems like a design decision I'd leave up to you folks.

[cincuranet]

I'm wondering whether simply using srv*<on file root of PDB extraction>*<another symbol location>*<location2...> would not work for you? That way the symsrv.dll first looks into <on file root of PDB extraction> and if found there uses it from there. If not, it would use <another symbol location> and if found, copy it to <on file root of PDB extraction> and so on. The leftmost location will be then the "cache" and rest will be fallback.