Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Layered SCSI port driver (2)

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Actually, after further investigation I've determined that only SCSI
requests initiated from a user mode DLL using MFC are generating the
problem. Executables using MFC are working just fine.

Hi All,

I'm writing a simple layered driver that is supposed to receive SCSI
requests from a user application and send them to the port driver. Under
Windows 2000 the driver is working as expected. Under Windows NT if the
application sending the request is using MFC (Microsoft Foundation Class)
after the code below is executed the complete routine never gets called.

IrpStack->MajorFunction = IRP_MJ_SCSI;
IrpStack->Parameters.Scsi.Srb = Srb;

IoSetCompletionRoutine(Irp, CompleteScsiRequest, Context, TRUE, TRUE,
TRUE);

IrpStack = IoGetNextIrpStackLocation(Irp);
IrpStack->MajorFunction = IRP_MJ_SCSI;
IrpStack->Parameters.Scsi.Srb = Srb;

IoMarkIrpPending(Irp);
IoCallDriver(PortDevice, Irp);

return (STATUS_PENDING);

I tried to trace my thread and invariably, if some MFCxx! Call is in the
stack the irp gets "lost" and the thread stops in some NT unexpected
exception after a write operation. If, on the other hand, the process
calling my driver doesn't use the MFC library, the completion routine is
called and everything works fine. Also, in Windows 2000 the same driver is
working fine with applications using MFC.

Does anybody have any idea how and why MFC is affecting my driver behavior
under Windows NT 4?

TIA,

Mirco Caramori

