Article # 1, added by Geoworks, historical record
| first | previous | index | next | last |

Swat "Death due to" and "Warning" message explanations


DS_SI_NOT_POINTING_TO_SPREADSHEET - ???

CANNOT_REMOTE_CALL_FROM_UI - cannot record a message from the system's
   UI thread.

ILLEGAL_SEGMENT - One of the segment registers references a block
   that is no longer valid.  Most likely, you have a pointer to a
   block that is no longer locked.  Commonly this occurs when a 
   message with a pointer parameter is sent with @send and the
   block that the pointer references is unlocked/freed before the
   sent message is handled.  (Thus the pointer is invalid.)

CANNOT_CALL_MEM_LOCK_ON_AN_OBJECT_BLOCK - This warning is caused by 
   calling MemLock on an object resource (which is a specialized
   type of memory block).  Note that this is a warning: it is up to
   you to decide whether the data being locked should be moved.

   This warning commonly occurs when one of your object's visMonikers
   is a gstring that references data via an optr (GR_DRAW_BITMAP_OPTR,
   GrDrawTextOptr, etc.) and that data is in the object resource rather
   than a data resource (which is read-only, lmem).  The memory manager
   can more efficiently access the data if it is in a data resource
   rather than the (writeable) object resource.

CANNOT_USE_DOUBLE_BYTE_CHARS_IN_THIS_VERSION - This error means an
   invalid character (something over FF hex) was passed to the routine
   (e.g., LocalUpcaseChar), but this verion of Geos doesn't support
   double byte characters.  The problem may be that the character is
   being sign extended because the high bit of the byte is set.

OBJ_DUPLICATE_BLOCK_NOT_DISCARDED - the resource to be duplicated is
   in memory.  To fix this, add "discard-only" to the resource
   declaration in the .gp file.

GRAPHICS_NO_FONT_FILES - occurs on startup if you don't have any
   files in your USERDATA/FONT directory.

VIS_TEXT_RANGE_END_BEFORE_START - the value for the end parameter is 
   smaller than the start parameter.  For GEOS SDK 2.0, this is because
   the C header file has the parameters listed backwards.  To fix this,
   simply swap the start and end parameters in the message call.

TEXT_STRING_CONTAINS_NULL
   The string length in MSG_VIS_TEXT_REPLACE_ALL_PTR includes the null-
   terminator in the string or the string data is corrupted.  If the
   string is null-terminated you may wish to pass zero as the string
   length.

TEXT_PARA_ATTR_RUN_NOT_AT_PARAGRAPH_BOUNDARY - the death error occurs
   when a paragraph run element is not at a paragraph boundary.  That
   is, the element's position is at a character other than a paragraph
   boundary. But I'm unsure why backspacing over a paragraph boundary
   would cause problems. The error-checking code should only be executed
   during editing operations or some other operation that causes the runs 
   to be updated.

   If you have not already done so, do "ec text high" to get more error
   checking help.  Also, use ptext just before you hit the backspace to
   see what the paragraph runs look like.

