QTAgent32.exe crashes when running a unit test that calls itself - by Neil.Justice

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 465633 Comments
Status Closed Workarounds
Type Bug Repros 6
Opened 6/9/2009 8:34:10 AM
Access Restriction Public


QTAgent32.exe crashes when running a unit test that calls itself.

Here is a video showing this:

Sign in to post a comment.
Posted by Lorenzo Von Matterhorn on 8/15/2011 at 4:26 AM
I had the same issue running unit tests with WatiN. I seem to have found a simple solution to the problem, I haven't seen it since!
Within Visual Studio, click on 'Debug' -> 'Attach to Process...' and then select the QTAgent32.exe from the list and attach to it. Note that in the process list it may have a suffix, e.g mine was QTAgent32_35.exe.
Hope this helps anyone with a similar problem.
Posted by Ravi Chelikani on 8/2/2011 at 10:48 AM
Had the same issue with my unit tests and it turned out to be a recursion issue as well. I followed Rich257's post below.
Posted by Snortymcfly on 5/23/2011 at 11:27 AM
Having the same problem in the Coded UI Test as well
Posted by Holysmoke on 2/9/2011 at 6:04 AM
We are experiencing the same problem with Windows 7 32 bit with VS 2010 Ultimate.

It happens very frequent with loadtest. The LoadTest does not finish after the specified time and keeps saying generating report. When we close VS 2010, it says the test is proceeding.

So we kill this task manually QTAgent32 in TaskManager. But this time the IE loses all the settings of Proxy and proxy exceptions settings.

Every time this happens we have to fill up this Settings in IE and rerun the test.
Posted by Geneticlone on 6/30/2010 at 6:42 AM
Experiencing this issue, in Visual Studio 2010, Windows 7 64-bit. QTAgent32.exe crashes (without any recursion in code) after running numerous amounts of tests multiple times; The Processes' Memory builds up causing the computer, to either run slowly or until it crashes the computer.
Posted by Rich257 on 5/26/2010 at 8:11 AM
My unit tests did expose a recursion problem in the code under test, unfortunately I didn't realise this as the unit test failed because the agent process was stopped. The problem with the agent process obscures the fault in the code under test and therefore I would rate this as important to fix.

A partial workaround is to run the failing test in debug and the debugger should stop on StackOverflowException being unhandled. Now you know the problem and the location so you can fix the code under test.
Posted by mikecvelide on 4/7/2010 at 12:27 PM
This is actually a more general problem. QTAgent32.exe crashes anytime there is a StackOverflowException thrown. Our normal policy is to write a unit test replicating a bug before correcting it, I think that's fairly common. Unfortunately we can't do that in cases where a StackOverflowException is the problem we're trying to fix.
Posted by Microsoft on 6/17/2009 at 8:35 AM

We will look into fixing this for future products but currently not for this one. We plan to possibly revamp the threading model we use at which time we can take a look at this, but the work needed is too big to complete for the current version.

Visual Studio Product Team
Posted by Neil.Justice on 6/16/2009 at 5:38 PM
Hi Visual Studio team,

I had no real world scenario in mind when I filed this bug. I found this bug while engaging in bug testing.
Posted by Microsoft on 6/16/2009 at 1:18 PM

While we understand that we should try not to crash, is there a specific purpose to this particular repro? Is there a scenario that we should be trying to understand?

Visual Studio Product Team
Posted by Microsoft on 6/11/2009 at 2:18 AM
Thanks for your feedback.

We are escalating 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.