Jared,
If you are in the SF Bay Area, I could loan you a STT8300M and FW8G for a couple of months. Let me know.
Frank
This is not a unique problem with your ST-2000XCM taking bias and dark frames. The same thing happens with the release version with both STT-8300M and Canon 6D cameras, but only when taking bias and dark frames. There is another very long topic going back months covering this issue. For me and apparently others, the issue can go away completely if you put a delay of 10 to 20 seconds between frames. Your description exactly matches what happens for many users. Other users with the same cameras never report this, so it seems to be an unknown random factor, but easy to deal with.
I was just looking into this. Seems it’s happening across multiple cameras and it’s pretty random. I thought it was a threading issue but it doesn’t appear to be. As you mentioned it does seem like a short timeout fixes it (even just a couple of seconds). I think a file system process is acting asynchronously and we’re not expecting that. So it’s clearing the image array as we’re writing the image and that makes things angry!
Jared
I know others have said 2 seconds did the trick. For me 2 seconds did not seem to help. Long runs with 12 seconds have run flawlessly. But it’s even more random than that. The most common behavior before I was trying any delay, was it would fail every few frames for a dozen tries. Then it would run 80 frames without a single failure. Nothing I know of changed on the pc or hardware, it would just start working.
Frank, Thanks for the offer. But I’m in the part of Texas that likes to act like California…AKA Austin 
Thanks,
Jared
When creating the sequence file to test my ST-2000XCM, I had failed to enter a delay between events. I put in 5 seconds and retested and that seems to have cleared the issue. Overnight, I setup a long test with SGP taking 64, 5 min light frames and had PHD2 taking 2 second frames at the same time. The process ran all the way through without any errors being reported so it looks like inserting a delay between events was the solution.
I will retest with bias and dark frames, as well.
Thanks for the feed back.
Charlie
I was a person who mentioned this issue with my STT8300. Just to clarify, for me it is with bias frames and flat frames, not darks. It seems very much related to exposure length. A two-second delay improves things, but doesn’t absolutely eradicate the problem. I have the same problem on two different laptops.
I haven’t had a chance to update SBIG driver and firmware yet, to see if it makes a difference. There was a mention of something about USB communications in one of the SBIG descriptions, not sure if it applies to STT8300. Fingers crossed.
Best regards,
Craig
well let us know how things work out for us chickens 
- do you have the OAG filter wheel cover?
I have the self-guiding filter wheel on my STT-8300.
I didn’t get to the experiment this weekend; hopefully soon.
Craig
Same here. Rain all weekend…and while that generally means “More astro testing” this time it meant I didn’t want to run out to the obs to bring the equipment inside. Hopefully soon. Currently trying to work out some other issues. And since this “ain’t broke” it’s not top priority at the moment.
Thanks,
Jared
Much, much later, I am happy to report that I am finally playing with my gear again heading into Star Party season for me.
I have a new pier-mounted micro computer (Windows 10 pro) to replace my laptop, and both SBIG drivers and SGP versions have updated (I am using 2.5.1.17), so it isn’t a well-controlled test.
Caveats aside, though, I am now able to take bias and flat frames just as fast as I like with none of the problems with duplicate naming or “crashing” SGP mentioned above, and I think in another thread, as well.
Great work and thanks a bunch!
Craig