Hi Clifford,
Glad to hear that the full-fledged crash is an unusual event, although I would obviously like to make that an extremely rare occurrence.
'index out of range' is an extremely common error, and can theoretically happen any time a list or array is accessed via an index, which means that there are likely tens of thousands of potential sources for this exception in the code. These issues generally manifest themselves fairly quickly: this one was a typo/incomplete copy-paste edit that was introduced shortly before the drop and not caught, but was found and fixed quickly thereafter. Unfortunately, it happened before a release.
There is no way to get this specific error without sample population in the fact type, so you are likely seeing something entirely different if you're seeing this without sample population.
There are three classes of errors in NORMA:
Errors that happen during a model change. Each item that shows up on the undo list is a single model change. These all happen under a transacted object model, and the model will return to the exact state as before the change, then report the error. This type of bug (which I've found to be the most common, and includes this one) are the easiest to track because they can be immediately reproduced by replicating the change.
Errors that happen during playback of atom changes in a single model change. These happen during the initial change, undo, and redo and always occur after the model change has been committed. The general source of these errors is one of the tool windows. Note that years ago I added additional framework components to NORMA so that one error during events in one rogue tool window could not bring down the system. The result is that you get an error dialog after the transaction playback is complete, but the system does not crash.
Errors that happen during rendering of the diagram or one of the tool window states. These are generally the bugs that will lead to a crash, and are the hardest to reproduce because they can take the system down.
If you get a reproducible failure that does not crash the system, then you can easily attach a debugger and get a call stack. NORMA installs the .pdb files, so the call stack is generally readable. To do this (this looks long, but takes about 15 seconds the second time you do it. This should also be familiar for those who are developers as well as modelers). It is hard to verify these instructions on a machine with a development version of NORMA installed, so it would be nice if someone could check them out for me. I'll add these to the readme once they are verified.
Open a second instance of Visual Studio.
Choose the 'Attach to Process' command on the Tools menu (usually Ctrl-Alt-P).
Attach to the 'devenv.exe' instance that is hosting the NORMA designer. You can speed up the attach by only debugging managed code (a setting in the dialog).
Try to reproduce the bug. You may stop in the debugger at the point the error is thrown. If you don't, do the following:
Using the dialog from Tools/Options menu, choose the 'Debugger' category and uncheck the 'Just My Code' option, then choose OK to commit your options.
Open the Exceptions dialog from the Debug menu (usually Ctrl-Alt-E) and check the 'Thrown' column for the 'Common Language Runtime' category, then commit the dialog.
You should now stop somewhere in the code when you reproduce the bug.
You may be prompted for a source location when the debugger stops. You can either ignore this, or pull the source code onto your machine from sourceforge. This is easiest if you have SVN and/or TortoiseSVN installed. Make sure you get the right changeset (look at the readme.htm file installed with NORMA in the Documentation directory). If you click the 'Code' page from orm.sf.net you'll see instructions on how to get a read-only copy. This can take two or three minutes. This step is optional. Obviously, it is really nice to have an exact line in the code, and this is easy if you already have SVN on your machine, but I can almost always spot the problem from the callstack (next step).
Once the debugger is stopped, use the Debug/Windows/Call Stack menu to see the call stack.
If you see [External Code] in the list (this won't happen if 'Just my Code' is off), then right click in the dialog and choose 'Show External Code'
You can also make sure that all of the options at the bottom of the context menu are checked (Show Module Names through Show Byte Offsets) to get the most information.
With focus in the call stack tool window, Select All and Copy to get the callstack (Ctrl-A/Ctrl-C, or use the items on the context menu).
Get me the call stack.
Please note that not all exceptions that are thrown during are actual problems. In general, I try to minimize the number of thrown exceptions during normal processing cases, but that is not true for all of the VS components used by NORMA. Generally, if you attach a debugger after the .orm file is loaded then you will see very few 'false negative' exceptions, but you may see a ton during system startup and file load.
NORMA is a good-sized code base, with well over half a million lines of active code at this point (haven't counted in years, this is a low-ball number). Unfortunately, there is very little I can do with a general report (I occasionally have problems, I saw this error). If you're using the tool, please take the 5 minutes if you see a problem to get a call stack and/or reproduce the scenario. The bottom line is that I can't fix issue I don't know about and can't reproduce.
-Matt