LINE_DOES_NOT_EXIST - This error occurs when a message tries to get line
   information (VTI_lines) from a text object that hasn't been built out
   yet (the text object isn't visible on the screen).  Make sure not to
   send messages like MSG_VIS_TEXT_CONVERT_OFFSET_TO_COORDINATE to a 
   newly created text object until it is build out.

VIS_TEXT_REACHED_LAST_REGION_WITHOUT_FINDING_NEEDED_COUNTS
   This is caused when the text object's internal data structures are
   getting is messed up and is not rippling data correctly.  The ISV
   is somehow messing up the text object's internal data structures.

TS_LOCK_TEXT_PTR_INVALID_RETURN_VALUE
   Your text object has gotten larger than 20K.   It may be that the system
   only checks to see if a text object has gotten too large when the user is
   entering characters, that it doesn't in general do something graceful,
   leaving it up to the calling app.

BAD_RELOCATION_CANNOT_FIND_VM_HANDLE - This can be cause by a library
   ldf or goh file being out of synch with the current library geode.
   Get new ldf and goh files.

VM_GAP_EXISTS_IN_FILE - It could be caused by an improperly-created VM file
   created by something external to GEOS.  Often, this is caused by a bug
   in the VM code itself.

FSIR_NOT_LOCKED_SHARED_BY_THIS_THREAD - trashing your stack, or attempting to
   call FSDUnlockInfoShared when you've not called FSDLockInfoShared...

CORRUPT_LINKAGE	- the handle (or chunk handle) of an object is zero.  The
   composite link is (therefore) corrupt.

EVAL_ILLEGAL_PARSER_TOKEN - the parsed token is not one of ParserTokenType.

ILLEGAL_RESOURCE - commonly caused by calling GeodeGetOptrNS in a single
   launchable app.

MUST_SET_CONTEXT_BEFORE_SENDING_UNDO_MESSAGES
   ISV must set the context with MSG_GEN_PROCESS_UNDO_SET_CONTEXT

VM_COMPRESS_HOSED
	we came to the last used block and found out that there are 
	more blocks on the assigned list.

LMEM_HEAP_SIZES_DONT_ADD_UP
	the size of all the chunks (as determined by 
	LMValidateSizes) does not add up to LMBH_blockSize
	(size of memory block containing chunks).

BAD_HEAP_SIZES
	The various heap/chunk sizes don't add up
	correctly. The offset to the heap start added
	to the sum of the chunk sizes doesn't match
	the value of blockSize (the stored size of the
	block).

UNFREE_CHUNK_ON_LIST
	Somehow a non-free chunk is part of the free
	list.

FREE_SPACE_WRONG
	The sum of the free-chunk sizes doesn't match
	the totalFree variable stored in the info.

HANDLES_MATCH
	Two handles refer to the same chunk.

HANDLE_OUT_OF_BOUNDS
	A reference to a handle which is outside the
	handle table has been made.

ADDR_OUT_OF_BOUNDS
	A reference to a chunk which is outside the
	heap has been made.

TAGS_DONT_MATCH
	The size/flags words at either end of a chunk
	do not match.

CHUNK_WITHOUT_HANDLE
	A non-free chunk has been found which doesn't
	have a handle associated with it.

HANDLE_TO_FREE
	A free chunk has been found that has a handle
	pointing at it.

ADJACENT_FREE_CHUNKS
	Two adjacent chunks are marked as free. This is
	a no-no. They should have been coalesced.

NOT_LMEM_HANDLE
	ECCheckLMemHandle* was called on a handle

GRAPHICS_BAD_FONT_PATH
  Either there are no fonts in USERDATA\FONT, the standard path set
  for fonts is pointing off to oblivion, or the right file system
  driver isn't downloaded. This last will only happen in the non-EC,
  as error checking code in the EC will catch the case otherwise.

NO_ONE_TO_SEND_SHUTDOWN_ACK_TO_ALAS
  Someone called SysShutdown(SST_CLEAN/SST_SUSPEND), passing cx==0, after the
  UI has exited, or before it started up.

Memory errors:

TOO_MANY_LOCKS
  A memory block may only have at most 254 locks placed on it, and you're
  on your 255th, or you're attempting to lock a fixed block. If the former,
  you're probably missing a MemUnlock for one of your MemLocks. If the
  latter, remember the tale of the person who told the doctor, "it hurts
  when I do this."

BAD_UNLOCK
  You are attempting to unlock an unlocked block.

CANNOT_CHANGE_OWNER
  You are attempting to change the owner of a non-sharable handle you do not
  own. Most likely, the handle whose ownership you think you're changing has
  long since been freed and re-used.

HANDLE_SHARING_ERROR
  You are attempting to lock down a memory block owned by another geode that
  isn't marked HF_SHARABLE. Either you've got the wrong handle (e.g. you're
  using a handle for a block you freed, which was recycled by the system),
  or you need to mark this block HF_SHARABLE.

ALLOC_ZERO
  You are not allowed to allocate a zero-sized block of memory. Allocate
  something HF_DISCARDED with a non-zero size if you just wish to reserve
  a memory handle for later use.

MEM_FREE_BLOCK_DATA_NOT_CC
  This error is trigged when ec +heapFree is enabled and indicates that
  something has written outside the bounds of one of its blocks into
  unallocated memory. The system fills free blocks with 0xcc bytes and
  regularly checks all free memory to make certain all the bytes remain
  0xcc. es:di-2 or es:di-1 is the first non-cc byte in the free block (the
  system checks for 0xcccc words, you see). What next? You should look at
  the data to see if they look like anything you might be creating (e.g. a
  recognizable text string), then look at blocks that fall just before the
  free block to see who allocated them and for what purpose, then take a
  look at the code that would be manipulating those blocks and see if they
  might scribble like this.

ECF_UNLOCK_MOVE_FAILED_SORRY
  This indicates that the memory being moved because of ECF_UNLOCK_MOVE being
  set was swapped out and could not be swapped back in again, due to an
  error declared by the swap driver.

MEM_REFERENCE_COUNT_NEVER_INITIALIZED

  MemIncRefCount was called on a block with a refCount of 0 - MemInitRefCount
  was never called on the block

FAKE_BLOCK_DOESNT_COVER_ENTIRE_NEW_HEAP_SEGMENT
  A swap driver is attempting to extend the heap with a segment that must
  already part of the heap, as the block that intersects the start of segment
  being added doesn't cover the entire extent of the segment being added.

OBJ_BAD_DEREF
  You called ObjDerefGen, ObjDeref1 or one of their friends but
  the master offset you are derefing does not have the master offset
  you are derefing.
  i.e. You are using the wrong deref routine.

SOMETHING_LEFT_ON_STACK_BEFORE_STACK_SPACE_RETURN
  You called ThreadRestoreStackSpace with something left on the stack that
  you pushed after calling ThreadBorrowStackSpace. This is a bozo no no.

THREAD_STACK_NOT_IN_LIST
  The list of thread stack blocks has been corrupted, possibly by someone
  calling HandleP on a geode's dgroup handle.

TIMER_BAD_YEAR
  TimerSetDateAndTime() was passed a year outside the range (1980-2099)

TIMER_BAD_MONTH
  TimerSetDateAndTime() was passed a month outside the range (1-12)

TIMER_BAD_DAY
  TimerSetDateAndTime() was passed a day outside the range (1-31)

TIMER_BAD_HOUR
  TimerSetDateAndTime() was passed an hour outside the range (0-23)

TIMER_BAD_MINUTE
  TimerSetDateAndTime() was passed a minute outside the range (0-59)

TIMER_BAD_SECOND
  TimerSetDateAndTime() was passed a second outside the range (0-59)

TIMER_MISSED
  There's a bug in the timer code such that a timer with a time-remaining
  of 0 was placed on the timer list. This should not happen. It's not
  your fault :)

