iSCSI Format Failure from Windows Server 2012

I don't expect anyone to be able to help me with this, but I didn't expect any help last time I posted a message yet was pleasantly surpised to get a very spot-on answer.

This one is a bit tougher though.

I've been working on an iSCSI server, mostly just for fun. Been chipping away at it in my spare time. I've managed to get through a lot of things. The Device is seen by Windows Server 2012. I can connect to it. I can initialize a disk. I can create partitions on the disk as far as I can tell (windows's own cache could be lying to itself about some of those things). But the actual formatting of the volume is where I run into trouble.

I've implemented all forms of ModeSense, ReadCapacity, Read, Write, Data-In, and Data-out. Also implemented a task-management class which seems to be functioning as intended.... but by golly, I just have no idea why this is still failing.

Some clues and relevant information:
1) For starters, here's the capture

2) Windows Server 2012 Successfully completes the "Gather information" step and the "Create new partition" step, but during the "Format Volume" Step reports "Failed to format volume - One or more parameter values passed to the method were invalid."

3) The failure occurs immediately AFTER Packet Number 6384 which I verified with breakpoints.
4) Packet 6384 is the longest Read operation during the process (128 blocks -- 65536 bytes).
5) This Read operation follows a write operation to the same LBA of the same length (128 blocks -- 65536 bytes)
6) The write operation is also the longest write operation of the entire process up to the point of failure. It is the first write operation to be >= 128 blocks.
7) There are other multi-block read and write operations that do not return errors, which to the best of my knowledge point the finger away from the Task-management system. I'll try to briefly and succinctly describe how the task management system works
7a).The long writes will send up to 8192 bytes in the first request, but the "Final" flag in the PDU will NOT be set.
7b). The Absense of the "Final" flag causes a task to be registered in a list, indexed by the "InitiatorTaskTag"
7c). "DataOut" PDUs follow the Write request and reference the InitiatorTAskTag which keeps information about the origin of the write request. The data-out packets are written using an offset of the original Task.
7d). If the DataOut packet has the "Final" flag set, the task is cleared at the end of its operation.

All of that internal stuff kinda seems to be working, but the format still fails. I've been looking at this problem for quite some time and I'm out of ideas and will need to shelve it for a while. Unfortunately, I think that any one of these 6000+ packets could potentially be causing the problem. I wish windows would just tell me WHICH parameter is incorrect.