Symbols for my own code not found due to "The calling thread must be STA, because many UI components require this."

[rasmushalland]

I want to view my sources with perfview's annotations. In the past it worked fine, but now it doesn't. The UI just seems to be trying to find the pdb. The log window contains the following snippet, which seems to indicate what the problem is, but not how to solve it:

Started: Fetching Source code for MyDll!Foo.Managers.Foo+<>c__DisplayClass100_1.<Bar>b__5(value class System.ValueTuple`3<value class Foo.Month,value class System.Nullable`1<value class Foo.Foo2>,value class Foo.Foo3>)
Maximum count for MyDll!Foo.Managers.Foo+<>c__DisplayClass100_1.<Bar>b__5(value class System.ValueTuple`3<value class Foo.Month,value class System.Nullable`1<value class Foo.Foo2>,value class Foo.Foo3>) = 199
GetSourceLine: Getting source line for code address index 00015AC1
GetSourceLine: address for code address is 7fff790ddabe module MyDll
GetSourceLine: Found JITTed method Foo.Managers.Foo+<>c__DisplayClass100_1.<Bar>b__5(value class System.ValueTuple`3<value class Foo.Month,value class System.Nullable`1<value class Foo.Foo2>,value class Foo.Foo3>), index 00005FAD token 60012ad
GetSourceLine: Found an il-to-native mapping MethodIdx 00005FAD Start 7fff790dd500 Len b6d
GetSourceLine: NativeOffset 5be ILOffset = 198
FindSymbolFilePath: *{ Locating PDB C:\Projects\MyApp\MyDll\obj\Debug\net48\MyDll.pdb GUID af916a23-0588-4677-8af2-6848c7b0dec9 Age 1 Version 
FindSymbolFilePath: Pdb is for DLL C:\Projects\MyApp\binbin\Debug\net48\Foo.UnitTests\MyDll.dll
FindSymbolFilePath: Checking relative to DLL path C:\Projects\MyApp\binbin\Debug\net48\Foo.UnitTests\MyDll.dll
FindSymbolFilePath: Aborting pdbMatch of C:\Projects\MyApp\binbin\Debug\net48\Foo.UnitTests\MyDll.pdb Exception thrown: The calling thread must be STA, because many UI components require this.
FindSymbolFilePath: Probed file location C:\Projects\MyApp\binbin\Debug\net48\Foo.UnitTests\symbols.pri\retail\dll\MyDll.pdb does not exist
FindSymbolFilePath: Probed file location C:\Projects\MyApp\binbin\Debug\net48\Foo.UnitTests\symbols\retail\dll\MyDll.pdb does not exist
FindSymbolFilePath: Aborting pdbMatch of C:\Projects\MyApp\MyDll\obj\Debug\net48\MyDll.pdb Exception thrown: The calling thread must be STA, because many UI components require this.
FindSymbolFilePath: Probed file location C:\tools\perfview\MyDll.pdb does not exist
FindSymbolFilePath: Probed file location MyDll.pdb does not exist
FindSymbolFilePath: Searching Symbol Server C:\Symbols.

See the line containing "The calling thread must be STA, because many UI components require this.". There is a pdb file at the path mentioned in the line.

FWIW, the assembly is for .net framework 4.8.

[cincuranet]

When you say In the past it worked fine, but now it doesn't., can you try to bisect in which version it started?

Can you create small repro, with folder structure, and share it? Just the trace file and PDB is enough.

[leonvandermeer]

As I suffer this same issue, I did some analysis:
After some experiments, I discovered that the issue occurs for pdb files not already in the symbol cache (usually C:\Users\redacted-username\AppData\Local\Temp\SymbolCache directory).

To perform a single test:
1 download a specific perfview version.
2 delete symbol cache contents (usually C:\Users\redacted-username\AppData\Local\Temp\SymbolCache directory)
3 Run perfview, do cpu analysis, ... Press Alt-D to show source.
Happy flow use-case:
4 'Security Check' dialog appears
5 Confirm the question, source code is shown
Failing use-case:
4 'Security Check' dialog does not appear
5 'Exception thrown: The calling thread must be STA, because many UI components require this.' found in perfview's log file

Result of bisect:
PerfView Version 3.1.26 NOK
PerfView Version 3.1.24 NOK
PerfView Version 3.1.23 OK
PerfView Version 3.1.22 Not tested
PerfView Version 3.1.21 OK

The dialog's source code. The dialog looks like this:
Title: Security Check
Message: Found redacted.pdb on your local machine. Do you want to use it?
Buttons: Yes No

Click here for a 'random' code change :-)

[brianrob]

@JeremyKuhne, is it possible that #2276 might have caused this?