LIBRARY_ENTRY_NUMBER_TOO_LARGE
  Calling ProcGetLibraryEntry with an exported-entry number larger than the
  number of entry points exported by the library (si holds requested number).

UNKNOWN_HANDLE_TYPE_IN_HANDLE_TABLE
  FreeGeodeBlocks is running through the handle table and has hit a handle
  that is not one of the known non-memory handles. The handle table has
  been scribbled on.

GRAPHICS_CANT_CREATE_ZERO_SIZED_BITMAP
  You can't pass zero width or height to GrCreateBitmap

GRAPHICS_PATTERN_CUSTOM_PATTERN_TOO_BIG
  The custom pattern (either a HatchPattern or Bitmap) is too large to be
  used. A 16K limit is enforced for custom patterns, as these are stored in
  the GState segment.

GRAPHICS_HATCH_PATTERN_DELTA_Y_CANT_BE_ZERO
  The HL_deltaY is defined to be in the rotated coordinate space of the hatch
  line (although the rotation may be zero), so it never makes sense to
  have a line that continually draws on top of itself.

GRAPHICS_MUST_PASS_OD_TO_CREATE_BITMAP
  You must pass a non-zero exposure OD to GrCreateBitmap as the object
  that will handle any MSG_META_EXPOSED messages caused by bitblts and the
  like within the bitmap.

GRAPHICS_BITMAP_ALREADY_COMPACTED
  GrCompactBitmap must be passed an uncompacted bitmap

GRAPHICS_BITMAP_MUST_BE_PACKBITS
  GrUncompactBitmap must be passed a compacted bitmap in the PackBits format

GRAPHICS_CANT_DO_THIS_WITH_COMPACTED_BITMAP
  Can't call GrClearBitmap or GrEditBitmap with a compacted bitmap.

GRAPHICS_BITMAP_SHOULDNT_BE_LOCKED
GRAPHICS_DEFINING_PATH_CANT_SET_DEFAULT_STATE
  You shouldn't be calling GrSetDefaultState while defining a path

GRAPHICS_UNBALANCED_SAVE_RESTORE_STATE
  There is an unbalanced GrSaveState/RestoreState pair.  Perhaps you are
  calling GrNewPage with saved states.

GRAPHICS_ILLEGAL_PAGE_END_COMMAND

