Crash bug in devenv.exe - WebTest Results Viewer - by Curtis K

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


5
0
Sign in
to vote
ID 584634 Comments
Status Closed Workarounds
Type Bug Repros 2
Opened 8/8/2010 10:37:42 PM
Access Restriction Public

Description

The webtest results viewer integrated in devenv.exe can crash when the very useful and seemingly innocent WebTest instance method AddCommentToResult() is used.

As outlined in the repro section, the easiest way to trigger this is with a declarative webtest that uses a WebTestPlugin to programmatically add a single comment to the webtest result at the beginning of the test, and which then calls two child tests.

A similar manifestation of this issue was reported here:  http://social.msdn.microsoft.com/forums/en-us/vstswebtest/thread/B47EED82-C230-4B67-8385-C07BB14F309B and had seemed to have been fixed, but clearly the underlying problem or a similar problem still exists.  The critical takeaway from that thread is that the issue is triggered by a combination of AddCommentToResult() and the presence of child tests.
Sign in to post a comment.
Posted by Microsoft on 10/4/2010 at 10:29 PM

We have looked at this and taken this up for SP1.

Internally we maintain the webtest results UI items in two dictionaries(of which one is simply maintained in sync with the other). When some comment is added to the webtest results view using AddCommentToResult() from a webtest plugin, then we are trying to put two result items in the same position (and this position in the webtest results view tree is the key for the dictionary of elements).

Thanks for reporting it. It's not clear this addresses a 'hang' though as flopstic reports. It's not clear from flopstic whether the 'hang' is related. Pl. post a separate bug for that with details as appropriate.

Neelesh
Load Test PM
Posted by esteban2800 on 9/23/2010 at 7:24 AM
Well, at first it appears to load up fast. After a while, I started having problems opening urls even withing Microsoft links. It just hangs there and nothing is displayed.
Posted by flopstic on 9/23/2010 at 4:52 AM
hello this is giving me alot of a problems using it with windows 7 my computer hung up and o lot of things but using it with windows xp is nice
Posted by Curtis K on 8/19/2010 at 1:12 PM
Hi again. I'm going to up the ante on this bug. It isn't limited to just the webtest results viewer - the crash seems able to foul up the load test engine as well.

I re-added several calls to AddCommentToResult() in a few places in my code and ran a load test. A few minutes into the load test, the results collection stopped cold (e.g. graphs stopped refreshing) while the load test kept on running. When the test reached its full duration, it kept right on running. I left it for many minutes and it remained "In Progress" the whole time. Trying to stop the test in Visual Studio had no effect. I had to shut down Visual Studio and bounce the Controller process to get the test to stop.

This seems like a repeat to the problem I talked about here: http://social.msdn.microsoft.com/Forums/en-US/vstswebtest/thread/5b2dbfd7-3f5a-464e-9065-3499fad62fea and could also be related to a similar problem discussed here: http://social.msdn.microsoft.com/Forums/en-US/vstswebtest/thread/29fa8f6a-7ce2-4575-8738-1ffb2a168165, neither of which were ever solved.

It appears that after the crash Visual Studio and the test controller (QTController or VSTestHost) are no longer in communication, since Visual Studio isn't getting any results and the test controller isn't listening to 'stop' requests from Visual Studio.

Should I raise a separate bug on this issue, or is this comment adequate? The evil bit pixies are probably going to prevent you from being able to duplicate this behaviour, but I'm sure it's got to be caused by the same issue as the original bug submission.
Posted by Curtis K on 8/9/2010 at 12:39 PM
Ok, I have uploaded the first of the two crash dump zips, and the second one is in progress. Both begin with "FeedbackID-566137" as directed.
Posted by Curtis K on 8/9/2010 at 10:18 AM
Hi - I attached a sample solution, did you try it? I just tried on another computer and got the same crash with that solution. I'm working on getting the crash dump now.
Posted by Microsoft on 8/9/2010 at 2:29 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.


Posted by Microsoft on 8/9/2010 at 2:19 AM
Thanks for reporting the issue.

In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

It may help if you provide us with a dump file

You can get the dump file with the following steps:

****************************************************************
Note: Please zip the file and use "FeedbackID-566137" as prefix of the file name

****************************************************************

1. Download the Debugging Tools from Windows from
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx and install. Assume that you copy it to
“C:\Debuggers”.

2. Open a command line prompt. Close all unnecessary applications.

3. Try to reproduce the problem.

4. Before VS IDE crashes , execute the following command at the command line prompt:

cscript C:\Debuggers\adplus.vbs -crash -FullOnFirst -pn devenv.exe –o C:\Dump

Dump file will be generated at “C:\Dump” and it usually takes several hundred MB. Make sure that you have sufficient disk space.

5. After VS IDE crash, please go to the folder “C:\Dump”. There can be multiple .DMP files. If their size are huge, please add the first .DMP file sorted by the timestamp (e.g. the first .DMP file captured) to a zip and upload it to the workspace:

https://sftus.one.microsoft.com/choosetransfer.aspx?key=26bf17bc-cad0-488c-b130-3c2b6eca387a

Password is %NE2QNqJT7#xFc

If we do not receive a response from you after 7-days , we will automatically close your issue. There is no obligation to respond -- at any time you may edit your issue via Connect and change the status to “Active.”

Thank you,
Microsoft Visual Studio Connect Support Team