Visual Studio Performance Profiling - Class library symbols could not be found

Question

I'm trying to Instrument an ASP.NET web-application with Visual Studio 2012, .NET 4. The solution contains a web-application and a class library. The problem is I can't see step into the class library, I get a message stating:

Matching symbols could not be found. Choose the 'Symbol Settings...' link to add the symbol file location and then reload the report.

The output while profiling looks good though:

Preparing web server for profiling.
Profiling started.
Instrumenting C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\\bin\PerformanceTest.dll in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 11.0.50727 x86
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
   C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\bin\PerformanceTest.dll --> C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\bin\PerformanceTest.dll
Original file backed up to C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\bin\PerformanceTest.dll.orig
Successfully instrumented file C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\bin\PerformanceTest.dll.
Warning VSP2013: Instrumenting this image requires it to run as a 32-bit process.  The CLR header flags have been updated to reflect this.
Instrumenting C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\SomeLibrary\obj\Debug\SomeLibrary.dll in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 11.0.50727 x86
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
   C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\SomeLibrary\obj\Debug\SomeLibrary.dll --> C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\SomeLibrary\obj\Debug\SomeLibrary.dll
Original file backed up to C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\SomeLibrary\obj\Debug\SomeLibrary.dll.orig
Successfully instrumented file C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\SomeLibrary\obj\Debug\SomeLibrary.dll.
Warning VSP2013: Instrumenting this image requires it to run as a 32-bit process.  The CLR header flags have been updated to reflect this.
Launching web server with profiling.
Launching profilable project.
Warning VSP2355: Some Windows counters will not be collected.  Without this data, some performance rules may not fire.
Profiling process ID 68 (iisexpress).
Process ID 68 has exited.
Data written to C:\Users\kipusoep\Documents\InfoCaster\svn\instances\PerformanceTest\PerformanceTest_130801(1).vsp.
Profiling finished.
Loaded symbols for C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\0329cb19\89f716fc\App_Web_0slsprtu.dll.
Loaded symbols for C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\0329cb19\89f716fc\assembly\dl3\62c5c0d2\9777513f_ae8ece01\PerformanceTest.dll.
Profiling complete.

I notice the output doesn't state anything about the class library called 'SomeLibrary' at the end, where it says "Loaded symbols for".

Does anyone know why I can't instrument the class library?

Here's the VS solution: http://www.fileswap.com/dl/C9HPd8uEC/

Answer 1

As far as I can tell from your solution, the .dll that is being instrumented is in the class library's "obj" folder.

Now, this may just be me speaking when I should keep my mouth shut (because I have little insight into the Visual Studio profiler, and I have no idea why/if one would want to instrument "obj" binaries rather than "bin"), and therefore, I guess I'd better describe my train of thought:

VS is looking for the symbol files (the .instr.pdb file specifically) in the "ASP.NET Temporary Files" location, because that's where it loaded the class library dll from. It won't find it, though, because that file is created in obj\Debug in the class library project and not copied over to the web application's "bin" folder - so it never gets shadow copied to "ASP.NET Temporary Files" either.

Removing the targets from the Performance Explorer and selecting "Add Project Target", checking both projects, gives me exactly what you (and I) had before:

• PerformanceTest.dll in Web Application project's ...\bin\Debug
• SomeLibrary.dll in Class Library project's ...\obj\Debug

So apparently, this is how VS wants it to be, whether it works or not. It instruments the class library in obj\Debug, then forgets all about the newly generated symbols when starting the profiler.

But if, instead, I remove the "SomeLibrary.dll" target again, select "Add Target binary..." and manually pick the one in the web application's ...\bin\Debug... And then start profiling: The report looks about the same, but I can browse into "SomeLibrary" and I get this in the output:

Preparing web server for profiling.
Profiling started.
Instrumenting E:\...\PerformanceTest\\bin\PerformanceTest.dll in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 11.0.50727 x86
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
   E:\...\PerformanceTest\bin\PerformanceTest.dll -->
   E:\...\PerformanceTest\bin\PerformanceTest.dll