GRAPHICS_ILLEGAL_PATH_TYPE
GRAPHICS_BITMAP_RESOLUTION_CANT_BE_ZERO
  The bitmap resolution stored in the complex bitmap structure is zero,
  an invalid value.  This may mean that the BMT_COMPLEX bit was set
  in the B_type field of the bitmap header when it shouldn't be.

GRAPHICS_SENTINEL_FOR_BITMAP_COMPRESSION_CORRUPTED
  The sentinel word stored at the end of the buffer used to compress
  a bitmap has been corrupted, indicating an internal error in
  GrCompactBitmap

GRAPHICS_BITMAP_COMPACTION_INTERNAL_ERROR
GRAPHICS_BITMAP_INTERNAL_ERROR
GRAPHICS_SENTINEL_FOR_BITMAP_BUFFER_CORRUPTED
  The sentinel word stored at the end of the buffer used for drawing
  complex bitmaps has been corrupted, indicating an internal error in
  either how the size of the buffer was calculated, or how someone is
  writing into the buffer.

GRAPHICS_POLYLINE_SPECIAL_SHOULDNT_HAVE_FAILED
  A call to CheckThinLine() indicated a fat line would be drawn, but
  PolylineSpecial returned that a thin line would actually suffice. The
  logic to determine a thin line must be the same in each of these routines.

	Font Manager errors

FONTMAN_FIND_OUTLINE_DATA_CALLED_WITH_BITMAP_FONT
  FontDrFindOutlineData() was called with a bitmap font.  It is
  intended for use by font drivers, and therefore should only
  be called for fonts that have outline font data available.

FONTMAN_BAD_ENUM_FLAG_PASSED_TO_IS_FONT_AVAIL
  GrCheckFontAvail() cannot alphabetize fonts.

FONTMAN_BAD_FONT_INFO_FOR_ADD_FONT
  GrAddFont() was called with a bogus FontInfo() entry.

FONTMAN_FONT_FILE_DELETED
  The font file was deleted between the time it was first used and
  the time the font manager attempted to reload a font from it.
  This probably indicates a bug in the font manager.

FONTMAN_COULDNT_OPEN_FONT_FILE
  The font file couldn't be opened to reload a font from it.
  This probably indicates a bug in the font manager.

FONTMAN_BAD_FONT_FILE_READ
  The file read of the font file failed.
  This probably indicates a trashed font file.

FONTMAN_FONT_DRIVER_NOT_FOUND
  The font driver for this font couldn't be found.
  Is the driver specified in the geos.ini file?
  Is the (correct version of) the driver in the SYSTEM\FONT directory?

FONTMAN_NEED_FEF_OUTLINES_OR_FEF_BITMAPS
  GrCheckFontAvail() and GrEnumFonts() need at least one of
  FEF_OUTLINES or FEF_BITMAPS set in the FontEnumFlags, otherwise no
  fonts will ever match.

FONT_INIT_NO_POINTSIZE_FOUND
  No pointsize could be found for the default font.  Something may
  be wrong with the file of the default font, such as a bad header.

FONT_INIT_IN_USE_CHUNK_NOT_EMPTY
  The FontsInUse chunk was not empty during initialization.  Something
  is probably wrong in GrInitDefaultFont() or GrInitFonts().

FONT_BAD_WEIGHT
  You should not use FontWeights in the range FW_ULTRA_LIGHT to FW_BLACK.
  These are provided for backwards compatibility only.

