Newbie question about MDBG sample  
Author Message
joepeer





PostPosted: Building Development and Diagnostic Tools for .Net, Newbie question about MDBG sample Top

Hi,

I'm trying to figure out how the Mdbg sample works so i tried to create a simple de**** handling breakpoints.

So this is a sample of my code:

public void Start(Projet proj)
{
_de****Mdbg = new MDbgEngine();

_de****Mdbg.Options.CreateProcessWithNewConsole = true;

//Fire event
OnDebugSessionStarted();

DebugModeFlag debugMode = DebugModeFlag.Debug;
// version should be v.2.0.50727
string debuggeeVer = CorDe****.GetDe****VersionFromFile(proj.OutputAssemblyName);

MDbgProcess p = _de****Mdbg.Processes.CreateLocalProcess(debuggeeVer);
p.DebugMode = debugMode;
p.CreateProcess(null, proj.OutputAssemblyName);

//Add breakpoint

_de****Mdbg.Processes.Active.Breakpoints.CreateBreakpoint(fileName, line);


p.Go().WaitOne();
OnLocationChange();
}

The process is launched, a console window appear but when I call p.Go().WaitOne(), the WaitHandle never get signaled. My application freezes because the thread is blocked at that point. The MDBGProcess doesn't receive any event from the CorProcess object like the OnBreakpoint event.

I tried figuring out what was missing by running the sample with the gui extension. In the Mdbg sample OnBreakPoint get signaled even though no breakpoint was added. The MdbgLocation is then set to the first line of code it can reach.

Thanks,

Joe



.NET Development6  
 
 
Mike Stall - MSFT





PostPosted: Building Development and Diagnostic Tools for .Net, Newbie question about MDBG sample Top

Your main thread needs to be MTA. This is very similar to a module-load sniffer example (see here http://www.hide-link.com/ ). See more about ICorDebug threading model here: http://www.hide-link.com/

That aside, things looks right to me. The key problem here is event dispatching, right The debuggee may not be generating debug events, or you may not be properly subsribed to them.

Event-dispatch with Mdbg is not ideal. Basically, ICorDebug dispatches managed debug events; but Mdbg has a layer on top of that which can sometimes get in the way. Perhaps the best way to diagnose these things is to just set a breakpoint right when MDbg gets the event.

Here's a basic overview:

  1. ICorDebug dispatches managed events via the ICorDebugManagedCallback interface. The de**** (Mdbg in this case), implements that callback interface to get events.
  2. MDbg implements the event callback via the ManagedCallback class defined in corapi\De****.cs. Thus all managed debug events first go through that class.
  3. That callback object just delegates everything to CorDe****.InternalFireEvent (using an enum to specify which type of event).
  4. That then delegates to Events on CorProcess.
  5. MDbgProcess subscribes to those events (see in MDbgProcess::InitDe****Callbacks in mdbgeng\process.cs). It's the MDbgProcess event handlers that may have extra goo that gets in the way.

The MdbgProcess handlers are probably auto-continuing the events for you. Try setting a breakpoint in InternalFireEvent in De****.cs. That should fire on every single debug event. You can then step though and see exactly what's happening.

I hope that helps!



 
 
joepeer





PostPosted: Building Development and Diagnostic Tools for .Net, Newbie question about MDBG sample Top

You were right. I was on a STA thread when it needs to be a MTA.

Thanks a lot!

Joe