locked
Displaying memory locations in the Memory view with a custom debugger, what type of IDebugProperty2 do I return? RRS feed

  • Question

  • Hi all,

    I am working on a custom debug engine for Visual Studio for a new language. So far, so good, but now I am getting into supplemental features like viewing memory. When I pop up the memory view while in our custom debugger, I notice that it calls ParseText similar to how locals and watches are done.

    I parse the string and return an expression in exactly the same way that I do it with the watches. No matter what I seem to do, however, I get the message "Unable to evaluate expression" in the memory viewer. I feel like I need to set the bstrType to some sort of string for the viewer to recoginize that I have given it an actual address, but I cannot find much documentation on how to fill out these fields so that Visual Studio recoginzes them. I looked through the expression evalutor sample, but it was largely incomplete in this regard.

    The question is:

    How do I need to fill out the fields for a DebugProperty2 for the memory viewer to recoginze the value? (Techinically, I return an IDebugExpression2 interface, but all it does is return an  IDebugProperty2 when EvaluateSync is called).

    Thanks,

    -Dan

     

    Thursday, September 30, 2010 3:29 AM

Answers

  • Hi Dan,

    Sorry for the slow response on this. Implementing custom debug engines and expression evaluators is a bit of an arcane art, and I don't have the infrastructure set up that would allow me to attempt to replicate this particular scenario without a LOT of development time. Your best bet for issues like these is to open a paid support incident with Microsoft Developer Support, and perhaps provide a repro we can debug to try and determine what the root cause of the error is. There are a few options available to open said support incident.

    Alliance and Premier VSIP membership includes a complimentary MSDN subscription, which includes 4 professional support incidents. These can be used to initialize a support request with Microsoft's Customer Support Services. Some versions of Visual Studio include a number of free support incidents as well. See the "Technical Support Incidents" topic for details.

    Microsoft Customer Support Services, has a small team of support staff (including myself) dedicated to assisting customers with problems related to Visual Studio package development, Visual Studio Addin development, or just plain automating the IDE via the exposed COM interfaces. Internally, we're known as the "Visual Studio Extensibility Support Team". This team is primarily responsible for supporting the VS SDK, and fielding questions/problems related to extending or integrating with the VS .Net IDE.

    The VS SDK documentation has a topic entitled "Support and Other Resources" that can provide additional details on how to contact and open support incidents with the VS Extensibility Support Team.

    Sincerely,


    Ed Dore
    Friday, October 29, 2010 8:42 PM

All replies

  • Hi Dan,

    Sorry for the slow response on this. Implementing custom debug engines and expression evaluators is a bit of an arcane art, and I don't have the infrastructure set up that would allow me to attempt to replicate this particular scenario without a LOT of development time. Your best bet for issues like these is to open a paid support incident with Microsoft Developer Support, and perhaps provide a repro we can debug to try and determine what the root cause of the error is. There are a few options available to open said support incident.

    Alliance and Premier VSIP membership includes a complimentary MSDN subscription, which includes 4 professional support incidents. These can be used to initialize a support request with Microsoft's Customer Support Services. Some versions of Visual Studio include a number of free support incidents as well. See the "Technical Support Incidents" topic for details.

    Microsoft Customer Support Services, has a small team of support staff (including myself) dedicated to assisting customers with problems related to Visual Studio package development, Visual Studio Addin development, or just plain automating the IDE via the exposed COM interfaces. Internally, we're known as the "Visual Studio Extensibility Support Team". This team is primarily responsible for supporting the VS SDK, and fielding questions/problems related to extending or integrating with the VS .Net IDE.

    The VS SDK documentation has a topic entitled "Support and Other Resources" that can provide additional details on how to contact and open support incidents with the VS Extensibility Support Team.

    Sincerely,


    Ed Dore
    Friday, October 29, 2010 8:42 PM
  • Hi Ed,

    Yes, we are considering the VSIP option which gives us source to Visual Studio. However, being somewhat of a garage/on the side startup, we are trying to avoid major capital expendables, especially just to solve one particular problem. We have most things working, including expression evaluation (it works fine in the watch window).,  but there are a number of weird things (possibly Bugs) with Visual studio, too many to list here. The trouble here seems to be not the expression evaluator, but that the memory viewer doesn't know what to do with the value we've returned. 

    However, this particular issue is very easy to reproduce. If you join our Beta, you can simply run any Go program in the debugger and pop up the memory view to see the issue. Go (no pun intended) t to www.ergolang.com) I fall through any valid hex number back to the memory view, but it still doesn't like things. Am I supposed to actually evaluate the memory via something like ReadProcessMemory?

    Thanks,

    -Dan

    Thursday, November 11, 2010 3:41 AM