Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

OSR Seminars


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 7  
25 Jan 18 07:39
ntdev member 176913
xxxxxx@faschingbauer.co.at
Join Date:
Posts To This List: 2
KMDF: determine originating thread of WDFREQUEST

Hi all, I have a driver which has an IO queue (WDFQUEUE) to receive requests (WDFREQUEST) from usermode processes, handles them, and then calls WdfRequestCompleteWithInformation() to complete them. My customer has some, well, weird (I call it bullshit) semantics of I2C communication that I have to implement: a transaction is divided into non-atomic accesses where transactions may interleave and steal bus access from each other. This stealing actually happens in rare circumstances which I use to call a "race condition", and I want to protect myself from any blames by implementing an "ownership" to detect such errors and reject bullshit. What I envision is to remember the thread that *starts* an I2C transaction, and to release that owner when it *stops* the transaction - and to reject any request from a different thread should that happen in the middle of a transaction. How is this done? The WDFREQUEST objects that I receive via the WDFQUEUE are the result of a usermode thread calling DeviceIoControl(). This usermode thread is the one that should "own" an ongoing I2C transaction, and thus I have to remember that thread in driver space. I can imagine that the WDFREQUEST carries that thread's ID with it - it's just that I don't understand how to access this information. Can anybody help me please? Thank you in advance, Jörg -- DI Jörg Faschingbauer Linux und Open Source - Programmierung, Beratung und Schulung http://www.faschingbauer.co.at
  Message 2 of 7  
25 Jan 18 07:52
Don Burn
xxxxxx@windrvr.com
Join Date: 23 Feb 2011
Posts To This List: 1406
KMDF: determine originating thread of WDFREQUEST

Actually, the WDFREQUEST does not carry the thread ID, and the thread in the driver is not guaranteed to be the thread from user mode unless you set up the device with additional calls. Overall your approach is not viable, can't you have a START TRANSACTION call that driver returns an ID for, then use the ID in your calls, then have an END TRANSACTION to finish things. I.E. do explicitly what you were trying to do with the thread ID? 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@faschingbauer.co.at Sent: Thursday, January 25, 2018 7:38 AM To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST Hi all, I have a driver which has an IO queue (WDFQUEUE) to receive requests (WDFREQUEST) from usermode processes, handles them, and then calls WdfRequestCompleteWithInformation() to complete them. My customer has some, well, weird (I call it bullshit) semantics of I2C communication that I have to implement: a transaction is divided into non-atomic accesses where transactions may interleave and steal bus access from each other. This stealing actually happens in rare circumstances which I use to call a "race condition", and I want to protect myself from any blames by implementing an "ownership" to detect such errors and reject bullshit. What I envision is to remember the thread that *starts* an I2C transaction, and to release that owner when it *stops* the transaction - and to reject any request from a different thread should that happen in the middle of a transaction. How is this done? The WDFREQUEST objects that I receive via the WDFQUEUE are the result of a usermode thread calling DeviceIoControl(). This usermode thread is the one that should "own" an ongoing I2C transaction, and thus I have to remember that thread in driver space. I can imagine that the WDFREQUEST carries that thread's ID with it - it's just that I don't understand how to access this information. Can anybody help me please? Thank you in advance, J??rg -- DI J??rg Faschingbauer Linux und Open Source - Programmierung, Beratung und Schulung http://www.faschingbauer.co.at --- 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://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 3 of 7  
25 Jan 18 09:40
Doron Holan
xxxxxx@microsoft.com
Join Date: 08 Sep 2005
Posts To This List: 10203
KMDF: determine originating thread of WDFREQUEST

