VerificationException only when profiling
JB47394
Posts: 5
Windows 7 x86
Visual Studio 2010
C#
Ants Performance Profiler 6.2.0.13 Standard
I'm looking for help in nailing down a problem that crops up only when I attempt to profile my application.
I have a C# console application. It had always run and profiled just fine until I brought a third party C# DLL into the build. My application continued to run without issues, but whenever I attempted to profile it I'd get a System.Security.VerificationException at the point where I attempt to create an instance of a class or struct from the third party DLL (the top level exception is a TypeInitializationException).
All assemblies are built for version 2.0 of the CLR. The third party DLL verifies type-safe with the 2.0 and 4.0 versions of peverify.
I tried some additional experiments with the third party DLL and found that
1. Creating an instance of a struct throws TypeInitialization and Verification exceptions. A parameterless struct constructor does not.
2. Assembly.LoadFile on the third party DLL does not throw an exception.
3. Calling a static method in the third party DLL does not throw an exception.
4. Accessing a const in the third party DLL does not throw an exception.
Per another post that I saw somewhere, I removed line-level profiling and that avoids the exception. But I lose line-level profiling.
The assemblies referenced by the third party DLL are 2.0.0.0 versions of
mscorlib
System
System.XML
I've been reading about security and such, and I've been poking and prodding the application from a variety of different angles, but because this is happening in the context of the profiler, I thought I'd ask for sage advice here.
Any help would be appreciated. I feel a bit naked without the ability to profile my code line by line.
Visual Studio 2010
C#
Ants Performance Profiler 6.2.0.13 Standard
I'm looking for help in nailing down a problem that crops up only when I attempt to profile my application.
I have a C# console application. It had always run and profiled just fine until I brought a third party C# DLL into the build. My application continued to run without issues, but whenever I attempted to profile it I'd get a System.Security.VerificationException at the point where I attempt to create an instance of a class or struct from the third party DLL (the top level exception is a TypeInitializationException).
All assemblies are built for version 2.0 of the CLR. The third party DLL verifies type-safe with the 2.0 and 4.0 versions of peverify.
I tried some additional experiments with the third party DLL and found that
1. Creating an instance of a struct throws TypeInitialization and Verification exceptions. A parameterless struct constructor does not.
2. Assembly.LoadFile on the third party DLL does not throw an exception.
3. Calling a static method in the third party DLL does not throw an exception.
4. Accessing a const in the third party DLL does not throw an exception.
Per another post that I saw somewhere, I removed line-level profiling and that avoids the exception. But I lose line-level profiling.
The assemblies referenced by the third party DLL are 2.0.0.0 versions of
mscorlib
System
System.XML
I've been reading about security and such, and I've been poking and prodding the application from a variety of different angles, but because this is happening in the context of the profiler, I thought I'd ask for sage advice here.
Any help would be appreciated. I feel a bit naked without the ability to profile my code line by line.
Comments
An easier option may be to change the app config file so the supportedRuntime is 2.0. I had a similar issue with ASP .NET here:
http://www.red-gate.com/MessageBoard/vi ... hp?t=11404
Everything I have is .NET 2.0, including the new DLL. Is there anything special that I can do with the profiler to get it to operate exclusively in that space? In the thread you linked, there's mention of something that can be done with a test web server, but I'm working with a console application. I can find no setting in the profiler user interface that suggests a solution.
I have another windows application that directly links to the third party DLL, and that profiles just fine. So I created a direct link from the console application to the third party DLL and now the console application profiles just fine. No actual calls to the third party DLL are needed; just the reference.
Do I need to stick with this workaround or is there some way for me to tell the profiler that this situation exists? Is there a particular usage pattern for dynamically loading assemblies that I should follow in order to make the profiler happy?
There were two (of four) assembly attributes that needed to be removed if the profiler was going to run.
[assembly: PermissionSet(SecurityAction.RequestOptional, Name = "Nothing")]
and
[assembly: FileIOPermission(SecurityAction.RequestOptional, Unrestricted = true)]
Once removed, the process ran normally while being profiled.
SecurityAction.RequestOptional is listed as being obsolete, but there are two other assembly attributes in the same DLLs that use obsolete SecurityActions that do not block the profiler:
[assembly: SecurityPermission(SecurityAction.RequestMinimum, Execution = true)]
and
[assembly: SecurityPermission(SecurityAction.RequestRefuse, UnmanagedCode = true)]
I haven't tried twiddling with this stuff because I don't have a clue what it does.
AFAIK it never used to be a problem before .NET 4 came out, though. I guess it's trying to map the old CASPOL scheme onto the new .NET 4 one and it's causing incompatibilities.