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: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]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:
- Get current and next stack pointers.
- Copy current stack location to next.
- Set completion routine.
- 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:xxxxx@padus.com]
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: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
You are currently subscribed to ntdev as: xxxxx@padus.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)