[RESOLVED ..for the time being :D]Is .NET inherently flawed with RaiseEvents

I've made at least two fairly large apps, both of which have utterly failed. Why? They are both server applications, so it opens a new Socket thread, and some classe(s) for each session. So let's say that an event gets called - even an async event:

1. RaiseEvent MyEvent()
2. MyEvent() is raised on the host object...
3. AnotherSub() is called
4. AnotherSub() sets the object that just called the event to nothing
5. Normally, the "chain of events" ends here, but the object that called it was just terminated on step #4! The result...

"Thread (gibberish here) has exited with code 0" in debug window - a nice silent error that indicates something went horribly wrong, leaving me to guess at what.

So here's my question: Am I doing something other new people are doing (VB6 was always fine with this kind of stuff) wrong, or are my apps in need of serious overhall to avoid these "silent death" errors. It is endlessly annoying, and has killed all my large projects thus far!

edit: Oh yes, not only does the thread exit, but things "stop working" ... after the thread has died, it generally results in a lifeless program that no longer works until you restart it!

nothing's wrong with .net:)
you're probably doing something wrong. Multi-threading can be tricky

Stick a few breakpoints in that thread's code and then see how far it gets.

If you are allowing a variable to be set to Nothing from within an event handler for that variable then it is your code that is the issue. Errors can be tricky to debug in a multithreaded environment because Action1 does something that is fine at the time, but then Action2 fails because of it. The problem is that Action2 has no idea when or where Action1 occurred, so it can't give you any information about it. Breakpoints and MessageBoxes are your friends! Also are you using synchronization techniques like SyncLock blocks?

jmcilhinney, thanks for pointing out SyncLock! This appears to be a good solution to most of my troubles!

theres another one which I'm not sure what it's called in VB.NET
it's the fixed block in C#:D

I doubt that there is a VB equivalent to "fixed" given that it is related to pointers. Given that the fixed statement can only be used in an unsafe context, and relates to whether the GC can move an object in memory, it is probably not useful to most people in most situations.