We will organize these questions into a better hierarchy as we get more answers.

For now, we'll just list the FAQs and answers that we have.  The question or issue is provided, along with the name of the expert supplying the answer.

Readers: Feel free to suggest questions, or even to write answers.  Click the Post Your Comments link to add a comment, question, or suggestion.

Members of NTDEV and NTFSD:To add an answer to the FAQ, simply add the text "FOR FAQ" to the subject line of your posting to either of these forums.  If you have any issues with how the FAQ question or answer has been processed, email OnlineAdmin@osr.com.

Questions And Answers:

NDIS: ProtocolReceive Handler is Not Being Called

[Answer by Srin Kumar, srin_kimar_at_nai_dot_com, 22 July 2003]

If you are developing either an NDIS IM driver or Protocol driver, and you are supporting ProtocolReceivePacket, that's what's being called. 

If you're supporting both ProtocolReceivePacket and ProtocolReceive paths which function is called depends on your miniport driver. Try disabling ProtocolReceivePacket function and this should make ProtocolReceive path the active path for testing

TDI Filter Drivers: Running out of I/O Stack Locations

[Answer by Mark Roddy, markr_at_hollistech_dot_com, 24 July 2003]

TDI filter drivers have to deal with the fact that they will receive IRPs that do not always have enough stack locations to be forwarded down the stack. This is a known design issue in the NT network stack implmentation. Failure to handle this situation results in a BSOD due to no more irp stack locations. The best practice is for the TDI filter driver to create new IRPs, either for all IRPs it processes or for those that do not have enough stack locations, forward the new IRPs, correlate the response in a completion handler that then also completes the originalk IRP.

FIle Systems: What Does "Synchronous" Mean?

[Answer by Nick Ryan, nryan_at_nryan_dot_com, 23 July 2003]

There are other conditions that may make a request synchronous in addition to just having a synchronous file object. In fact, some of these conditions override FO_SYNCHRONOUS_IO. My GUESS here is that you are blocking on asynchronous paging I/O when you shouldn't be. For those classes of I/O that can be either synch or asynch (such as read/write), you should be relying on the value of IoIsOperationSynchronous().

Exactly what it means for an I/O request to be synchronous is a fuzzy concept that's never been explained adequately by Microsoft. The best resource we have here is, of course FastFat. Nagar's book also does a good job of covering the concept. Basically, if a request is synchronous (either 'inherently' or because IoIsOperationSynchronous() returns TRUE), it is OK for you to block or not block and to pend or not pend as you see fit. Otherwise, you must make every effort not to block and to pend lower I/O whenever possible. Fastfat sometimes violates these.

When posting a create in a filesystem filter, should I store and impersonate the security context of the original thread?

[Answer by Nick Ryan, nryan_at_nryan_dot_com, 29 July 2003]

Actually, yes. There is one corner case (which I believe Microsoft should classify as a bug) where FastFat performs a privilege check against the current thread's token while processing a create. (The offending code is in FatCheckSystemSecurityAccess).

Is there any way for a kernel mode driver to send a windows message (something like WM_REFRESH_CONFIG) using SendMessage or something similar? How about receiving such messages in a driver?

[Answer by Peter Viscarola, petergv_at_osr_dot_com, 25 July 2003]

No.  Windows drivers run as part of the operating system, and there's no practical method to send or receive Windows messages (such as WM_REFRESH_CONFIG) in this environment.