VS2005 with R# 3.0 RC2 hang
While i switching between big C# solutions VS2005 hang. CPU usage is 98%
for the deveenv.exe
Last lines in log file:
5:13:49 PM.390: Thread:7: Caches2: Loaded in 951 msec
5:14:03 PM.495: Thread:5: Reloading schema 'D:\Program Files\Microsoft Visual
Studio 8\xml\Schemas\addinschema.xsd'.
5:14:29 PM.567: Thread:5: Reloading schema 'D:\Program Files\Microsoft Visual
Studio 8\xml\Schemas\adrotator.xsd'.
5:14:32 PM.579: Thread:1: OnWmActivate Active=0 Disposed=False.
5:14:39 PM.597: Thread:5: Reloading schema 'D:\Program Files\Microsoft Visual
Studio 8\xml\Schemas\adrotator1_0.xsd'.
Please sign in to leave a comment.
Hello Alexander,
could you please attach debugger to the hung devenv.exe process, capture
stack traces and post them here? Thanks.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
unfortunately i can't do this. ClrDebugger can't attach to process.
I try to minimize problem.
I start devenv.exe under dotTrace profiler with /Log command arg.
Attachment files:
"R# 3.0 - enabled.zip" - contains snaphots and logs while R# 3.0 was enabled.
"R# 3.0 - disabled.zip" - contains snaphots and log while R# 3.0 was disabled.
Test workflow:
1. Start profiling devenv.exe
2. Open Solution1.
3. Get snaphot and save as "Solution1_Opened"
4. Open Solution2.
5. Get snaphot and save as "Solution1_Opened"
6. Open Solution1.
7. Get snaphot and save as "SwitchFromSolution2ToSolution1"
PS
While R# was enabled i waiting 1 hour and close VS2005.
>
Attachment(s):
R# 3.0 - disabled.zip
Hello Alexander,
do I understand you correctly that hung has occurred after step 6 in your sequence? Unfortunately, I see nothing suspicious in the log you sent. It would be still very useful
if you could attach a debugger to the hung process. Could you please elaborate on the error you get while attaching a debugger? Thanks.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>
>> Hello Alexander,
>>
>> could you please attach debugger to the hung devenv.exe process,
>> capture stack traces and post them here? Thanks.
>>
In profiler snapshots you can see all needed information.
The compare view "Solution1_Opened" and "SwitchFromSolution2ToSolution1"
shows what the method OnLoadCompleted is slowly on 800% (3 424 753* ms).
When open method JetBrains.dotTrace.VSIntegration.Connect.QueryStatus in
new tab you can see what this methos take 75.43 % in method OnLoadCompleted
(1 717 783 ms of 2 277 196 ms)
Hello Alexander,
ok, now I see what you mean. Is the problem repeatable, e.g.. when you try
to repeat the workflow mentioned in your previous post,
is the second opening of the Solution 1 horribly slow? Thanks.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Hello Alexander,
>>
>> do I understand you correctly that hung has occurred after step 6 in
>> your sequence? Unfortunately, I see nothing suspicious in the log you
>> sent. It would be still very useful
>>
>> if you could attach a debugger to the hung process. Could you please
>> elaborate on the error you get while attaching a debugger? Thanks.
>>
100% repeatable. This problem reveals when VS have opened document(s) in
Form or User Control Designer.
Hello Alexander,
it looks like the problem is somehow related to dotTrace VS Integration.
What build / version of dotTrace you were using? Thanks.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Hello Alexander,
>>
>> ok, now I see what you mean. Is the problem repeatable, e.g.. when
>> you
>> try
>> to repeat the workflow mentioned in your previous post,
>> is the second opening of the Solution 1 horribly slow? Thanks.
This ploblem presents before dotTrace has been installed. I used dotTarce
3.0 build 305.60.
But in your snapshots most of time in the slow scenario is consumed by dotTrace
integration, if I'm not wrong. If you can post
snapshots with the same problem without dotTrace, it would be great.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> Hello Alexander,
>>
>> it looks like the problem is somehow related to dotTrace VS
>> Integration. What build / version of dotTrace you were using? Thanks.
>>
You are wrong. dotTrace consumed CPU time, but i selected "Sampling profiling"
for collect snapshots.
From dotTrace help:
Sampling profiling is a profiling method where profiler creates a dedicated
profiler thread which periodically stops all profilee threads and collects
their stacktraces. Basing on these stacktraces, sampling profiler builds
the call tree.
Generally, sampling profiling is much faster than tracing profiling (up to
30 times according to our tests). Such performance allows to use sampling
profiling to profile performance-sensitive interactive 3D graphics applications,
computer games, and so on.
Hello Alexander,
I see your point. Unfortunately, I can't figure out the cause of the delay
given these snapshots.
I've tried to repeat your experiment with two solution but haven't noticed
the problem. Is it peculiar to these particular solution or their
combination (i.e. does it still hapen if your replace one of the solution
or both of them)? Thanks.
Dmitry Shaporenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
>> But in your snapshots most of time in the slow scenario is consumed
>> by
>> dotTrace
>> integration, if I'm not wrong. If you can post
>> snapshots with the same problem without dotTrace, it would be great.