FONTMAN_FILE_CACHE_CORRUPTED
  The font file cache was somehow corrupted (eg. a font in the cache
  didn't exist, was listed in the cache twice, etc.)

WIN_INPUT_OBJ_MUST_BE_RUN_BY_SAME_THREAD_AS_GEODE_INPUT_OBJ
  This is an error that WinOpen generates if the passed "InputOD" & "owner"
  for geode are not compatible.  Any non-NULL InputOD passed must be run by
  the same thread as runs the owner-to-be's geode's input object, by default
  the geode's GenApplication object.  This is necessary not because of a
  kernel requirement, but because GenApplication expects to be able to call
  any InputOD of a window that it has received input for.

WIN_ERROR_MOVING_WINDOW_ALREADY_IN_BACK_TO_BACK
  A window or window layer, after being moved to the back, was found to have
  no siblings to its/their right before beingmoved.  Code earlier in the
  routine is supposed to have bailed out in this case with nothing to do.

WIN_BAD_ASSUMPTION
  Bad assumption internal to window system code

OBJ_FLUSH_INPUT_QUEUE_BAD_NEXT_STOP
  Result of default MetaClass handler for MSG_META_OBJ_FLUSH_INPUT_QUEUE being
  called with bogus ObjFlushInputQueueNextStop value

OBJ_ILLEGAL_REFERENCE_TO_DYING_OBJECT_BLOCK
  Object block being tested has had MSG_META_BLOCK_FREE or ObjFreeObjBlock
  called on, is no longer marked as "in use", & will be nuked from memory the
  moment the queues have finished being flushed.  The current operation being
  performed requires this NOT to be the case.  One example is "WinClose", which
  requires that the exposureObj & inputObj's not already be dying.  This can
  be corrected by first closing the window, or changing its inputObj or
  exposureObj to NULL, & THEN destroying the object, or object block.

  More in-depth info:  This error checking routine
  is called by the system when it is about to start another queue-flushing
  sequence to an object, to make sure that it's going to be around to be able
  to receive the message -- if the block's about to be freed within one
  queue flush, then the new flush doesn't stand any chance of being able to
  finish without crashing.

OWNER_CORE_BLOCK_NOT_LOCKED
  The kernel is unrelocating a handle and has found that the core block for
  the owner of the block being unrelocated is not, in fact, locked.

VM_FILE_MUST_BE_CLOSED_WITH_VM_CLOSE
  A geode tried to close a VM file by calling FileClose instead of VMClose.
  This often happens if a geode has a VM file open, and exits without closing
  it.

ATTEMPTED_TO_PERFORM_UNSUPPORTED_FUNCTION_BEFORE_APPROPRIATE_IFS_DRIVER_WAS_LOADED
  The proper file system driver for one of your PC's drives didn't get
  loaded.  Since the system::fs key in the INI file was not set, Geos
  polled the system to determine what drives are present and didn't 
  recognize the response it received.

  To fix this problem:

  If you're using MS-DOS 7 (Windows 95) or PC-DOS 7, add the following 
  line to the [system] category of the GEOS.INI file.
	fs = ms4.geo
  This will force the appropriate file system driver to be loaded.
  (For EC emulator, add "fs = ms4ec.geo" to the GEOSEC.INI file.)

  If you plan on reinstalling the target software and don't want to
  always have to update the INI file, you can do the following as a
  more permanent solution:

  For MS-DOS 7, you'll need to enter these three lines at the DOS
  prompt, then reboot the machine:
      CD\WINDOWS
      SETVER LOADER.EXE 6.3
      SETVER LOADEREC.EXE 6.3

  If you're using PC DOS 7, you'll need to make sure that this line
  is in your config.sys file:
      DEVICE=C:\DOS\SETVER.EXE
  then reboot your machine and enter this line at the DOS prompt:
      SETVER LOADER.EXE 6.3
      SETVER LOADEREC.EXE 6.3
  then reboot your machine again.

INVALID_FSDRIVER_OFFSET
  Called FSDUnregister with an offset that's not a registered FS driver, as
  returned by FSDRegister.

FSIR_MAY_NOT_BE_LOCKED
  FileGetDestinationDisk has been called with the FSInfoResource locked in
  some way. This can lead to deadlock, however, when the disk for a drive
  specifier is registered.

FSHOF_SET_FILE_NAME_PASSED_TO_SKELETON_DRIVER
  The skeleton filesystem driver has been told the name of a file opened
  before the other drivers were loaded. This means the file in question
  was opened on a drive for which the driver was not loaded. Likely you will
  die soon of some other error.

VM_READ_FILE_WORD_ERROR
  A call to VMFileReadWord() returned an error.  Given that this is simply
  doing a file pos, and then reading from a portion of the VM header which
  is assumed to exist, an error is a bad thing.  See Tony.

VM_ATTACH_BLOCK_CANNOT_BE_DETACHABLE
  A block that is passed to VMAttach must be NOT_DETACHABLE, so as to avoid
  confusing the application state file mechanism, which will expect to be
  able to save the block to the state file when the application is detached.

  The NOT_DETACHABLE attribute can be set in a .ui file with
  "start Resource, notDetachable" or in a .goc file with
  "@start Resource, notDetachable;"

VMEM_GENERIC_OBJECTS_CANNOT_BE_UPDATED_ASYNCHRONOUSLY
  The file whose handle is in BX has VMA_COMPACT_OBJ_BLOCK set without
  having VMA_SYNC_UPDATE set. This is illegal, as it implies that whenever
  a block containing generic objects is off-screen, it can be compacted,
  thereby losing all non-save-to-state vardata and other things that could
  well be vital to bringing the objects back on-screen.

CANNOT_TRUNCATE_MULTI_REFERENCED_VM_FILE
  Someone has called VMTruncateAndClose for a VM file that has been opened
  by more than one application. Since VMTruncateAndClose is an extremely
  destructive operation, rendering the VM file invalid, the kernel refuses
  to perform it unless it knows only one process is using the file.

DB_UNGROUP_NOT_LOCKED
  VMMarkUngroupAvail has been called passing the handle of a group block
  that's not locked. This is illegal, as the handle for the block could go
  away at any time... this is an internal error in the kernel DB code.

UNGROUPED_GROUP_MAY_NOT_BE_PASSED_AS_AN_EXPLICIT_GROUP
  DBAlloc was called passing a group in AX that is a member of the set of
  groups used to satisfy requests for DB_UNGROUPED allocations. For various
  reasons, this is against the rules. Use DB_UNGROUPED instead, or create
  your own group (if you need to have items end up in the same group, for
  some reason).

  ***** OBJECT ERRORS *****

BAD_REMOVE_CHILD
BAD_CLASS
  This error happens frequently when an object or object block is freed
  before a message in the queue destined for it is delivered.  Always use
  as high a level of object/block destruction mechanism as you can -- The
  highest object-level routine in the UI is MSG_GEN_DETROY, in vis,
  MSG_VIS_DESTROY.  Lower is MSG_META_OBJ_FREE, which first flushes queues
  after which a MSG_META_FINAL_OBJ_FREE is sent to the object.  The handlers
  for this last message are allowed to use ObjFreeChunk & LMemFree.  On the
  block side, once all objects within the block have been taken out of any
  tree they resided in, MSG_META_BLOCK_FREE & ObjFreeObjBlock are the high-
  level message/routine to use.  MSG_META_FINAL_BLOCK_FREE ends up being
  called only after the queues have been flushed out, which in turn is
  allowed to actually nuke the block.

LMEM_BAD_INSERT_OFFSET
  LMemInsertAt() was passed a bad offset.  The offset passed should
  be the offset from the start of the chunk you are inserting in.

LMEM_BAD_DELETE_OFFSET
  LMemDeleteAt() was passed a bad offset.  The offset passed should
  be the offset from the start of the chunk you are deleting in.

LMEM_BAD_DELETE_SIZE
  LMemDeleteAt() was passed a bad size.  The passed size to delete was
  larger than the existing chunk.

LMEM_BAD_DELETE_COMBINATION
  LMemDeleteAt() was passed a bad offset/size comibination.  The offset
  plus the size extends beyond the end of the chunk.

OBJ_BLOCK_BAD_IN_USE_COUNT
  Each object block contains an "in-use" count, which is stored in the
  ObjLMemBlockHeader (The field is OLMBH_inUseCount).   The count starts
  out as 0, indicating objects are not active, climbs during usage, & must
  return to 0 before the block may be destroyed.  If you've gotten this
  error, it is because the count went negative, or became far to large to
  be a reasonable value.  The most common cause of this is intercepting &
  not passing on to the superclass a method which inc/decs this count.

  So, which methods might these be?  The count is incremented each time
  an object becomes active in some new way in the system, & is decremented
  each time an object is no longer active in that way.  Currently, there
  are the following pairs:

	1) Incremented whenever a window is created for visible objects
	   having the VTF_IS_WINDOW bit, & decremented in the default
	   handler for MSG_META_WIN_DEAD.

	2) Inc in MSG_META_OBJ_FREE (sent when objects are being destroyed)/
	   Dec in MSG_META_FINAL_OBJ_FREE (sent out after queues interacting
	   with object have been cleared)

	3) New object classes are free to inc/dec this count as well, using
	   ObjIncInUseCount & ObjDecInUseCount, but must do so in pairs, or
	   this fatal error may be the result.

  Also -- note that if a decrement does not occur for each increment, then
  the count never reaches zero, resulting in the block never getting free/
  application never exiting.

