Weird bug that showed up when the serial ports were all unconfigured that suddenly meant that the data files were not being written. I figured it might be something with the whole I/O subsystem, but as it turned out it was a really bizarre confluence of things:
1.) When none of the serial ports are configured, the serial port code is not initialized and the serial port interrupt routine is not installed.
2.) The interrupt routine includes a call as part of its initialization that explicitly sets the maximum priorty value of the main (parent) process.
3.) Undocumented feature that setting the maximum priority of the root process by default also sets the maximum priority of any subsequent child threads. Not explicitly setting this value means it stays at the MINIMUM value, as in no child thread can be created with an explicit priority level. The only indication that a thread creation has failed is the return value of the thread handle; happily I check for this (from being bitten in the ass a few times), but the only thing I can do is print an error message to the console.
4.) We recently set thread priorities for the child threads explicitly (the default is to let the system create the threads with an automatic priority so all threads are levelled). So the only way this showed up was in this way wacky configuration where the serial ports were all reconfigured off and someone tried to run the system.
It was a good legitimate catch, but I rocked the house in not only finding this little bitch but finding the solution and getting it pumped out the same day.