Visual Studio Profiler - "The process cannot access the file"

Question

Version: Visual Studio 2008SP1

OS: Windows Vista

I am trying to profile a mixed-mode assembly written in C++/CLI.

I'm trying to use "Instrumentation" profiling.

The assembly is delay-signed, and verification checking is disabled using SN in a post-build step.

I get this error message when trying to launch the profiling session:

[assembly path].dll has been signed.  Instrumenting will break verification.  Either turn off verification for this assembly or re-sign it in the post-instrumentation step. Press OK to attempt to profile anyway.

So I added verification skipping in the post-instrumentation step.

Then, when I try and run a profiling session, I get this error message

Error Error VSP1734 : File contains no data: [a path here]\e3090924(7).vsp

Output of the Performance window is as follows:

Successfully instrumented file [my assembly path].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.

Verification skipping

Microsoft (R) .NET Framework Strong Name Utility  Version 3.5.21022.8

Copyright (c) Microsoft Corporation.  All rights reserved.

Verification entry added for assembly '[my assembly name],8FC3CC631E44AD86'

The process cannot access the file '[my assembly path]r.dll' because it is being used by another process.

Collection file exited: [my collection file path]\e3090924(7).vsp

Profiler exited

Performance report [my collection file path]\e3090924(7).vsp contains no data.

PRF0025: No data was collected. 

The process cannot access the file '[my assembly path]' because it is being used by another process.

Using procmon.exe I can see that it's DEVENV.exe itself which has the file open and thus can't open it again.

Does anyone know how to get round this bug?

Answer 1

Let me ask few questions first:

What is the exact command are you using in post-instrumentation step?
Did you post the complete output from Output Window? (I undestand that you replaced the actual dll name)
Can you see how many handles DevEnv.exe has and what are they?

Answer 2

You can also try do the SN -vr step from outside VS *onyl once* for a binary (and remove that step in VS), and it will always skip verification after that.

Answer 3

I think I stopped getting the first warning message when I added a post instrumentation step to re-delay-sign the assembly, but I see what you mean about sn -Vr - once should be enough. (In the assembly's post-build step, the assembly is delay signed using sn -Vr.)

I believe that the text above was the full output, but I don't have time to re-run it right now to check this.

After I gave up on the VS profiler, I did have some success using the VsInstr/etc command-line tools, although the captured profiling data wasn't hugely useful, as most of the time was spent in functions with names like <Unknown> and names with Thunk in them - perhaps I need to instrument more dlls to get useful data.

One thing I wondered was how the Jetbrains profiler tool manages to work without any need to pre-process the assemblies as is needed with the MS profiler tools.

Answer 4

I also never had success with the post-instrumentation step integrated into IDE, and backed down to command-line.  I'm not quite sure why, my best guess is that sn.exe failed because my logon account is not local admin (and my app will not run properly under the local admin account).  I tried putting a sleep in the post-instrumentation step and running sn -Vr from another process, no success.

Seems like there is some room for a blog post on exactly what is this post-instrumentation step.  Is it just sn -Vr, or is there a procedure to re-sign with an actual key?

---

Jon

Answer 5

There are two ways to profile a strong-named assembly:
(1) Register the assembly for verification skipping: sn -Vr <assembly>. You only need to do this once outside of IDE, and you need amdin rights to do it.
(2) Re-sign the assembly: sn -R or sn -Rc. This should be put in the post-instrumentation step.

Answer 6

As far as I can tell, running "sn.exe -Vr" outside the IDE has no effect on the profiler running inside IDE -- the signed binary won't load inside IDE regardless of "sn -Vr".  There is vague talk above of using the post-instrumentation step, but no example of what this step would be.  Re-signing the assembly sounds promising, but you would need to do some steps regarding generating a new key _and registering it on the local machine_, I'm not confident exactly what to do there.

Like other posters, I have had to back down to command-line.  This works fine if you instrument and run the binaries on the machine where they were built.  However, if you instrument and/or run them elsewhere, you only get function addresses and no symbols.  Visual Studio Team System Profiling Tools FAQ contains procedures for using VSPerfReport to attach symbols to the .VSP file, but one key piece of information is missing.  Both the instrumented EXEs/DLLs and the corresponding *.instr.pdb files must be on the symbol path in order to VSPerfReport to successfully pack symbols into the VSP.  With that, I finally have data!

Thanks,

Jon