Debugging multithreaded driver


I'm trying to follow a driver's trace but much too often an event on
other channel arrives and the trace gets messy and starts jumping back
and forth, rendering the trace completely unreadable.

My example is going through a heavy user add operation while a modify
user flows from the connected system. The trace goes back and forth
between the events and it's hard to tell apart query results and the
modify event.

Is there any way to automatically tell when it's hopping from one event
to the other?
Should I perhaps limit the driver to 1 thread anyways? Is that even
I thought about using the event-id but from what I've read so far it
doesn't look
too consistent and is more a "best effort" type.


YLivay's Profile:
View this thread:

Parents Reply
  • On 02.09.2013 12:44:02, YLivay Wrote:
    >EDIT: Ok, I took a look at it. Very basic but it get's it might get it
    >wrong in cases where
    >the IDM engine switches threads before printing an "untagged" message.

    From what I understood, it spits out the untagged messages into both
    files because it wasn't always possible to determine which channel the
    untagged messages belonged to.

    Definitely this could be improved on somewhat, is your splitting code
    also in perl?

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

  • The splitting code, like the rest of the util is C# and will output an
    HTML with some jQuery tricks to help navigate the page.
    Untagged lines are annoying. They can originate from both subscriber and
    publisher channel, custom shim implementations,
    remote loader etc and are not necessarily even on one of the channel
    threads. Ugghh...

    I have a short term solution and a long term for this.
    The short one is extremely naive and will fail with busy drivers but
    otherwise it's fine most of the time:
    Simply compare the line's time-stamps to see if it makes more sense to
    belong to the last transaction or the next one.

    The long one will be implemented after I've added more parsing
    capabilities and should be able to determine
    where the line goes by understanding the context.
    If i'm in the middle of a subscriber channel policy's action for
    example, I know that this line:

    [08/22/13 15:58:40.105]:Active Directory Driver :Remote Interface Driver: Received.

    makes no sense in the current context so I add it to the other channel.
    (Yes, that means i'll be implementing a "superficial" IDM engine

    Again, I know in advanced it probably won't be something extremely
    accurate and will not cover
    weird end cases, but it's for "casual" use and i'll be adding
    functionality as I go and learn more :)

    YLivay's Profile:
    View this thread: