The real question is why are you mucking with the WDM sample? It is
conditions like the one you cite that drove the development of KMDF, and for
99.99% of the filter drivers WDM should not be used.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, April 12, 2018 8:43 AM
To: Windows System Software Devs Interest List Subject: [ntdev] IoAcquireRemoveLock and Microsoft’s toaster example
> The real question is why are you mucking with the WDM sample? It is > conditions like the one you cite that drove the development of KMDF, and > for > 99.99% of the filter drivers WDM should not be used. > > > Don Burn > Windows Driver Consulting > Website: http://www.windrvr.com > > > > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of > xxxxx@gmail.com > Sent: Thursday, April 12, 2018 8:43 AM > To: Windows System Software Devs Interest List > Subject: [ntdev] IoAcquireRemoveLock and Microsoft’s toaster example > > Hi guys, > > I’m new in the Windows drivers world, and I’m working on a fliter driver > which is based on this toaster example: > > https://github.com/ljvblfz/WindowsServer2003DDKFiles/blob/3d85bdfeaea192aea0 > 8d519a32e1da9b89cda8b9/WINDDK/3790.1830/src/general/toaster/filter/filter.c > https: > > You can see that the IoAcquireRemoveLock function is used in most > callbacks, > such as this one: > FilterDispatchPower, source: > > https://github.com/ljvblfz/WindowsServer2003DDKFiles/blob/3d85bdfeaea192aea0 > > 8d519a32e1da9b89cda8b9/WINDDK/3790.1830/src/general/toaster/filter/filter.c# > L704-L710 > https: > > But IoAcquireRemoveLock is not used when processing custom IOCTL-s, in the > callback function FilterDispatchIo, source: > > https://github.com/ljvblfz/WindowsServer2003DDKFiles/blob/3d85bdfeaea192aea0 > > 8d519a32e1da9b89cda8b9/WINDDK/3790.1830/src/general/toaster/filter/filter.c# > L969-L971 > https: > > I wanted to know whether that’s an omission of the example, or whether > there’s a reason behind it? > > Thanks. > > — > NTDEV is sponsored by OSR > > Visit the list online at: > http: > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software > drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at > http: > > > — > NTDEV is sponsored by OSR > > Visit the list online at: < > http://www.osronline.com/showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at < > http://www.osronline.com/page.cfm?name=ListServer> ></http:></http:></http:></http:></https:></https:></https:>
Did you really not notice that this sample is 13 years old? It is an
antique. Development tools don’t age like wine, they age like milk.
It’s also illegal for that person to have posted the entire Windows 2003
DDK in public.
Â
I wanted to know whether that’s an omission of the example, or whether there’s a reason behind it?
The reason is that you shouldn’t be looking at antiques. Those problems
have been fixed in the 8 or 9 major WDK releases since then. The
current WDK is free, and the current authorized and modernized Microsoft
samples are also freely available on GitHub:
   https://github.com/Microsoft/Windows-driver-samples/
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Usermode IOCTLs (and Read/Write) take the remove lock on the whole stack. The stack will not get IRP_MN_REMOVE_DEVICE while there is any usermode I/O pending on it. Only QUERY_REMOVE will get through. SURPRISE_REMOVAL will, as well.
Thank you guys, I will check out KMDF. The reason I was looking at the old example is that I found code which does what I need (working with webcams), and it was based on that example.