OSRLogoOSRLogoOSRLogo x Seminar Ad

Everything Windows Driver Development

GoToHomePage xLoginx

    Thu, 14 Mar 2019     118020 members


  Online Dump Analyzer
OSR Dev Blog
The NT Insider
The Basics
File Systems
ListServer / Forum
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

Kernel Driver Frequestly Asked Questions (FAQ)

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.

The system crashed with bugcheck (some number), what is wrong?

[Answer by Mark Roddy, markr_at_hollistech_dot_com, 25 August 2003]

You have to run windbg on either the live system while it is in the bugcheck or the crash dump produced by the bugcheck. You must have the proper symbols installed, or you are wasting your time. Use the '!analyze -v'  command to understand more about the cause of the bugcheck. This will frequently produce a stack strace (of course only if you bothered to install the correct symbols) that will get you very close to a root cause understanding of the problem. In addition, the windbg help files include a comprehensive list of bugcheck codes, many with a detailed description of possible causes and/or potential next steps to take to analyze the problem.

As always, when testing a system, assume that your code is the bad code until you have proven otherwise.

Why doesn't the WinDBG command !irql always return the correct IRQL for my target?

[Answer by Jake Oshins, jakeo_at_windows_dot_microsoft_dot_com. Workaround provided by James Antognini, antognini_at_mindspring_dot_nospam_dot_com, 27 August 2003]

!irql currently only produces useful results on a crashdump, not a live system. To retrieve the current IRQL on a live system you should instead use the !pcr command.

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

"WDF Tracing with WPP"
I hope this is the correct forum for asking questions on driver development. I'm a newbie to this website. Apologies if I'm posting to the wrong forum ... please advise.

I've been trying to use WPP-based tracing in order to help debug a new WDF driver. So far I've been able to get a trace log to show up when enabled via tracelog but the level and flags args do not seem to be working correctly since all of my generated trace logs have just one message in them (a header). I have read a lot of documentation and notes about getting this to work and it seems as if others are indeed successful. My driver is for a PCI device and it must work on Windows-XP (x86-32) as well as Windows-7 (amd64). The driver is based on a driver I wrote in 2004 which is used heavily on XP (32bit) systems. This is merely an update to 64-bit and Windows7. I am using the WinDDK-7.1.0 (just downloaded last week). I've followed the examples given in the MSDN WPP documentation, using TraceEvents(level,flags,formatstring,...). I am not getting compilation nor linker errors. The driver (after signing) loads correctly and supports open and close but does not work right on ioctls (.... that's why I need tracing to help with debug).

Thanks for any advice on next steps ...

Steve B

13-Jul-11, Steve Butner

Post Your Comments.
Print this article.
Email this article.
bottom nav links