One way to make this work is to have your transaction semantics on the wdffileobject level. The app would open a handle per thread (or transaction) instead of one overlapped handle shared across all threads. Bent from my phone ________________________________ From: xxxxx@lists.osr.com <xxxxx@lists.osr.com> on behalf of xxxxx@windrvr.com <xxxxx@lists.osr.com> Sent: Thursday, January 25, 2018 4:51:18 AM To: Windows System Software Devs Interest List Subject: RE: [ntdev] KMDF: determine originating thread of WDFREQUEST Actually, the WDFREQUEST does not carry the thread ID, and the thread in the driver is not guaranteed to be the thread from user mode unless you set up the device with additional calls. Overall your approach is not viable, can't you have a START TRANSACTION call that driver returns an ID for, then use the ID in your calls, then have an END TRANSACTION to finish things. I.E. do explicitly what you were trying to do with the thread ID? Don Burn Windows Driver Consulting Website: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.windrvr.com&d ata=02%7C01%7CDoron.Holan%40microsoft.com%7Cf4e61e7044a5460bb7f008d563f26695%7Cee 3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636524815110984702&sdata=Hy3KaLYcZnezBvM UOfZfMiacErp4JgVYC7xeZG1aJPs%3D&reserved=3D0 -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@faschingbauer.co.at Sent: Thursday, January 25, 2018 7:38 AM To: Windows System Software Devs Interest List <xxxxx@lists.osr.com> Subject: [ntdev] KMDF: determine originating thread of WDFREQUEST Hi all, I have a driver which has an IO queue (WDFQUEUE) to receive requests (WDFREQUEST) from usermode processes, handles them, and then calls WdfRequestCompleteWithInformation() to complete them. My customer has some, well, weird (I call it bullshit) semantics of I2C communication that I have to implement: a transaction is divided into non-atomic accesses where transactions may interleave and steal bus access from each other. This stealing actually happens in rare circumstances which I use to call a "race condition", and I want to protect myself from any blames by implementing an "ownership" to detect such errors and reject bullshit. What I envision is to remember the thread that *starts* an I2C transaction, and to release that owner when it *stops* the transaction - and to reject any request from a different thread should that happen in the middle of a transaction. How is this done? The WDFREQUEST objects that I receive via the WDFQUEUE are the result of a usermode thread calling DeviceIoControl(). This usermode thread is the one that should "own" an ongoing I2C transaction, and thus I have to remember that thread in driver space. I can imagine that the WDFREQUEST carries that thread's ID with it - it's just that I don't understand how to access this information. Can anybody help me please? Thank you in advance, J?rg -- DI J?rg Faschingbauer Linux und Open Source - Programmierung, Beratung und Schulung https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.faschingbauer .co.at&data=02%7C01%7CDoron.Holan%40microsoft.com%7Cf4e61e7044a5460bb7f008d563f26 695%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636524815110984702&sdata=iVygl6z PH3PJEPhQPVpczMYhfBqU3hTXfeLoWCmMZ4A%3D&reserved=0 --- NTDEV is sponsored by OSR Visit the list online at: <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osronline.co m%2Fshowlists.cfm%3Flist%3Dntdev&data=02%7C01%7CDoron.Holan%40microsoft.com%7Cf4e 61e7044a5460bb7f008d563f26695%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636524 815110984702&sdata=C0narJ96P19T3o0N4bf8zP7%2BdrF43%2B%2FD2aZlUBVspaY%3D&reserved= 0> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osr.com%2Fse minars&data=02%7C01%7CDoron.Holan%40microsoft.com%7Cf4e61e7044a5460bb7f008d563f26 695%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636524815110984702&sdata=APV2Z8S F6eTAA2WB1nAO49VOP%2BhC82sf%2FxoqT555y0M%3D&reserved=0> To unsubscribe, visit the List Server section of OSR Online at <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osronline.co m%2Fpage.cfm%3Fname%3DListServer&data=02%7C01%7CDoron.Holan%40microsoft.com%7Cf4e 61e7044a5460bb7f008d563f26695%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636524 815110984702&sdata=4afKvOq%2BrYU6lWRIqZconX38lgImxU3rBS9ZgI4GzBQ%3D&reserved=0> --- NTDEV is sponsored by OSR Visit the list online at: <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osronline.co m%2Fshowlists.cfm%3Flist%3Dntdev&data=02%7C01%7CDoron.Holan%40microsoft.com%7Cf4e 61e7044a5460bb7f008d563f26695%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636524 815110984702&sdata=C0narJ96P19T3o0N4bf8zP7%2BdrF43%2B%2FD2aZlUBVspaY%3D&reserved= 0> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osr.com%2Fse minars&data=02%7C01%7CDoron.Holan%40microsoft.com%7Cf4e61e7044a5460bb7f008d563f26 695%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636524815110984702&sdata=APV2Z8S F6eTAA2WB1nAO49VOP%2BhC82sf%2FxoqT555y0M%3D&reserved=0> To unsubscribe, visit the List Server section of OSR Online at <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.osronline.co m%2Fpage.cfm%3Fname%3DListServer&data=02%7C01%7CDoron.Holan%40microsoft.com%7Cf4e 61e7044a5460bb7f008d563f26695%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636524 815110984702&sdata=4afKvOq%2BrYU6lWRIqZconX38lgImxU3rBS9ZgI4GzBQ%3D&reserved=0> --
  Message 4 of 7  
