Thread Closing Error on specfic machine.

System.NullRefe renceException: Object reference not set to an instance of an object.
at Cycle_Box.Cycle Box.CycleBox_Fo rmClosing(Objec t sender, FormClosingEven tArgs e)

I can make some suggestions.

• Assume that everything is broken, or at least not ideal.
• Presume that the user is going to provide data in a format or manner that you just didn't expect. If you use a textbox for a number, the user will type "One".
• Assume that hardware breaks in the middle of what you are doing, so you have to recover.
• Take a few extra lines of code to get standards like the boot drive, the number thousands seperator etc. Don't assume that you have a C: drive or that a comma is the separator because not everyone is in America.
• Check that files/folders exist, even if you just did a call to make it: You may not have permissions.
• Don't assume the harddrive has room for what you are doing: They do fill up. Usually right in the middle of you writing to your log file.
• Get used to placing breakpoints and walking through the code line by line. Double check EVERYTHING on every line. Keep the "Locals" and "Autos" windows open so you can see your values.
  • Put a breakpoint on line 1.
  • When the code stops there, walk through line by line with F-10.
  • Check the values of your assumptions.
• Stop. Breath. Relax. Then reason out the problem. Cut it down by sections or halves. "The value was good here, then at this method it wasn't. Where did it go between 'A' and 'B'?"
• Range check and validate values. Confirm that you didn't get a zero when you are only set to accept 1-10. Confirm your objects and values aren't null. Initialize them to a known default if possible. If a selection can be from 0-10, then initialize to -1: Now you have something to check for.

In the case of a null reference exception you know exactly where it happens because the compiler should break on that line. Just hover the mouse over the objects and the tooltip will show you the values. See which is null.

Now, if this doesn't happen on your test machine, but only in the real world...
A) VMware. A great product that lets you have virtual computers on your computer. You can test in a dozen different OS versions without a dozen different PCs. Best of all, it integrates with Visual Studio so you can have VS throw the project being debugged directly into VMware. You can use its remote debug feature to build in XP, yet debug in Win2k
B) In the method that is failing you need to add more robust value validation before running code. You can't assume things are not null.

Example:
Presumes that m_Undo must be good (not null)(actually exists)(not in use)(you have permissions)(do esn't time out when accessed). If that assumption fails so does the program, because you can't make anything from a file if the file is null. Get used to

validating data and assumptions in your code if you want it to be robust. For example:
It could be that your properties of 'closing' or 'cycling' are null... or the log. If the application is quiting maybe the log has already been disposed of by the time this form tries to close and wants to access it.

Try putting in more log entries to see how far it gets before failure

That's good advice and I do perform a great deal of data validation and checking for my log (all encapsulated in my Log class) and I do enough here (closing and cycling are both primative bools and I get a expression is always 'true' warning if I check it).

I found my error and it is really annoying. So when I would run the code on my development machine (and testing machine) I would always use the debug build configuration so I can use the debugger (or remote debugger). Then I would switch to release before I built my Setup and Deployment project. Because of this the release build of my actual code project was never created. It was instead including an old version that was built weeks ago (before I added the data validation). By building that project before my Setup project all my problems went away.

Thanks for you help though. If I would have had trouble figuring out the problem in the actual wrong could this would have been very helpful.

Umm... The debugger still works when you pick 'Release' build.

If you have precompile commands that are tied to 'Debug' they will execute when in debug versus when in 'release'.

I do almost all of my debugging on the 'release' build. I only go to 'debug' when I want the added thousand log entries to be written and lots of extra console comments. For example:

Oh I was not aware of that worked. Well I guess that's what I get for just assuming things about the language. Oh well, another error another lesson. Thanks for your help.