Profiler quits generating reports (or gets stuck on the same one)
I upgraded to Team System for Sd earlier this week from 2005 Pro in order to try out the profiler. I can get it ro run once or twice, and then it seems to quit.
In my solution, I have a class library (Rancher) and console app (Rancher.Test). I used the Performance Wizard to create a session for the console app, and then added the class library as a target project. Instrumentation, no allocation gathering. I ran it twice with no problem and got reports like these:
Pretty normal. I tried to run it a third time, it ran fine, but no report showed up in the Session window. Tried it several times in various configurations, deleted and recreated it, etc. No dice. Finally gave up. It says it runs fine, but the line "Collection file exited:" keeps giving me the same file name every time I run it.
Rebooted and tried it again today. Worked twice again and then quit after I tried adding a second session so I could track allocations. Deleted the second session, and modified the first session to do allocation. Nothing. Tried switching it back to the original, still nothing. Still running fine, though it still says it keeps exiting the same collection file. I looked in the directory and found the file it says it keeps exiting. What was strange was it had this format:
Now why the .Test moved to the end of the file name, I have no idea. Anyone else have any ideas on how to get this to work consistently?
As an additional comment, not having line level timing is a big disappointment. If you have a large function, just saying "This function is taking a long time" doesn't help nearly as much as saying "This function is taking a long time at this line" like the DevPartner profiler does.
[1902 byte] By [
Modian] at [2007-12-20]
I've tried rebooting and removing the Session and adding a new one but it still doesn't work. I get this as output every time (with a different process number):
Successfully attached to process: 1392
Exited from process: 1392
Collection file exited: C:\Projects\FitTrack2\RancherDB060415.Test.vsp
Profiler exited
===================== Profiling Complete =====================
If I open the vsp file manually in VS, it parses the file fine but can't resolve my projects' function names, even with the project directory defined in Tools - Options - Debugging - Symbols.
Thanks for the feedback, this is definitely not the desired user experience! Here are some troubleshooting type questions that might help us trace it down.
- Any chance the system is out of memory?
- Is the class library also set up in the performance session (maybe it is only profiling the test console app?).
- Are there previous VSP reports on the screen when it stops working? There were bugs fixed in the past related to multiple reports being shown at the same time, maybe this is a related issue.
- Is there anything left over from the software under test (resource leak, etc) that might leave the system in a different state on the third time around. Is there concurrency involved?
If we can get this boiled down into a consistent repro case, I'd love to get a bug logged and regression test added to our profiler test suite.
Eric Jarvi
http://blogs.msdn.com/ejarvi
- I have a gig of memory, and it's using 500 megs at most, even during the test run.
- Yes, the class library is setup in the performance session.
- No, I close the previous reports.
- I don't think so.
I just tried it again, and these are the steps:
- Create new performance session using the wizard.
- Select the console app as the project to be profiled.
- Select Instrumentation as the type of profiling
- Click finish
- In the Performance session window, right-click on Targets and choose Add Target Project.
- Right-click on the newly added target (the class library) and deselect Set as Launch.
- Click Launch
- It runs the test, creates a new report and opens the report.
- Close the report, then click Launch again.
- Repeat twice. (I was able to run it fine 3 times)
- Open the performance session properties
- Check "Collect .NET object allocation information" and then check "Also collect lifetime information"
- Close the properties
- Launch
Now I get the error condition of it messing up the report name and not opening it anymore. It always seems to coincide with me switching the profiler to collect allocation information instead of collecting time.
I created a test solution on my machine which gives me the same error if I follow the steps I outlined above. Here's what I did:
- Create a new Blank Solution.
- Add a new class library project called TestLibrary..
- Add a method to Class1 called Test. Within Test add the following code:
string s = string.Empty;
for(int i = 0; i < 10000; ++i)
s += s;
- Add a new Console project called TestLibrary.Test.
- Add a reference to the class library to the console project.
- Within Program.Main, add the following code:
TestLibrary.Class1 c = new TestLibrary.Class1();
c.Test();
- Next do the steps I outlined above.
When I did this, it ran successfully twice. Then I switched it to collect object allocation and got the below output:
C:\Projects\TestProfilerBug\TestLibrary\obj\Debug\TestLibrary.dll
C:\Projects\TestProfilerBug\TestLibrary.Test\obj\Debug\TestLibrary.Test.exe
Profiler started
Instrumenting C:\Projects\TestProfilerBug\TestLibrary.Test\obj\Debug\TestLibrary.Test.exe in place
Microsoft (R) VSInstr Post-Link Instrumentation 8.0.50727 x86
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
C:\Projects\TestProfilerBug\TestLibrary.Test\obj\Debug\TestLibrary.Test.exe --> C:\Projects\TestProfilerBug\TestLibrary.Test\obj\Debug\TestLibrary.Test.exe
Original file backed up to C:\Projects\TestProfilerBug\TestLibrary.Test\obj\Debug\TestLibrary.Test.exe.orig
Successfully instrumented file C:\Projects\TestProfilerBug\TestLibrary.Test\obj\Debug\TestLibrary.Test.exe.
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:\Projects\TestProfilerBug\TestLibrary\obj\Debug\TestLibrary.dll in place
Microsoft (R) VSInstr Post-Link Instrumentation 8.0.50727 x86
Copyright (C) Microsoft Corp. All rights reserved.
File to Process:
C:\Projects\TestProfilerBug\TestLibrary\obj\Debug\TestLibrary.dll --> C:\Projects\TestProfilerBug\TestLibrary\obj\Debug\TestLibrary.dll
Original file backed up to C:\Projects\TestProfilerBug\TestLibrary\obj\Debug\TestLibrary.dll.orig
Successfully instrumented file C:\Projects\TestProfilerBug\TestLibrary\obj\Debug\TestLibrary.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.
Successfully attached to process: 3372
Exited from process: 3372
Collection file exited: C:\Projects\TestProfilerBug\TestLibrary060419.Test.vsp
Profiler exited
===================== Profiling Complete =====================
Once again, it moved the .Test to the end and failed to open the report. Additional runs produced the same output.
One quick observation - it looks like the driver project has a '.' in the name, and that may be confusing the code that generates the output file name. Can remove the '.' and see if that helps? I'll try that when I get home.
One quick note I forgot to mention before. I was able to get it to load the symbols for the messed up report (I had put it in the wrong path in Options), but it was reporting the wrong function names. For instance, it said a custom Exception I had was creating 2000+ instances of strings and was calling 30 other functions. Pretty interesting considering a) the constructor is empty and b) it never gets called. I don't know if the report is getting corrupted as well as the file name, or if it was loading the wrong symbols. I had it pointing to the same directory as the projects it was profiling to get the symbols from.
I removed the '.' from the project name and assembly name and it ran the same. Once I removed the Performance Session and created a new one it's been working fine so far. Looks like that was the issue. Good deal. :)
