How to detect if one eventhandler is null or not

Event handler can not be null or not, because event handler is a piece of code, a method, anonymous or not. Only the instance of event handle can be null or not.

When you implement an event in your class in C#, it is easy to do and you always need to do this check:

public class MyEvenArguments : System.EventArgs { /*...*/ }

class MyEventTest {
    internal event EventHandler<myevenarguments< MyActionPerforming;
    internal event EventHandler<myevenarguments> MyActionPerformed;
    void MyAction() {
        if (MyActionPerforming != null)
            MyActionPerforming(this, new MyEvenArguments( /*...*/ ));
        //action
        if (MyActionPerformed != null)
            MyActionPerformed(this, new MyEvenArguments( /*...*/ ));
    } //MyAction
} //MyEventTest

However, outside of this class this check of impossible, even in the derived class:

class MyEventTestDerived : MyEventTest {
    void Test() {
        if (this.MyActionPerformed != 0) //will not compile!
            System.Console.WriteLine("set up");
    }
}

That's it. Checking up if the event instance is null is impossible outside the class declaring the event.
This is one of the main limitations of the event instances compared to delegate instances. Events are designed to use limited and safe usage patterns.

There are no situations where checking up of the event instance for null could be useful. The users of the class firing event never fire the event. They can add an event handler to the event instance but cannot check up if it was done or not. This is the important conception of the event-oriented architecture. The user of the class firing the event cannot fire event, they call some method firing the event directly or indirectly and get called a callback called event handler if it happens. If an event handler is called, it means the event instance in not null, if not — we never need to know. If you're trying to create some algorithm based on this knowledge, you're trying to abuse the technology. You should be thankful to the event-oriented techniques for keeping you out of the abuse.

If you explain to me the ultimate goal of your code, I will be able to explain you how the goal should be reached without the effect you need.

I want to add something else. The whole idea of adding and removing an event handler in response to UI event is a sign of bad design. In good design you never remove event handler and set all your event handlers in the very beginning of the run time. For example, Form Designer puts sets up all the method InitializeComponent simply called from the form constructor. I never use Designer for setting up events (and recommend everyone to avoid this by all means and set events in your own code), but I also call the code setting my events from the Form constructor or in some other single call which happens in the beginning of run-time if this is not a Forms UI.

When you need to disable effect of the event handler call, you simply need a Boolean flag skipping a call. When event if fired, first action of the handler is to test this flag and exit immediately. This flag(s) can be a field of your class using the events; and you have fool control over it. In this way, you never need to add an event handler more than once and never need to remove it. This is a simple and reliable discipline.

—SA