RP said:
Below is the code of ADFormula DLL:
[...snip...]
That's way too much code to post, especially for an issue like this.
You have a reference variable that is being used without it being
initialized to an actual reference. It still has its default value of null.
The debugger is generally very helpful in telling you what variable is
null, if you simply look at the line that generates the exception and
then check all of the values in the line. Having variable-less
references (eg a reference returned by a method) makes it harder; in
that case, it's often helpful to create variables to store the
references temporarily so that you can look at them more easily in the
debugger (if you look at the assembly, you can tell what's null
regardless, but this isn't always a useful suggestion for someone).
If the exception is actually happening within some other code that
you're calling, then the call stack will show that other code's stack
frame at the top, even if there's no symbols or source. Your own code
will show the green "call entered here" marker, rather than being
highlighted in yellow in this case. If that's happening, then it could
either be because you've passed in null for something that shouldn't be
(though typically methods will check parameters for null and throw an
argument-related exception if one is null), or there could be a bug in
the code you're calling (which you can do little about if it's code out
of your control...which would be the usual reason you don't have the
symbols or source for the code).
Basically, this is a really good opportunity for you to learn more about
how to track down null references in the debugger. In reality, these
are often the easiest thing to debug, because the immediate cause of the
problem is readily apparent, always. That is, whatever's null, it's
null at the exact moment that the code breaks when it's null. Figuring
out why it's null is not always so straightforward, but at least you
should be able to tell what's null.
Pete