I have a program that is made up largely of plugins. An event gets raised from one, and others can handle the event. That generally works well, but sometimes it can be difficult to debug. If one of the plugins is out of date, it may be that VS can't show the code.

That seems to be what is happening in this case: An event gets raised, then everything freezes. I have tracked it down to the code waiting on a SQL call. The SQL call is very simple, and would normally return results almost instantly, but there's a deadlock that keeps the query from being processed. There are two possible causes for this, and both would be really easy to solve...so long as I could tell who was making that SQL call.

To be clear, I do know who is ultimately making the SQL call, but somebody is triggering a chain of events that leads to the SQL call, and it happens when a particular event is raised. This should then be simple. All I need to do is look at the stack trace. The stack trace shows a series of methods leading up to the SQL call, and it shows the event being raised, but between those two is [External Code].

That means that there is some part of my program that VS feels it can't identify, which is almost always because the latest version of the source code doesn't match the code in the dll that VS has loaded for it. This is annoying in a plugin system because there are some 30 plugin dlls, along with four or five that are directly referenced by the main program. One of those is the culprit, but which one?

The first thing I did was remove ALL the plugins that I could, which reduced the number down to five. Of those, four of them do not handle the event that triggers this cascade of events, so they seem unlikely to be candidates. The fifth is 'special'. For one thing, I know that I can see the code in that one, because it's the one that causes the event to be raised. It doesn't raise the event, but it causes the event to be raised, and it handles the event. I've stepped through to the point the event is raised, and I've had a breakpoint in the event handler. That breakpoint isn't reached.

Interestingly, there are several other plugins that would cause that event to be raised. I haven't tried ALL of them, but I've tried a couple, including one that is very similar to the one that causes the problem, and in every case, all is well. In fact, the plugin that causes the problem then handles the event just fine. I can step through the event handler for that plugin when some other plugin triggers the event, so not only does that plugin seem fine, but I know that VS can see it and will show me code from it.

So, what I'm looking for is this: Can anybody suggest any means to figure out what is behind that [External Code]? I've removed every plugin except the few I'm testing. I've rebuilt every dll referenced by the main program. I've gone hunting for anything in the remaining code that handles that event, and I've found nothing. If I could figure out who is handling that event, I believe I could solve it, but outside of the plugins, I have yet to find anybody who handles the event. So, I'm really looking for a means to figure out who is handling the event when the stack trace only shows me that somebody is, but not who that somebody is.