Agilent E4426B signal generator locks up during multiple GPIB *SAV operations

Question

I have a test fixture with an Agilent E4426B RF signal generator connected to a PC via a National Instrument Ethernet-to-GPIB bridge. My software is attempting to sanitize the instrument by presetting it and then saving the current state to all of the memory locations writable via the standard SCPI command "*SAV x,y".

The loop works to a point, but eventually the instrument responds with an error and continuously displays the "L" icon on the front display and a "Remote preset" message at the bottom. At that point it won't respond to any more remote commands and I have to either cycle power or press LOCAL, then PRESET at which point it takes about 3 minutes to finish presetting. At that point the "L" icon is still present and and the next GPIB command sent to the instrument causes it to report a -113 error (undefined header) in the instrument error queue.

I fired up NI spy to see what was happening, and found that the error was happening at the same point in the loop - "*SAV 6,2" in this case. From NI Spy:

Send (0, 0x0017, "*SAV 6,2", 8 (0x8), NLend (0,0x01))
Process ID: 0x00000520 Thread ID: 0x00000518
ibsta:0xc168 iberr: 6 ibcntl: 2(0x2)

And here's the code from the instrument driver:

int CHP_E4426b::Erase()
{
  if ((m_StatusCode = Initialize()) != GPIB_SUCCESS) // basically just sends "*RST"
    return m_StatusCode;

  m_SaveState = "*SAV %d, %d";

  for (int i=0; i < 10; i++)
    for (int j=0; j < 100; j++) {
      sprintf(m_CmdString, m_SaveState, j, i);
      if ((m_StatusCode = Send(m_CmdString, strlen(m_CmdString))) != GPIB_SUCCESS)
        return m_StatusCode;
    }

  return GPIB_SUCCESS; 
}

I tried putting a small Sleep() delay (10-20 ms) at the end of the inner loop, and to my surprise it caused the error to show up earlier rather than later. 10 ms caused the loop to error out at 44,1 and 20 ms was even sooner. I've already eliminated faulty cabling or the instrument as the culprit. This same type of sequence works without any error on a higher end signal generator, so I'm tempted to chalk this up to a bug in the instrument's firmware.