25 Jan 18 10:39
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6150
List Moderator
KMDF: determine originating thread of WDFREQUEST

<quote> the WDFREQUEST does not carry the thread ID </quote> Sure it does. It's in the IRP. But, regardless, it is absolutely true that: <quote> the thread in the driver is not guaranteed to be the thread from user mode </quote> So... <quote> One way to make this work is to have your transaction semantics on the wdffileobject level. </quote> This is the best advice. It's easy to implement, and it's handy. The WDF_FILE_OBJECT handle is always available. You can even stuff a context on it., in which you can store per-open-instance stuff. Will that work for you? Peter OSR @OSRDrivers
  Message 5 of 7  
06 Feb 18 01:49
ntdev member 176913
xxxxxx@faschingbauer.co.at
Join Date:
Posts To This List: 2
KMDF: determine originating thread of WDFREQUEST

What I found when reading the docs was ... WdfRequestGetRequestorProcessId(). Although I'd rather like the sending thread's ID, that looks like a hint that the WDFREQUEST somehow exposes originator information. IRP.Tail.Overlay.Thread. The docs (https://msdn.microsoft.com/en-us/library/windows/hardware/ff550694(v=vs.85).aspx ) say that "For requests that originate in user-mode, the I/O manager always sets this field to point to the TCB of the thread that issued the request." Would IRP.Tail.Overlay.Thread work? Thanks, Joerg On 01/25/2018 01:51 PM, xxxxx@windrvr.com wrote: > Actually, the WDFREQUEST does not carry the thread ID, and the thread in the driver is not guaranteed to be the thread from user mode unless you set up the device with additional calls. > > Overall your approach is not viable, can't you have a START TRANSACTION call that driver returns an ID for, then use the ID in your calls, then have an END TRANSACTION to finish things. I.E. do explicitly what you were trying to do with the thread ID? > > > Don Burn > Windows Driver Consulting > Website: http://www.windrvr.com > > <...excess quoted lines suppressed...> -- DI Jörg Faschingbauer Linux und Open Source - Programmierung, Beratung und Schulung
  Message 6 of 7  
06 Feb 18 12:01
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4087
KMDF: determine originating thread of WDFREQUEST

Yes sure, if requester mode is usermode then tail.thread is valid, plus you don't have to convince the customer to change their app. Mark Roddy On Tue, Feb 6, 2018 at 1:49 AM, xxxxx@faschingbauer.co.at <xxxxx@lists.osr.com> wrote: > What I found when reading the docs was ... > > WdfRequestGetRequestorProcessId(). Although I'd rather like the sending > thread's ID, that looks like a hint that the WDFREQUEST somehow exposes > originator information. > > IRP.Tail.Overlay.Thread. The docs (https://msdn.microsoft.com/en > -us/library/windows/hardware/ff550694(v=vs.85).aspx) say that "For > requests that originate in user-mode, the I/O manager always sets this > field to point to the TCB of the thread that issued the request." <...excess quoted lines suppressed...> --
  Message 7 of 7  
08 Feb 18 14:36
Peter Viscarola
xxxxxx@osr.com
Join Date:
Posts To This List: 6150
List Moderator
KMDF: determine originating thread of WDFREQUEST

Hence my comment two weeks ago: <quote> Sure it does. It's in the IRP. </quote> Peter OSR @OSRDrivers
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 17:47.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license