I assume you mean a "NullReferenceException".

If you are passing the DLL a null reference when you shouldn't be, then  
the answer is to stop doing that.

If your own code is in the call stack, but it's not being caused by an  
incorrect parameter you've passed, then you may want to wrap the call with  
a try/catch block.  It won't fix the error, but at least your own  
application can detect the problem and do its best to continue to exit  
normally.

If your own code is involved, you can look at the call stack window to see  
how you got to the caller, and what parameters you passed (including  
checking for null parameters that shouldn't be).  The disassembly screen  
isn't going to tell you much of anything useful.  That is, if you're good  
at debugging you might be able to, after some hours or days of effort,  
figure out what the DLL is trying to do when it gets the exception, but  
that's usually not going to lead to a different solution than just looking  
at your own use of the DLL (I have personally had exceptions to that  
general rule, but they are extremely rare).

But the disassembly of the DLL isn't the interesting part.  The  
interesting part is how you got there and what your code is doing at the  
time.  That information you should be able to get by looking at the call  
stack, and if your code shows up there, double-clicking on the stack frame  
you want to see and looking at the state of your own code.

Pete