Double whammy
Anyone who has passed a managed delegate as a parameter to an unmanaged function will be familiar with the oh-dear-the-GC-just-pulled-the-rug-from-under-me NullReferenceException you get if you don't keep save a reference to that delegate. It's hard to debug, but once you are aware of the problem you tend not to make the same mistake again. Or. So. I. Thought.
So I'm merrily hacking away with .Net 2.0, trying out the new flashy bits like generics and anonymous methods, when I tried out the new type-inference features in C#. Essentially this means that C# creates the delegate for you, and code like this:
button.Click += new ClickEventHandler(OnClick);
can be simplified like this:
button.Click += OnClick;
which is much nicer. It also means you can pass delegates to, you guessed it, unmanaged code without explicitly declaring a new delegate instance, and then spend a happy few hours debugging a stack-less NullReferenceException, safe in the knowledge that the problem can't be related to the delegate being garbage collected, because you'd never make that mistake again. In my defence, I was clearly drunk on syntactic sugar.
Which leads me to the second whammy: in 2.0, you don't always get a NullReferenceException in this situation. Sometimes, you get an AccessViolationException, which is a new type meant to help distinguish between null references and other types of AVs. Unfortunately, the CLR seems to be inconsistent about which one it chooses to throw (I was getting NRE on some runs and AVE on others) and led me to investigate the wrong flavour of bug.