ANTS Performance Profiler 7

No .NET methods were profiled on web application

When profiling an ASP .NET web application, the following warning may be displayed when gathering the results:

No .NET methods have been profiled

There are four possible causes of this error:

  • IIS is caching the previous request for an ASP .NET page, so that no code needs to be executed to satisfy the request.
    Caching can be configured in a page directive, causing this behavior.
  • The profiler's core dll was not loaded into the application.
    When the .NET Execution Engine starts, it checks to see if a profiler is configured by examining the COR_PROFILER and COR_ENABLE_PROFILING environment variables. If they are not set for the IIS worker process, profiling will not take place.
  • An attempt was made to load the Core dll, but the wrong dll is registered, the registry is incorrect, or the dll file itself is corrupt or missing.
  • The profiler's Core dll loaded correctly, but encountered an error.

Verify that the .NET Execution Engine is loading

In this case, it's necessary to determine whether of not your application is executing managed .NET code in the runtime. This can be done by attaching a debugger or using a process monitoring tool such as Microsoft's Process Explorer.

If you notice that the ASP .NET worker process (aspnet_wp.exe or w3wp.exe) has loaded the mscorlib.dll or "mscorlib.ni.dll" files, the runtime should have executed managed code. To determine the process that needs to be checked on IIS 6 and 7, the iisapp.vbs (IIS 6) or appcmd.exe (IIS7) tools can be used to resolve an IIS application pool to a Windows Process ID.

If the runtime is not present in your worker process, the site may contain nothing but static HTML, traditional ASP, other scripting code such as PHP, or the page is cached by IIS. You can determine the latter by looking for the following at the top of your .aspx files:
<%@ OutputCache Duration="Seconds" %>

Verify that the process has a profiler configured

On IIS 6 and 7, the only way to check that a profiler will be attached to a worker process would be to examine the process environment variables for the COR_PROFILER and COR_ENABLE_PROFILING variables, again, using iisapp.vbs/appcmd.exe and Process Explorer as in the previous case.

IIS 5 is slightly more complicated. Because IIS 5 does not implement the IIS 6 Worker Process Isolation Model, it is necessary to work out the user who will launch the worker process (aspnet_wp.exe) and modify their user profile so that the above environment variables are set in the user environment. This way, any process launched by this user (default: ASPNET) will be profiled.

If the environment can't be modified, a different error message will be shown, so that possibility will not be discussed in this section. If the environment variables are incorrect, this would result in a "failed to cocreate profiler" error (see below). The remaining possibility is that the variables had been set in the wrong profile.

Because .NET supports the parallel installation of many runtime versions, it's important to ensure that you have chosen the correct .NET version in the web application profiling project wizard. The user who will run aspnet_wp.exe is specified in the .NET installation's machine.config file, under the processModel section. If, for instance, your web application is configured to run .NET 2.0, which is configured to run as "USERA" and you also have configured .NET 1.1 to run as "USERB", choosing .NET 1.1 will set the environment for "USERB" and the profiler will not be attached to your web application. Normally, ANTS will automatically detect the correct .NET version, but if the metabase is corrupt or no application is configured for your web app's virtual directory, the wrong user could be configured.

Verify that the Profiler Core is correctly registered

Rather than checking the registry, you can ensure the registration is correct by re-registering the Core dll. First, determine the location of the dll. In ANTS v3, it is in %programfiles%\Red Gate\ANTS Profiler 3\RedGate.Profiler.Core2.dll. In Performance Profiler 4, it is in %programfiles%\Red Gate\ANTS Profiler 4\ProfilerCore.dll. In Memory Profiler 4.0, it is at %programfiles%\Red Gate\ANTS Profiler 4\Memory\RedGate.Profiler.Core2.dll.

Open a command prompt, change the working directory to the folder containing the dll, and run
regsvr32 <name of dll>

If this is successful, then retry profiling. If not, you may need to reinstall ANTS Profiler because the dll is corrupt.

Verify that the dll is functioning correctly

If the Core dll does load successfully, it may have failed during initialization. When this happens, an entry is written into the Application event log, with the source shown as ".NET Runtime":

Failed to coCreate the profiler.


Note that incorrect environment variables or incorrect registry information can also cause the same event log entry to appear. In that case, re-registering the dll as above or checking that the COR_PROFILER environment variable is correctly set to the GUID corresponding to the dll would fix this.

[ANTS Profiler version 3.x]
Name: COR_PROFILER Value: {9AE7D44D-DE91-47cb-9ABA-84BCAA0E5F54}
[ANTS Performance Profiler version 4.x]
Name: COR_PROFILER Value: {A07CBDF0-B23B-4A96-A889-18E3C3004EB2}
[ANTS Memory Profiler version 4.x]
Name: COR_PROFILER Value: {4befac55-31fa-4cf0-84b7-327248147851}
[ANTS Memory Profiler version 5.x]
Name: COR_PROFILER Value: {D60F7519-2600-4865-8AC1-C621C9CE41A2}
[ANTS Performance Profiler 5.x]
Name: COR_PROFILER Value: {60E3DCF2-1A65-4a44-9F41-038582C8181C}

If the environment is set correctly and the "Core" is registered, the only way to find the cause of the problem would be to attach a debugger to the worker process. Since there is probably a bug in the dll at this point, the only reliable way of troubleshooting this would be to send a memory dump of the worker process to support@red-gate.com. Microsoft's DebugDiag can be used to create this dump file.

http://www.microsoft.com/downloads/details.aspx?familyid=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en >

If it is not necessary to use IIS as a platform to run your web application, it is much simpler and less error-prone to use the "'development web server" option to profile web applications. This application had shipped with .NET Framework 2.0 as a cut-down webserver to use for debugging purposes.


Didn't find what you were looking for?