Bogus OVERLAPPED pointer in the IO completion callback RRS feed

  • Question

  • I've got a device driver that I am currently taking to the edge and testing
    the heck out of it. This obviously is producing all kinds of interesing
    pops, bangs and whistles; kind of like particle physics in a collider. The
    latest one brings up the question of what happens when your application IO
    completion call back that was bound using BindIoCompletionCallback gets
    called with a status such as STATUS_CANCELLED, and not one of the
    normal ERROR_XXXX values?

    When the callback is called, I normally squirrel away some information and
    then go and finish things up. However, if I get a status such as
    STATUS_CANCELLED, things go to hell really really fast because at that point
    in time my OVERLAPPED pointer is bogus. The situation in the driver is that
    there is so much IO in process that yes, individual requests may be cancelled
    due to timeouts at any given point in time; remember, I'm testing edge conditions.
    Since everything I'm about to do in the callback is based on LPOVERLAPPED being
    valid, I'm in a bit of a quandry as to what to do, though my real question is why
    is that OVERLAPPED pointer invalid?

    If I let the app run, I'll get error dialogues indicating an R6025, but a colleague of
    mine and I believe that is simply obfuscating the real problem. Has anyone encountered
    such a scenario; e.g. bogus pointers in their IO complteion callback?

    The device is an LSI 3041 SAS controller with our proprietary driver
    connected to 3 Seagate ST9300 SAS drives. We are testing hard drives, and
    found a long time ago that the file system and SCSI pass through can be
    royal pains in the butt for some levels of testing that we MUST do. The
    particular test scenario has threads that are sending Start/Stop unit, and
    write track using blocking IO and a final thread that is blasting
    asynchronous read/write IO requests just as fast as it can. The driver
    queue is currently sized to allow 127 IO requests. All three drives are
    connected to the same controller and are using the same queue.

    The personal opinion of
    Gary G. Little

    • Edited by Gary Little Wednesday, July 2, 2008 9:19 PM More spelling
    Wednesday, July 2, 2008 9:16 PM


  • Just a quick note: This appears to be an issue in the application I was using ... which a nice way of saying "BUG". I was passing a bogus overlapped pointer to the IO functions.

    Monday, July 7, 2008 7:53 PM