Mdbg: Examining property values of objects. How? RRS feed

  • General discussion

  • I am trying to implement basic debugging functionality. Mdbg is a great starting point. Though what I found out is that it does not analyse the properties of the object being inspected but fields only (e.g. TryExpandNode). It is understandable: properties are not fields-like members but just decorated methods under the hood.

    Though it seems only logical to inspect both fields and properties. After all it is what Visual Studio does. I have managed to update the Mdbg Sample IMetadataImport  implementation and successfully call m_importer.GetPropertyProps(...

    Though I can only make use the returned property name and don't see how to invoke the getter (returned by GetPropertyProps) to evaluate the property value. All my attempts just failed.

    Any suggestion will be appreciated.



    • Edited by Oleg Shilo Tuesday, March 18, 2014 3:03 AM
    Tuesday, March 18, 2014 1:46 AM

All replies

  • Hi Oleg

    I haven't done a lot of research on this yet, but try this article: http://blogs.msdn.com/b/jmstall/archive/2005/11/15/funceval-rules.aspx, it should give you a good place to start.

    Have a look at the MDbg "funceval" command (mdbgCommands.cs:1794), it uses the ICorDebugEval interface, so you should be able to use/reuse this call to help you execute the getter calls. Obviously this isn't a trivial thing to do, good luck! :)



    Wednesday, March 19, 2014 8:16 AM
  • Thank you Greg,

    You are right. Indeed "Funceval" does the job. I have already implemented exploring the properties with it. Works just fine. It is a bit heavy in terms of performance but still OK. So properties are now covered.

    However I quickly find out that 'funceval' can easily dead lock. BTW it is exactly what the link you gave me was about. Thanks. I also completely appreciate now severity of funceval being 'unlished' (Func-eval is evil).

    To my surprise 'funceval' easily dead locks even if USER_UNSAFE_POINT and USER_STOPPED are respected. I do not have explanation for that...

    Anyway, I would like to ask you another question if you do not mind.

    What is the way of retrieving the exception info (e.g. Exception.Message) of the exception trown by the debuggee. Detecting the exception is not a problem as PostDebugEvent is quite suitable for this. Though I do not see CorExceptionEventArgs having any relevant info. Do I miss something? 

    Thank you again. It is not easy to find the answers on such a specific topic as MDbg. :o)


    Friday, March 28, 2014 12:50 PM
  • >...retrieving the exception info..

    Found it: 

    MDbgValue ex = shell.Debugger.Processes.Active.Threads.Active.CurrentException; string exception = ex.GetStringValue(0);

    And the rest of the Exception info in the fields of ex object.

    If I can only solve the funceval dead-lock problem this simple... :o)

    • Edited by Oleg Shilo Saturday, March 29, 2014 4:25 AM
    Saturday, March 29, 2014 4:24 AM
  • Yup, that's where I would have pointed you to :)

    If you need any other help just post a question here, I know how hard it can be to find information on mdbg/CorDebug and I try and check here pretty often.


    Saturday, March 29, 2014 9:09 AM
  • Thank you Greg,

    I appreciate your help. Indeed the information on mdbg/CorDebug is rare as gold.

    It is an interesting and challenging journey I am undertaking. I am extending my Notepad++ C# Intellisense plugin with the debugger functionality. I am already in a reasonably good position with respect to the number of features already implemented: CSScriptNpp on CodePlex. Though some features are more difficult to 'craft' than others.

    Thus I would like to use your kind offer and ask your advice with the following problem. I would like to allow automatic update of the local variables in the Witch window as Visual Studio does. This involves automatic invocation of 'funceval' after each execution 'logical' step (F10).

    I invoke 'funceval' from the shell.Debugger.Processes.Active.PostDebugEvent and if '!USER_UNSAFE_POINT && USER_STOPPED' as it is described in the article you referred to (http://blogs.msdn.com/b/jmstall/archive/2005/11/15/funceval-rules.aspx).

    However despite all my effort the system can I can still get deadlocked. Particularly easy if is 'setip' to the already executed code.

    Do you have any ideas that can help me to get through?  :o)


    Tuesday, April 1, 2014 5:33 AM
  • Just after posting I found mistake in the dbgThred.GetUserState analysis. Not sure if it affected the overall outcome. Will post update as soon as the mistake is fixed.


    Tuesday, April 1, 2014 11:01 AM
  • Hi Oleg

    I just started having a look around mdbg and something occurred to me: I was wondering whether the deadlock might be related to calling 'funceval' within the PostDebugEvent handler? I'm assuming you're hooking into the event when your step is complete? If not when the step is complete then when are you getting the PostDebugEvent? I see it can fire in quite a few situations (thread loads, exits, step complete, etc)

    I only just started looking, so I could be talking rubbish, but thought I'd mention it in the mean time while I carry on looking.


    Wednesday, April 2, 2014 9:41 AM
  • OK. All the problems are solved now.

    The following are my findings that can potentially help someone who is trying to use Mdbg sample (CLR Managed Debugger (mdbg) Sample 4.0) as a starting point for the Managed Debugging solutions.


    • The deadlock that the Mdbg exhibited was in fact a pseudo-deadlock caused by the inadequate exception handling in the Mdbg implementation:

      'MdbgProcess.StepImpl' can easily fail to retrieve the stepper (e.g. when hitting breakpoint). It is a valid situation but because of the absence of the error handling 'StepImpl'  may skip calling 'ReallyContinueProcess'. This in turn prevents resetting Kernel synchronization objects (Events) and in result we have an infinite waiting, which looks like a deadlock.  

      Simple try..catch completely solves the problem.

    • Detecting the safe conditions for 'funceval' is really tricky. Following the '!USER_UNSAFE_POINT && USER_STOPPED' recommendations (http://blogs.msdn.com/b/jmstall/archive/2005/11/15/funceval-rules.aspx) is not enough. For example I was not able to detect the safe conditions even once with a simple step by step debugging.

      Numerous experiments demonstrated that USER_NONE is also safe for 'funceval' and it is normally achieved just after the step completion.
    • Mdbg itself is a relying on COM a lot. When I tried to host the Mdbg code directly in Notepad++ it almost immediately brought down the host process. Mdbg is not a production code so one should be extremely cautious allowing Mdbg in his product codebase.

      In my case I host Mdbg in the additional external host process and communicate with the main process via Named Pipes.

    • Mdbg does not have any support for inspecting the object properties. It is just not implemented. Only empty method stamps with "throw new NotImplementedException()" 

      If you need this feature you will need to implement it by yourself. "Funceval" is your friend. The example can be found in my CSScript.Npp project.

    • Mdbg is great. But it is not of a production code quality level and it does only what it does. Any attempt to extend it's functionality can be potentially very effort costly.

      I have sprinkled the Mdbg codebase with some extra error handling. I also added support for the property inspection. The solution can be reused by anyone. 

      However because MS doesn't host Mdbg source on any public source control I have no way to push my changes back to the codebase. So I added the whole Mdbg source with the modifications as 'mdbg_Source.zip'  to the CSScript.Npp source code on CodePlex. 

    • Edited by Oleg Shilo Wednesday, April 9, 2014 11:52 AM
    Wednesday, April 9, 2014 11:51 AM
  • Hi,

    could you present some code to make property read possible in own code?

    Best regards,


    Sunday, December 31, 2017 11:32 AM