OBJ_BAD_IN_USE_COUNT
  Indicates if in-use count has gone negative for this particular object (The
  EC code only keeps track of the in-use count on a per-object basis).  See
  above OBJ_BLOCK_BAD_IN_USE_COUNT for more info.

OBJ_BLOCK_BAD_INTERACTIBLE_COUNT
  Each object block contains an "interactible" count, which is stored in the
  ObjLMemBlockHeader (The field is OLMBH_interactibleCount).   The count
  starts out as 0, & becomes non-zero as objects in the block become visible,
  or need to have current status information reflected in their state.
  GenControl objects are not updated unless this value is non-zero.  This
  error occurs only if the value goes negative, which should never happen,
  as the count should only be changed by in/dec pairs.

  So, which methods might these be? Currently, there are the following pairs:

	1) Incremented whenever a window is created for visible objects having
	   the VTF_IS_WINDOW bit, & decremented in the default handler for
	   MSG_META_WIN_DEAD.

OBJ_BAD_INTERACTIBLE_COUNT
  Indicates if interactible count has gone negative for this particular
  object (The EC code only keeps track of the interactible count on a
  per-object basis).  See above OBJ_BLOCK_BAD_INTERACTIBLE_COUNT for
  more info.

OBJ_RELOCATION_TO_INVALID_LIBRARY_NUMBER
  The application is probably restoring from state and one of its libraries,
  or its libraries' libraries exports an object class an instance of which
  was saved to state, but now one of the libraries or libraries' libraries
  has changed what libraries it imports without having increased the
  protocol number, so the state file is invalid.