Original file backed up to E:\...\PerformanceTest\bin\PerformanceTest.dll.orig
Successfully instrumented file E:\...\PerformanceTest\bin\PerformanceTest.dll.
Warning VSP2013: Instrumenting this image requires it to run as a 
32-bit process. The CLR header flags have been updated to reflect this.
Instrumenting E:\...\PerformanceTest\bin\SomeLibrary.dll in place
Info VSP3049: Small functions will be excluded from instrumentation.
Microsoft (R) VSInstr Post-Link Instrumentation 11.0.50727 x86
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
   E:\...\PerformanceTest\bin\SomeLibrary.dll --> 
   E:\...\PerformanceTest\bin\SomeLibrary.dll
Original file backed up to E:\...\PerformanceTest\bin\SomeLibrary.dll.orig
Successfully instrumented file E:\...\PerformanceTest\bin\SomeLibrary.dll.
Warning VSP2013: Instrumenting this image requires it to run as a 
32-bit process. The CLR header flags have been updated to reflect this.
Launching web server with profiling.
Launching profilable project.
Profiling process ID 14652 (iisexpress).
Process ID 14652 has exited.
Data written to E:\...\PerformanceTest\PerformanceTest_130810(1).vsp.
Profiling finished.
Loaded symbols for 
   C:\...\App_Web_yzwcgfbx.dll.
Loaded symbols for 
   C:\...\assembly\dl3\928eb82e\75dbb6f1_5695ce01\PerformanceTest.dll.
Loaded symbols for 
   C:\...\assembly\dl3\6c0d460d\5208c7f1_5695ce01\SomeLibrary.dll.
Profiling complete.

Is this the correct way to fix it? Again, I have no idea. If not, there may be a way to get the profiler to look for symbols in the class library's obj folder when it doesn't find them where it expects to - or a way of copying the .instr.pdb file to the bin folder pre-profiling so that it gets included in the shadow copy to ASP.NET Temporary Files.

Answer 2

I had this problem in VS2014 with an exe which was built for "Any CPU" with "Prefer 32 bit" set, whereas the referenced libraries did not have "Prefer 32 bit" (ie. 32-bit exe, 64-bit libraries).

Changing the exe to not "prefer 32 bit" fixed the problem with symbols, I think it's because the libraries are modified to match the bitness of the exe (during instrumentation) and the symbols no longer match.

Answer 3

This solution worked for me:

http://www.brothersincode.com/post/Matching-symbols-could-not-be-found-Performance-Profiler.aspx

You could also try it the other way around, meaning removing your dll as it is and trying to put the one from bin cause that can might as well be the other way around.

Answer 4

I have successfully managed to profile my class library - but only from within a console application. I have not been able to profile the class library during an ASP.NET app performance profiling session.

Some assorted links - which alas didn't solve my problem, but may give you some leads:

• Run the Developer Command Prompt for VS2012
• Then you can use this to VSPerfReport <yourreport.vsp> /debugsympath to figure out where SomeLibrary.dll should be loaded from
• Troubleshooting tips http://msdn.microsoft.com/en-us/library/bb385766.aspx

Answer 5

The currently accepted answer helped me to get there, but I'll try to humbly give a little more straightforward instructions to those who are trying to accomplish exactly the same thing that I am, just in case I would save a couple of hard googling hours for somebody. I was unsuccessfully trying to profile a WCF service that uses external assemblies, which are loaded by reflection at runtime and have this service to be triggered by my custom client. I had 2 problems: my WCF service just didn't start at all during profiling session (but while debugging it would always do it), and then when it did for some reason - Visual Studio coulndn't load the symbols for external assemblies. So to get both things to work I needed to create an instrumentation performance session with the target set to my main WCF service along with the custom external assemblies and set the launch mode - Internet Explorer (otherwise the service wouldn't start). No exes or pointing to client from solution. Then I didn't start the profiler immediately, but modified it's properties in "Performance Explorer" window and added a binary of my custom client to the "Launch" tab to be launched 2-nd (right after the service inself). It also helped to have a proper "Service reference" right in the client (I don't really use it, I use shared assembly and generate channels using ChannelFactory) and launch the client in debug mode first (but without actually ever accessing a service). Maybe that's not the right way to do it, but it does the trick and I finally can profile my service after 2 days of googling - not very much docs available on this topic, and the accepted answer to this stackoverflow question is the best resource I found.

Answer 6

I'm using Visual Studio 2019 and stumbles the same issue while instrument profiling an ASP.NET web site.

Heavily inspired by the above JimmiTh solution, I added the [ProjectPath]/obj/Debug paths of the missing project to VS Options->Debugging->Symbols. After profiling again I could easily access the source code and get more accurate profiling diagnosis.