Comments

  • OSR_Community_User-35OSR_Community_User-35 Member Posts: 154
    MFC is just a framework of application code that uses the Win32 APIs.
    Your non-MFC applications just aren't exercising the APIs quite the
    same way. It's the unhandled exception that is your real problem, and
    probably has to do with the way you are passing down the IRP.

    You're code snippent looks a little odd. How is the user invoking
    your driver code? By private IOCTL? Where does the SRB come from?
    Are you passing down an IRP passed to you, or building your own IRP?

    All my SCSI port filtering follows
    some very simple steps:

    1. Get current and next stack pointers.
    2. Copy current stack location to next.
    3. Set completion routine.
    4. return IoCallDriver().

    Note there is no IoMarkIrpPending() or return STATUS_PENDING. The
    port driver you are calling determines if it is pending or not, and if
    you return the value returned by IoCallDriver() you will always get it
    right.

    If you queued the IRP within your driver rather than passing it down
    to the port driver immediately, then you would mark it pending and
    return STATUS_PENDING.

    Also, in your completion routine, you need to worry about marking the
    IRP pending:

    if (pIRP->PendingReturned)
    IoMarkIrpPending(pIRP);

    You are not copying the current stack location to the next; you are
    just manually setting up the next, but you are ignoring some of the
    fields in a stack location.

    Why are you changing the contents of the *current* stack location?
    The lower driver won't see those.

    -----------------------------------------------------------------------
    Dave Cox
    Hewlett-Packard Co.
    HPSO/SSMO (Santa Barbara)
    https://ecardfile.com/id/Dave+Cox


    -----Original Message-----
    From: Mirco Caramori [mailto:[email protected]]
    Sent: Tuesday, April 11, 2000 6:01 AM
    To: NT Developers Interest List
    Subject: [ntdev] Layered SCSI port driver (2)


    Actually, after further investigation I've determined that only SCSI
    requests initiated from a user mode DLL using MFC are generating the
    problem. Executables using MFC are working just fine.

    Hi All,

    I'm writing a simple layered driver that is supposed to receive SCSI
    requests from a user application and send them to the port driver. Under
    Windows 2000 the driver is working as expected. Under Windows NT if the
    application sending the request is using MFC (Microsoft Foundation Class)
    after the code below is executed the complete routine never gets called.

    IrpStack->MajorFunction = IRP_MJ_SCSI;
    IrpStack->Parameters.Scsi.Srb = Srb;

    IoSetCompletionRoutine(Irp, CompleteScsiRequest, Context, TRUE, TRUE,
    TRUE);

    IrpStack = IoGetNextIrpStackLocation(Irp);
    IrpStack->MajorFunction = IRP_MJ_SCSI;
    IrpStack->Parameters.Scsi.Srb = Srb;

    IoMarkIrpPending(Irp);
    IoCallDriver(PortDevice, Irp);

    return (STATUS_PENDING);

    I tried to trace my thread and invariably, if some MFCxx! Call is in the
    stack the irp gets "lost" and the thread stops in some NT unexpected
    exception after a write operation. If, on the other hand, the process
    calling my driver doesn't use the MFC library, the completion routine is
    called and everything works fine. Also, in Windows 2000 the same driver is
    working fine with applications using MFC.

    Does anybody have any idea how and why MFC is affecting my driver behavior
    under Windows NT 4?

    TIA,

    Mirco Caramori


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Dave,

    Actually I got most of the code from the "scsicdwo" example in the NT4 DDK.
    Yes, the application is sending SRBs using a buffered private IOCTL.
    As you can see from the code snippet, the driver is "recycling" the IRP and
    sending an IRP_MJ_SCSI request to the port driver.
    Do you think I should copy the entire stack location to the next even if I'm
    changing the IRP from IRP_MJ_DEVICE_CONTROL to IRP_MJ_SCSI?

    Again, what is really puzzling me is that in Windows 2000 everything works
    fine and under NT4 only applications sending my private IOCTL from a DLL
    using MFC are failing.


    Thanks,

    ---Mirco.


    -----Original Message-----
    From: [email protected]
    [mailto:[email protected]]On Behalf Of COX,DAVID
    (HP-Roseville,ex1)
    Sent: Tuesday, April 11, 2000 10:41 AM
    To: NT Developers Interest List
    Subject: [ntdev] RE: Layered SCSI port driver (2)

    MFC is just a framework of application code that uses the Win32 APIs.
    Your non-MFC applications just aren't exercising the APIs quite the
    same way. It's the unhandled exception that is your real problem, and
    probably has to do with the way you are passing down the IRP.

    You're code snippent looks a little odd. How is the user invoking
    your driver code? By private IOCTL? Where does the SRB come from?
    Are you passing down an IRP passed to you, or building your own IRP?

    All my SCSI port filtering follows
    some very simple steps:

    1. Get current and next stack pointers.
    2. Copy current stack location to next.
    3. Set completion routine.
    4. return IoCallDriver().

    Note there is no IoMarkIrpPending() or return STATUS_PENDING. The
    port driver you are calling determines if it is pending or not, and if
    you return the value returned by IoCallDriver() you will always get it
    right.

    If you queued the IRP within your driver rather than passing it down
    to the port driver immediately, then you would mark it pending and
    return STATUS_PENDING.

    Also, in your completion routine, you need to worry about marking the
    IRP pending:

    if (pIRP->PendingReturned)
    IoMarkIrpPending(pIRP);

    You are not copying the current stack location to the next; you are
    just manually setting up the next, but you are ignoring some of the
    fields in a stack location.

    Why are you changing the contents of the *current* stack location?
    The lower driver won't see those.

    -----------------------------------------------------------------------
    Dave Cox
    Hewlett-Packard Co.
    HPSO/SSMO (Santa Barbara)
    https://ecardfile.com/id/Dave+Cox


    -----Original Message-----
    From: Mirco Caramori [mailto:[email protected]]
    Sent: Tuesday, April 11, 2000 6:01 AM
    To: NT Developers Interest List
    Subject: [ntdev] Layered SCSI port driver (2)


    Actually, after further investigation I've determined that only SCSI
    requests initiated from a user mode DLL using MFC are generating the
    problem. Executables using MFC are working just fine.

    Hi All,

    I'm writing a simple layered driver that is supposed to receive SCSI
    requests from a user application and send them to the port driver. Under
    Windows 2000 the driver is working as expected. Under Windows NT if the
    application sending the request is using MFC (Microsoft Foundation Class)
    after the code below is executed the complete routine never gets called.

    IrpStack->MajorFunction = IRP_MJ_SCSI;
    IrpStack->Parameters.Scsi.Srb = Srb;

    IoSetCompletionRoutine(Irp, CompleteScsiRequest, Context, TRUE, TRUE,
    TRUE);

    IrpStack = IoGetNextIrpStackLocation(Irp);
    IrpStack->MajorFunction = IRP_MJ_SCSI;
    IrpStack->Parameters.Scsi.Srb = Srb;

    IoMarkIrpPending(Irp);
    IoCallDriver(PortDevice, Irp);

    return (STATUS_PENDING);

    I tried to trace my thread and invariably, if some MFCxx! Call is in the
    stack the irp gets "lost" and the thread stops in some NT unexpected
    exception after a write operation. If, on the other hand, the process
    calling my driver doesn't use the MFC library, the completion routine is
    called and everything works fine. Also, in Windows 2000 the same driver is
    working fine with applications using MFC.

    Does anybody have any idea how and why MFC is affecting my driver behavior
    under Windows NT 4?

    TIA,

    Mirco Caramori


    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')

    ---
    You are currently subscribed to ntdev as: [email protected]
    To unsubscribe send a blank email to $subst('Email.Unsub')
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online
Writing WDF Drivers 22 May 2023 Live, Online