Freigeben über

Getting answers to questions

  • Artikel

I've been getting a lot of individual questions (usually via the contact form) about random things I know very little about. Unfortunately, I can't provide everybody the answers I'd like. Lack of time is one thing. But also, I often just don't know the answer. Just because I happen to know some detail about the debugging architecture doesn't mean that I can accurately describe winform's threading model. I only wish!

When it comes to finding answers, here are some additional resources to consider:

1) For MDbg issues, you can email ClrMDbg at Microsoft dot com.
This is an email alias for Mdbg specific issues or feedback.

2) Use the forums!
Shawn talks more about using the forums. Here's a list of all the forums. The forums most related to the content I blog about are:

The forums are great because there's many knowledgeable people around who may be able to answer your question. They also have great RSS support, and so consider subscribing. And if you can answer questions, go on and chip in!
We were actually pondering whether we should start a forum for ICorDebug / MDbg / Profiler issues / etc. We're not sure there's enough interest to justify a forum. Any thoughts?

3) Use MSN Search:
Everybody probably already knows this, but search-engines are extremely valuable. Got an HRESULT you've never seen before? Want to see why an API is failing? Got a strange exception? Search it!

4) Check out other blogs:
There are tons of other CLR bloggers that provide info on other areas. These other blogs are gold mines of information in their area, including Reflection, Security, and the Loader.

5) Microsoft's official support site:
Microsoft has an official support site (https://support.microsoft.com/ ) with more information and contacts for serious problems. Hopefully all of your issues are very simple and can be solved by a short post to a forum.

Comments

  • Anonymous
    March 29, 2006
    i have installed visual studio 2003 on my pc.
    but whenever i debug a form after adding controls to it. it gives system.arithmetic exception in drawing.dll file. but if i debug without adding any control then it debugs properly. So please Suggest me what to do?
  • Anonymous
    March 31, 2006
    Here's a question I simply cannot find any useful information about...

    I want to implement a feature in my debugger that allows it to honor the DebuggerBrowsable attribute on object properties.

    Typically my (simplified) debugger simply ignores and does not display private variables in variable watch windows, but in a very small set of cases I want to allow class developers to allow the debugger to display private variables.

    The problem is that IMetadataImport (and specifically IMetadataImport::EnumCustomAttributes) is probably in the top ten worst documented APIs :)

    I simply cannot come up with any useful information on how to determine if a property getter has the DebuggerBrowsable custom attribute defined, and everything I've tried has resulted in utter failure (reminds me of Edison, I know 1000 ways that don't work).

    Poring through the Mdbg code has also not yielded the usual gold mine of information :(

    Presumably others will want to know where to find this information as well, so I truly hope that you or someone you know will be able to provide links or info.
  • Anonymous
    April 02, 2006
    Well, I think I've figured out what I did wrong, but it's still true that the metadata api is quite poorly documented ;)

    As for whether there should be another forum for ICorDebug / MDbg / Profiler issues / etc, I would certainly love it.  I'm sure I'm not alone, though I doubt it'd be one of the busier forums.
  • Anonymous
    April 02, 2006
    Mdbg doesn't touch Custom Attributes.
    I'm curious, what was the problem? It may be nice to know in case others run into it...
  • Anonymous
    April 04, 2006
    Well, there were several, and I've still not got it completely ironed out, but I've made enough progress to get it basically working.

    [Forgive me if the class names don't match Mdbg anymore, I've changed the Mdbg codebase a great deal while learning from it]

    Firstly, I wasn't passing the correct metadata tokens for the [tk] and [tkType] parameters in the call to IMetadataImport::EnumCustomAttributes.  That was the easy part, even though the docs are a little ambigous they were mostly correct.

    Secondly, I was trying to create a "helper class" just to see if I could learn how to get the info without modifying otherwise solid classes, and as a result of my poor understanding of what lived where I was not looking in the proper scope for the information I needed.  In some cases I was even using the wrong symbol store altogether <grin>

    Here is a small C# snippet that enumerates a method's custom attributes that I put in my port of the MetatdataMethodInfo class.  If you have the correct baseImporter (which is a IMetadataImport) for your method and the correct m_MethodToken value, it works perfectly fine as far as I can tell ;)

    IntPtr hEnum = new IntPtr();
    try
    {

    while( true )
    {

    int mdCustomAttribute = 0;
    uint pcTokens = 0;
    baseImporter.EnumCustomAttributes(
    ref hEnum,
    m_methodToken,
    0,
    out mdCustomAttribute,
    1,
    out pcTokens
    );

    if( pcTokens == 0 )
    break;
    System.Diagnostics.Debug.WriteLine( string.Format( "Method {0} has custom attribute {1}", m_name, mdCustomAttribute ) );

    }

    }
    catch
    {
    }
    finally
    {
    this.baseImporter.CloseEnum( hEnum );
    }
  • Anonymous
    April 04, 2006
    Jim - I see.
    We've been wanting to add custom attribute support to Mdbg for a while. Sorry we hadn't gotten to it earlier.
  • Anonymous
    April 04, 2006
    Actually, it's Jonah not Jim ;)

    The fact that Mdbg is even available for us to poke around in and learn from is absolutely fantastic, and any shortcomings it might have are certainly forgivable in light of that I should think.