RELOCATION_TO_INVALID_LIBRARY_ROUTINE_NUMBER
  This can happen if you're using a library whose entry points in the .gp do
  not match the one your geode was compiled with (because it's too old, etc).

BAD_TABLE_SIZE_PASSED_TO_OBJ_VAR_SCAN_DATA
  The # of VarDataHandlers passed to ObjVarScanData is unreasonable (0, or
  very large)

BAD_SIZE_PASSED_TO_OBJ_VAR_ADD_DATA
  Size of extra data passed to ObjVarAddData is unreasonably large

CLASS_AT_DS_SI_MARKED_NEVER_SAVED_SO_WHY_AM_I_RELOCATING_OR_UNRELOCATING_IT_BUB?
  This death occurs if a class has been @classdecl'ed with the "neverSaved"
  flag but an object of that class is being saved to state.  To fix the
  problem, either mark the object "ignoreDirty" (so it doesn't save to state)
  or remove the "neverSaved" flag from the class declaration.

  Note that GenProcessClass subclasses should be marked neverSaved because
  process objects don't have any instance data thus they are never saved
  to state.

OBJ_SHUTDOWN_OR_DETACH_WHILE_OTHER_STILL_ACTIVE
  ObjInitDetach was called for an object while a previous MSG_META_DETACH
  or MSG_META_APP_SHUTDOWN was still active for the object, and the message
  passed to ObjInitDetach is different from when ObjInitDetach was first
  called for the object (e.g. a MSG_META_APP_SHUTDOWN was received before
  the object sent MSG_META_ACK back to the object that sent it a
  MSG_META_DETACH). You might also have trashed AX before calling
  ObjInitDetach, so it didn't receive the message number your object
  actually received.

FSD_LOADED_BUT_NOT_REGISTERED
  When restoring a disk handle, was able to find the core block for
  the IFS driver, but not its  FSDriver record. Likely the FSDriver
  chain has been corrupted.

SAVED_DISK_HAS_NO_DRIVE_SPECIFIER_FOR_DRIVE_NAME
  When trying to locate the drive for a saved disk handle, we
  were told the saved drive name, which should always be a name followed
  by a colon (aka a drive specifier), had no drive specifier. Either
  DiskSave screwed up or, more likely, the saved data have been corrupted
  by the application.

DRIVE_NOT_LOCKED_EXCLUSIVE
  You are attempting to release exclusive access on a drive that is
  marked as being locked for shared access.

INK_ENUM_EXCEEDED_END_OF_BUFFER
  We tried to terminate a line segment, but there were no points in the
  point buffer.

NUM_INK_POINTS_IS_ZERO
  We are sending ink off, and the # points is 0. This shouldn't happen.

INK_Y_COORD_IS_NEGATIVE
  Somehow, an ink point had a negative Y coord

CANNOT_DELETE_MORE_POINTS_THAN_EXIST
  For some strange reason, the code tried to delete more points from the
  input manager ink buffer than actually existed.

TOO_MANY_INK_POINTS
INK_DATA_EXCEEDED_BOUNDS_OF_BUFFER
  More ink points have been stored in the ink buffer than should be able
  to fit.

NO_INK_GSTATE
  MSG_IM_INK_REPLY was received but there was no inkGState for some reason

  One of the handlers for the ink collection finite state machine
  trashed AL...

  Indicates that the MSG_IM_INK_REPLY (with AX=TRUE) was received before
  any pointer window was set

IM_ERROR_BAD_PTR_IMAGE_VALUE
  Indicates that ImSetPtrImage was called with cx = 0, but dx was not set
  to a legal PtrImageValue.

IM_MEMLOCK_FAILURE
  Internal IM problem

IM_BAD_SETPTR_PARAMS
  Internal IM problem

IM_MONITOR_ALREADY_IN_MONITOR_CHAIN
  You have attempted to call ImAddMonitor passing a Monitor structure that
  is already in the monitor chain. You need to have called ImRemoveMonitor
  on the Monitor before you can add it back in again

GCN_BAD_USAGE_COUNT
  Result of NDBH_usageCount within a NotificationDataBlock having an
  abnormally large number in it.

  You passed both GCNLSF_RETURN_COUNT and GCNLSF_SET_STATUS to GCNListSend
  or GCNListSendToBlock, but the two are mutually exclusive, as the
  undisturbed status message handle is expected to be returned in cx.


GCN_UNRELOCATING_GCN_LIST_WITH_UNOWNED_OPTR
  Cannot unrelocate a GCN list with optrs that are owned by someone other
  than the owner of the GCN list itself.

FSD_ES_ISNT_SHARED_FSIR
  A routine was expecting FSInfoResource to have been locked shared and
  its segment loaded into ES.

OVS_BAD_HANDLER_TABLE
  The pointer passed to ObjVarScanData does not point to a valid
  VarDataHandlerTable or VarDataCHandlerTable.

OVS_SIZE_OF_VAR_DATA_ENTRIES_GREATER_THAN_VAR_DATA_AREA
  The variable data storage area of the object has been corrupted -- the
  sum of the sizes of the individual entries exceeds the total size of the
  variable data storage area.

  One common cause of this is that a class definition in a library
  uih/goh file at the time the app was compiled no longer matches the
  structure of the class in the library found at runtime.  This can
  happen if instance data was added to a library class, but the major
  protocol of the library wasn't increased (e.g., you're using an new
  SDK, but an old application).

