Profiler is stuck doing only memory profiling on web applications no matter what I do

Question

Ok, I've never had this problem in my long history with the profiler, but it started last night and I've done everything including reboot and yet I continue to get only memory profiling. I was using Visual Studio when it started happening, but since then I've dropped down to command line just for my own sanity's sake and so I have total control... unfortunately it isn't helping.

Let's start by saying my assemblies are all instrumented and ready to go with vssintr. Next I fire off a vsperfaspnetcmd like this:

vsperfaspnetcmd /Trace /Output:d:\test.vsp http://localhost/MyApplication

This gives me the expected:

Microsoft (R) VSPerf ASP.NET Command, Version 10.0.0.0
Copyright (C) Microsoft Corporation. All rights reserved.

Configuring and attaching to ASP.NET process. Please wait.
Setting up profiling environment.
Modifying web.config.
Starting monitor.
Launching ASP.NET service.
Launching Internet Explorer.
The profiler is attached to ASP.net. Please run your application scenario now.

Press Enter to stop data collection...

While this is up, I bring up another console and check the exact status with vsperfcmd /status and I see it's definitely using TRACE collection:

Microsoft (R) VSPerf Command Version 10.0.40219 x64
Copyright (C) Microsoft Corp. All rights reserved.

Process and Thread Status
============================================================
Output File Name            : d:\foo.vsp
Collection mode             : TRACE
Maximum Processes           : 64
Maximum Threads             : 512
Number of Buffers           : 514
Size of Buffers             : 65536
============================================================
Maximum Number of Processes : 64
Number of Active Processes  : 1
Global Start/Stop Count     : 1
Global Suspend/Resume Count : 0
------------------------------------------------------------
 Process                    :  c:\windows\system32\inetsrv\w3wp.exe
 Process ID                 : 4084
 Num Threads                : 4
 Start/Stop Count           : 1
 Suspend/Resume Count       : 0
<TRIMMED FOR BREVITY>

So then I go do my testing in the app and hit enter in the console with the vsperaspnetcmd to stop data collection which gives me the expected:

Profiling now shut down. Report file "d:\foo.vsp" was generated.

Running VsPerfReport, packing symbols into the .VSP.

Shutting down profiling and restarting ASP.NET. Please wait.
Restarting w3wp.exe.

Now, if I go open up that VSP in Visual Studio, what I get is a Memory Profiling Report. WAT!?

I've done everything from deleting all my assemblies, to clearing out the temporary asp.net files dir, to rebooting. Nothing I do is getting the profiler to actually use the right kind of profiling I've selected... despite what it claims its doing. I'm positive I'm not looking at a stale report as I've deleted it and the report details change every time.

UPDATE:

It seems like it's isolated to this particular application that I'm profiling because I whipped together a quick console application and ran a profiling session against it and got the expected Intrumentation Profiling Report. There must be some kind of metadata stuck somewhere that I'm just not finding despite my attempts at clearing out all of the data.

UPDATE #2:

Ok, it's not just isolated to that one application. Profiling of any IIS web application is exhibiting this problem.

UPDATE #3:

So I broke out process explorer and checked the Environment variables for the w3wp.exe that is supposedly being setup with the trace profiling, but lo-and-behold it appears that it is being setup for memory profiling after all:

COR_ENABLE_PROFILING             1
COR_GC_PROFILING                 2
COR_INTERACTION_PROFILING    0
CORE_LINE_PROFILING                0

Looking up the process chain it appears the svchost.exe is also configured this way, although services.exe is simply configured with COR_ENABLE_PROFILING=1 and 0 for everything else. Still not entirely sure how to fix this, but going to try vsperfclrenv /globaloff.

Answer 1

https://skydrive.live.com/redir.aspx?cid=bb789f72272d4858&resid=BB789F72272D4858!1389&parid=BB789F72272D4858!1041

Then can you help me to open this report file under your Visual Studio 2010 to see if it is display as expected(Instrumentation Profiling Report) instead of the name you said - memory report?

This report file is generated by the my empty web project under Visual Studio 2010 with "Use Visual Studio Development Server"(since the IIS configuration also complex, and I'm not that aspect export, so I use the Visual Studio Development Server to avoid some server caused problems):

https://skydrive.live.com/redir.aspx?cid=bb789f72272d4858&resid=BB789F72272D4858!1390&parid=BB789F72272D4858!1041 

If your Visual Studio 2010 also cannot show you the correct report content, then I think you will need to try these options:

You need locate to the IDE folder then run these commands, or you can set path to the system environment.

The following path is the vs2010 in my system, and you can use this for reference.

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

 

Devenv.exe /SafeMode  Launches the IDE in safe mode loading minimal windows.

 

Devenv.exe /ResetSettings    Restores the IDE's default settings, optionally resets to the specified VSSettings file.

 

Devenv.exe /ResetAddin       Removes commands and command UI associated with the specified Add-in.

 

Devenv.exe /ResetSkipPkgs  Clears all SkipLoading tags added to VSPackages.

 

After these, you can create a new project in a new workspace to avoid if there’re any problems of the old workspace settings.

 

If this issue is also exists, then you need to reinstall the vs2010.

1. Uninstall vs2010.
2. Clean the registry and files on disk.

3. Install vs2010.
4. Create the new solution in a new workspace.

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us

Answer 2

Mike,

So... luckily I don't have to get that drastic. I did some serious sleuthing while profiling the process and I found that whenever the process was started up a new SID key would appear in HK_USERS. That particular SID entry's Environment key had COR_GC_PROFILING "stuck" at 2 for whatever. Therefore, regardless of everything that was being done/reported at runtime, it was always doing memory profiling. While this makes absolutely no sense to me, what I figured I'd do is edit this SID's COR_GC_PROFILING value using regedit. However, I'd stop profiling and that SID key would disappear from HK_USERS I wouldn't be able to edit it. So, what I did instead is: started profiling, waited for the SID to appear and edited the value before stopping profiling. Much to my surprise and happiness this worked and the next time I went to profile it actually performed instrumented CPU profiling.

Very strange and I'm sure there's a place where this SID's data was being stored when not running that might make this easier to fix without having to actually launch profiling, but I'm not sure where. Hopefully this will help you guys figure out the bug, be able to provide a hotfix or at least provide a KB article to explain how to fix it in the future.

Answer 3

First, thanks for your experience sharing! And I'm glad you make it work now.

But I should admit that I'm really not familiar with your this issue details, so could you help us to submit this issue to MS Connect web site, so if that web site exports ask for some details for this issue, you can explain your issue to them in detail.

Thanks!

---

Mike Zhang[MSFT]
MSDN Community Support | Feedback to us