EventSourceException Message (not Thrown) During DataflowBlock.SendAsync RRS feed

  • Question

  • I'm chasing a very annoying problem.  I'm using TPL Dataflow ( with C# to create pipelines passing various classes. It's a "non-trivial" application. Mostly this is working fine. However I have one situation in which the VS2013 output window starts displaying long runs of:

    EventSourceException: No Free Buffers available from the operating system (e.g. event rate too fast)

    To my surprise, a Bing search for pieces of this message turn up nothing applicable except the MSDN entry for "EventSourceException".  It is important to note that, best as I can tell, no such exception is being thrown into my code.  VS2013 can't trap it, I don't deal with exception in that reporting manner, and it's not the style of message I'd generate if I did.  It appears to be a message output by some other component (TPL Dataflow?).

    Because I can't trap it, and the app is a non-trivial collection of TPL dataflow blocks bouncing between tasks, it's very difficult to be absolutely sure what action in my code is triggering it.  What I do know is there is one DataflowBlock.SendAsync operation that is magnitudes higher at the number of individual items it is posting into the DataflowBlock. If I let mostly everything else continue to run but shut down the postings into that one case, the messages go away.  Unfortunately it also means the timing for the rest of the pipeline changes dramatically, so this only "strongly suggests" that SendAsync is the source of the messages. It's not definitive.

    I'm also not clear whether the message is attempting to refer to events within my application (perhaps in the TPL Dataflow library), or it occurred to me later it might be "events" trying to be posted to the system event log.  I'm not a pro at filtering the system event log.  Not knowing which section of the log the events might be headed for, I'm not sure where to look for them.  I'm not sure if there is a way to find "recent events regardless of where they were posted."

    The DataflowBlock is supposed to be suspending the task when the buffer is full (4 item limit), and this same configuration appears to be working fine with other DataflowBlocks in the app.  So "event rate too fast" doesn't make sense if the block is supposed to be suspending when it's full.

    Using System.Diagnostics.Debug.WriteLine() before and/or after the SendAsync call ends up being sufficient to cause the error messages to go away.  So whatever timing change they cause solves the "problem".  Placing a Task.Yield() both before and after the SendSync does NOT cause the messages to go away.

    I'm wondering if anyone is familiar with this message and can advise what it applies to.  I can't even be positive it actually has to do directly with TPL Dataflow. There is only a strong suggestion that it is.  It could be simply the timing caused by the TPL Dataflow activity that is triggering it.

    -- kburgoyne

    Saturday, May 9, 2015 6:02 PM

All replies

  • After way too much research time, this "seems" to be related to Event Tracing for Windows (ETW) and tracing calls baked into the .NET framework. Particularly for TPL activity.  Best guess is all the async activity without any processing pauses in the app is overrunning ETW buffers.  Presumably the typical .NET application regularly reaching an idle state and waiting on the UI allows ETW to flush its buffers, but my app is primarily a data processing pipeline with no regularly used UI.

    There are a lot of fancy involved blog, etc, postings about ETW, but little in the way of very simple postings that discuss its "automatic use" by components like .NET and its impacts/side-effects.  I'd very much like to disable this activity in my app since it seems to be invoke heavily (in my case) and apparently is actually causing buffering and buffering processing rather than the tracing calls being quickly ignored when I'm not interested in the information.

    I can appreciate what .NET is trying to accomplish with its tracing, but apparently when no one is interested in the tracing info the tracing calls are not being "short circuited" early enough to minimize overhead.

    If anybody knows of a way to disable .NET task tracing via ETW for my app, I'd much appreciate the info.

    BTW... I'm now running Win8.1.  I had started the bulk of the development under Win7.  I don't "remember" these messages under Win7, but it's also VERY possible I had not been doing testing that would have produced the messages.  So I don't know if this "issue" is new as a result of running under Win8.1 now, or if I would have encountered it under Win7.

    -- kburgoyne

    Sunday, May 10, 2015 3:33 PM
  • Have you ever found a way around this? I'm experiencing the same issue after upgrading to Windows 10 from Windows 7 and running the application under VS debugger (see this stack overflow post and this msdn forum post).

    This problem does not exist while running without having the debugger attached to the process nor it did exist when I was running it on Windows 7.

    • Edited by milasch Friday, April 29, 2016 7:55 PM
    Friday, April 29, 2016 7:54 PM
  • I'm not sure if this is still a problem for the users here, but I saw a solution for this issue at:

    Hope this helps.

    Thursday, October 27, 2016 8:54 PM