System.Diagnostics.StackTrace future ?

[Guest]

The constructor new System.Diagnostics.StackTrace(System.Threading.Thread
targetThread, bool getSourceInformation) *requires* that the target thread be
suspended.
But System.Threading.Thread.Suspend (and .Resume) are currently labelled
Obsolete and the documentation states that they are scheduled to be removed
in a future version.

What is planned to avoid the upcoming uselessness of this StackTrace ctor?

Our suggestion would be another signature for the StackTrace constructor
which takes a boolean flag indicating that you want the stack trace even if
the thread is not suspended (implemented however they want, maybe by
suspending the thread internally). All you are assured is that the returned
stack trace was a true stack trace for the target thread *sometime* during
the StackTrace ctor call.

We are using this feature to perform statistical execution profiling of a
thread from within the application itself (using another thread of course).

 

[Steven Cheng[MSFT]]

Hi Keith,

From your description, you're looking for the recommended means to capture
stacktrace from a given thread (by using the StackTrace class) since the
Thread.Suspend/Resume methods are obsolete in .net framework 2.0, correct?

I've checked the document and it seem the obsolete of the Thread's
"Suspend/Resume" methods does cause the StackTrace's constuctor with a
given thread not work. Currently, I'll perform some further research and
look for some further resource on this to see whether we have any other
alternative means. I'll update you as soon as I get any new information.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

That is what we are looking to do and wanted to know what direction the
future holds... Thanks.

 

[Steven Cheng[MSFT]]

Hi Keith,

Yes, I'm also interested in this issue and currently also involving some
other framework engineers to discuss on this. I'll keep you update.

Thanks for your understanding.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hi Keith,

Just add a message you let you know that I'm still contacting some other
engineers on this issue and keep focus on this. I'll update you as soon as
possible.

Thanks for your understanding!

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hi Keith,

I've just got some further information on this problem. Here are some
comments from our dev team engineers:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
So far there's no safe way to do this - you have to suspend the thread, and
suspending the thread is an unsafe operation. It might get suspended
somewhere while it holds a particularly dangerous lock. When you try and
walk the stack you might need that lock and you'll hit a deadlock.

The only safe way would be to have the thread cooperate and grab its own
stack trace and hand it off to you. Or if you're just doing this for
diagnostic purposes you could suppress the warning on calling the obsolete
method and do it anyway - just make sure to cross your fingers and avoid
black cats, don't break any mirrors, etc¡­
In addition, I also recommend send this feedback to our product feedback
center(connect site):

http://connect.microsoft.com/feedback/default.aspx?SiteID=210

thus, our dev team can also get informed on this feedback.

Thank you for your understanding!

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hi Keith,

Do you have any further concerns on this or if you have any other questions
need help, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

I went to post on the connect.live site, and discovered someone else had
posted almost the exact same thing. I added our comments to that thread.

Thanks, Keith