Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
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/
Hello all,
We have an exciting update to share - Plugfest 2023 will now also include Windows Server!
You will have access to Windows Server VMs hosted on Azure, to help you prepare your drivers for the next version of Windows Server by performing interoperability testing with other products. You may register a separate team dedicated to server or have one single team, as appropriate to your situation. The event will remain virtual, with no changes to the current schedule. To accommodate these changes, the registration deadline has been extended to Friday May 12, 2023 at 11:59PM Pacific Time.
Action Needed:
If you have already submitted the registration form and would like to extend your participation to include server, please complete the additional form linked below:
https://forms.office.com/r/L9GR4Qiyqp
If you haven’t registered for Plugfest 2023 yet, please use the original registration form below (it has been updated to reflect both Client and Server):
https://forms.office.com/r/CiAkCGJZkR
As a reminder, the event starts June 5th 2023 and we look forward to having you join us for this event. Please reach out to our coordinating PMs ([email protected]) or Olivia Chapman ([email protected]) if you have any questions.
Link to Original Discussion: https://community.osr.com/discussion/293789/filter-plugfest-2023
Hi Dejan
There are a couple of things that are contributing to some confusion here.
The first is that the currently available documentation doesn't do a great job of explaining that it is possible to enable bypass-IO on a file hosted on a volume where the filter stack supports bypass-IO, but the underlying storage stack does not. In such a scenario (which I suspect is what you're seeing), reads for bypass-IO enabled files will bypass the filter stack, but still be sent down the volume stack. I will file a documentation bug to better explain this.
The second is that FsUtil wasn't providing much help in understanding this. This has been addressed with more recent builds of Windows (this is output from one of my machines running Windows 11 22H2):
PS C:> fsutil.exe bypassio state c:
BypassIo on "c:\" is partially supported
Volume stack bypass is disabled (iaStorAVC.sys)
Storage Type: RAID
Storage Driver: Not BypassIo Compatible
Dave Buches
Windows CoreFS Dev
Hello! We are excited to announce that Plugfest 2023 is starting June 5th 2023!!
Since last year’s virtual Plugfest was such a success, Plugfest 2023 is going to continue to be virtual for 2023! Similar to last year, Plugfest 2023 will have VMs hosted on Azure to take the place of physical HW.
What is Plugfest?
The goal of Plugfest is to help you prepare your file system minifilter, network filter, or boot encryption driver for the next version of Windows by performing interoperability testing with other products.
When is Plugfest 2023?
Plugfest 2023 will take place in batches between Monday, June 5, 2023 and Friday June 9, 2023.
Who are we looking for to participate?
Independent Software Vendors (ISVs), developers writing file system minifilter drivers and/or network filter drivers for Windows.
How much does it cost?
FREE - There is no cost to attend this event.
Why should I go?
Here are four major benefits of Plugfest:
• The opportunity to test products extensively for interoperability with other vendors' products and with Microsoft products. This has traditionally been a great way to understand interoperability scenarios and flush out any interoperability-related bugs.
• Get exclusive talks and informative sessions organized by the File System Minifilter team about topics that affect the filter driver community.
• Great opportunity to meet with the file systems team, the network team, and various other teams at Microsoft and get answers to your unanswered technical questions.
• Early exposure to new hardware innovations, that affect filter functionality
How do I register?
Please fill out the registration form below and if you are selected to participate, you will hear back by Friday May 12th, 2023.
Full url link here - https://forms.office.com/r/CiAkCGJZkR
Registration for Plugfest 2023 will close on Friday May 5, 2023 at 11:59PM Pacific.
If you have any additional questions please email our coordinating PM, Olivia Chapman, at [email protected]
-The Microsoft File System Minifilter Team
As it took me most of a day to understand this is a bug in 22H2, I'll save you all the trouble: to use network debugging of hyper-v vms on an external switch (e.g. from your hyper-v host to the vm) , on W11 22H2 you have to disable the switch extensions that are enabled by default. Specifically Microsoft Azure VFP Switch Filter Extension and Microsoft NDIS Capture.
Failure symptoms: your vms have default 169.254 ip addresses.
Hi everyone.
I have been reading about UFX class extension for WDF.
https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/function-client-driver
The only sample I saw "ufxclientsample" mention about installing it on Windows 10 Mobile.
Also, opening the sample, I saw it refers to header files I don't have on my WDK (10.0.22.621.382).
Can this kind of driver be built using regular WDK or do I need to get the environment for a BSP for WIndows Mobile?
Can it be installed on a regular Windows for desktop instead of Windows Mobile?
Regards,
What you’re doing isn’t commonly done… you don’t see it much outside the enterprise setting and, aside from that, is mostly used by those who are trying to “skirt the rules”… so, we don’t see a ton of these complaints here.
Peter
Hi,
I am writing an UMDF2 driver which accesses some legacy PCI board.
Besides reading and writing PCI bar memory this driver needs to handle occasional interrupts from the board.
For compatibility reasons the application needs to be notified about incoming interrupts knowing that these should be processed transparrently by the driver in an ideal worls.
Would it be possible to
* initialize the default queue with WdfIoQueueDispatchParallel
* Introduce an IOCTL WAIT_FOR_INTERRUPT
....
case WAIT_FOR_INTERRUPT:
// Store request in the device context so it can be completed later
// Do noting to mark request as pending, complete the request in the DPC of the interrupt
break;
case READ_REGISTER:
...
CASE WRITE_REGISTER:
and then have the application open a thread which issues a blocking IoControl with WAIT_FOR_INTERRUPT which only returns if the request is completed from the DPC routine handling the interrupt.
My question is:
If another thread of the application calls an IOControl request with e.g. READ_REGISTER, will this request be handled by the driver even though another request in the same queue is not completed? I have initialized the default queue as WdfIoQueueDispatchParallel, but does this mean that this request reaches the driver and can be completed emediatelly?
How does WdfIoQueueDispatchParallel relate to Overlapped IO?
Thank you and all the best!
Last Updated: 24 March 2021
These Rules and Guidelines are established for the overall good of the Community. We reserve the right to edit or change them at any time and without notice. For that reason, we recommend you stop by here frequently to check on the latest changes.
This Community and its forums is maintained by OSR Open Systems Resources, Inc. as a public service for the overall benefit of the professional Windows system software development community. The purpose of the Community is to facilitate communication among peers who design and develop Windows drivers, file systems, and file system Minifilters. The goal of the forum is to allow professional practicing engineers to assist each other with problems, issues, and policies. It's also intended as a place to have focused discussions regarding Windows OS architecture, driver development, file system and Minifilter development, and debugging issues.
The Community is specifically NOT for extended debates and discussions, and we tend not to appreciate answers that start with "In Linux, we do it this way" or "On Android, this would be easy."
We will be creating an FAQ for each of the lists. If you'd like to contribute a question or an answer, please feel free to post about it in the relevant category.
We are a respectful, inclusive, community. We, as a community, will not tolerate behavior that disrespects, harasses, abuses, shames, denigrates, mocks, or otherwise marginalizes any of our members. We will not accept trolling, insulting or derogatory comments, or personal or political attacks. We will also not accept rude, abusive, or offensive user names on this forum.
Incidents of inappropriate conduct on the list will result in that member, and perhaps all members from the offender's company, being permanently banned from the community.
The following are specifically inappropriate behaviors on these forums:
1. Commercial postings - This is a technical community, and the only posts that are allowed are technical in nature. Please don't post advertisements or announcements for your products, services, or activities to the forums. Your posting will NOT be considered technical (and thus legitimate), just because it starts with "I just wanted all you to know that we've released a new version of" some software. On the other hand, if somebody posts question saying "Can anybody recommend a good XYZ?", it's perfectly fine to answer "Yeah, we make XYZ's and we think they're pretty cool. Please contact me directly for more info."
2. Job solicitations - Not from commercial concerns looking for developers, not from head hunters, not from small companies, not from people looking for work, not from consultants looking for clients, not from consultants looking to offer their services to solve a specific problem.
3. Requests for, or offers of, or inquiries about paid consulting services - We consider these commercial postings, and are therefore not allowed. If you're interested in more information about hiring OSR or any other consultant on the forum to help with a problem, please email directly or visit the appropriate web site. If you're a consultant, and you're only willing to (further) help a poster on a paid basis, a good way to communicate this might be to say "What you're asking is beyond that scope of what I can help you with on a forum." Do not email them and offer your services (that would be a really major violation of the terms of this forum).
4. Salary, consulting rate or price discussions - Something about the laws here in the States about price fixing comes into play here. Please just don't do it.
5. Use of the email addresses or names of Community members for "direct mail advertising" or business solicitation of any type.
6. Asking about how to implement malware, or requesting help with techniques that are commonly used for the implementation of malware. The members here are not interested in helping with, and the forum will not support, the development of malware or anything that looks like or could be used as malware. This is true even when done under the premise of "this is for my personal learning." While we do not want to discourage questions from bona fide security researchers, it's often hard to distinguish between requests from legit defenders from those of black-hat offensive actors. Our policy is to err on the side of caution, and treat all such queries with suspicion. Sorry.
7. Anything that, in the judgment of the moderators, is not in keeping with the overall spirit and purpose of the Community or is not in the best interest of the Windows system software development community as a whole.
There are a number of other behaviors that are considered rules of "good conduct" for posting here on the forums. These include:
1. Read a bit before posting. This should help you get a "feel" for the forum, and how we tend to deal with different types of questions and responses here. It should also give you a feel for the character of some of our veteran members. Hopefully, these discoveries will be helpful as you eventually formulate and post your first questions.
2. Please do not revive "old" threads. Please not reply to threads where the last post is more than a month old. This is referred to as "necroposting." If you have a comment/question/issue that's raised in a "dead" thread, just start a new thread (you can post a link to the old thread if you want) and ask your question there.
3. Please post your question in the appropriate category: For example, file system filter questions should be posted to NTFSD; Other Windows driver questions should be posted to NTDEV.
4. Please do not post the same question in multiple categories. This is not allowed.
5. Please do the Community members the courtesy of searching the Internet and the list archives before you post a question.
6. Please post your questions/comments in English. We get that the majority of forum members are not necessarily native speakers of the English language. On the other hand, it is clear to us that the language most forum members share in common is English. If you struggle with English, try not to be too concerned -- The members will typically ask questions if your post is not sufficiently clear.
While we are first and foremost a community of working, professional, system software developers we absolutely welcome (and encourage, even!) questions from students, hobbyists, and those who wish to dabble in the field of Windows drivers. If you're a student, or if you're asking a question out of general curiosity or academic interest, we ask you to please say so in your post. Also, please don't ask us to do your homework for you. We mean that in both the literal sense (you shouldn't bring assignments from your professors here for us to solve for you) and also the more figurative sense (please do some independent research on your problem before asking us here).
Like any community, we have both written and unwritten rules of doing things here. We have a distinct character, flavor, and outlook. These things might not be obvious from simply reading these Rules and Guidelines. Therefore, our best advice to you for success in participating in the forum is to spend some time hanging out before posting. Read several threads. We're not saying you HAVE to do this... we're just suggesting that we have found over the many years that this forum has been active that this is conducive to getting the best answers to any questions that you may post.
The forums are all searchable from the web site, and can be searched by Google, using the "site:community.osr.com" qualifier. The community will be happiest if you search first, and ask questions after doing so.
Before you use this site, please be sure you read both our Terms of Service and Privacy Policy. Your use of the Community is expressly conditioned on your acceptance of the Terms and Service and Privacy Policy.
You can post here in the Announcements and Administration section if you have questions about the Community. We'll be happy to hear from you. We think.