OVS_CORRUPTED_VAR_DATA_ENTRY
  The VDE_entrySize field was 0, which is illegal.  This field must
  be at least (size VDE_entrySize + size VDE_dataType).

OVS_VAR_DATA_HANDLER_CHANGED_DATA_ENTRY
  A VarDataHandler or VarDataCHandler has changed the data entry it is
  handling.  This is illegal.  A VarDataHandler or VarDataCHandler is not
  allowed to change the data entry or add or remove data entries.

  A data entry size of 0 or 2 was passed to ObjVarAddDataEntry.
  ObjVarAddDataEntry is only used to add a data type with extra data.  If a
  data type with no extra data is to be added, use ObjVarAddDataType.

OVS_BAD_MSG_META_INITIALIZE_VAR_DATA_HANDLER
  MSG_META_INITIALIZE_VAR_DATA has been called on an object to get a
  particular variable data type created & initialized, and ds:ax has NOT
  been returned, as is required, pointing to the extra data of the new
  data entry (Should match return value of ObjVarFindData for the given
  data type)

OVS_VAR_DATA_HANDLER_ADDED_OR_REMOVED_DATA_ENTRY
  After calling a VarDataHandler or VarDataCHandler, the size of the vardata
  area for the object has changed.  It is not allowed for a handler to do
  anything which can cause this to happen, such as add or remove vardata
  entries to/from the current object.  For this reason, it is also not
  advisable to make any message calls from within a handler, unless it is
  known that no current or future handlers for that message would be adding/
  removing vardata entries to/from this object.

BAD_DETACH_MSG
  ObjInitDetach was called with AX != MSG_META_DETACH or
  MSG_META_APP_SHUTDOWN

TIMER_NOT_STOPPED_BEFORE_GEODE_EXITED
  A timer for the currently-exiting geode (ds:bx.HM_owner is the handle
  of the geode) remains on the timer list. All timers belonging to a geode